RE: PATCH: was RE: PATCH: old lists compstate

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> I just tried it with vanilla zsh -f; just try ls ChTAB in zsh top level dir
> :-) Look:
> 
> bor@itsrm2:/tools/src/zsh-3.1.5-pws-14%> zsh -f
> itsrm2% l Ch<TAB>
> itsrm2% l ChangeLog<TAB>
> itsrm2% l ChangeLog<TAB>
> ChangeLog       ChangeLog.3.0   (beep)
> itsrm2% l ChangeLog<TAB>
> ChangeLog       ChangeLog.3.0    (beep)
> itsrm2% l ChangeLog.3.0
> ChangeLog       ChangeLog.3.0
> 
> So, I need four TABS to get at the automenu completion.   _path_files does
> it on the third TAB. confused.

No, three. What irritates you here is that the unambiguous string
inserted on the first TAB is the same as the first match inserted at
the third TAB. Try:

  % mkdir foo; touch foo/foo{1,2,3};cd foo
  % ls f<TAB><TAB><TAB>

Here you get `foo' on the first TAB, the list on the second, and
`foo1' on the third (starting menucompletion).

Ok?

[ Rest of the mail deleted, let's start from scratch. ]

Think about `listambiguous' as an option delaying normal processing
for one TAB.

Now, without `listambiguous', but with `automenu' set it goes like this:

1) First TAB, completions are generated, more than one match, the code 
   inserts the unambiguous part and (if `autolist' is set) shows the
   list. If `automenu' is set, it sets everything up so that
   menucompletion is started on the next TAB. And since normal
   completion is done here, the cursor is moved into the word.
2) Second TAB, directly after the previous one. Menucompletion is
   started due to the setup from the first TAB, *no* completions are
   created, it just uses the old list. It knows the position
   the cursor was at (well, not actually the position, only if it was
   at the end of the whole word) when things were set up for
   `automenu'. In this case this was the first TAB, where the cursor
   was at the end of the word (remember: it knows about the position
   of the cursor *when completion was started* -- and cares little
   about the position of the cursor after the unambiguous stuff has
   been inserted because we once decided that moving the cursor to the 
   end is a good thing for menucompletion, but not for normal
   completion).
   Well, with all that it moves the cursor to the end when
   menucompleting because it was at the end when the completion was
   done that made `automenu' start menucompletion on the next TAB.

Ok. With `listambiguous' set:

1) First TAB, completions are generated, more than one match, the
   unambiguous string is inserted. This time it sees that
   `listambiguous' is set and delays everything (both listing and
   menucompletion, trying to make everything after the next TAB *look* 
   like the first case above).
2) Second TAB, completions are generated (for the second time, this is
   the important bit). This time the cursor was in the middle of the
   word when the whole comlpetion code was run.
   Since it can't build an unambiguous string this time (more exactly:
   no unambiguous string different from what's on the line),
   `listambiguous' is ignored and the list is shown (with
   `autolist'). And then the code behaves as on the first TAB in the
   first case, setting everything up for `automenu'. But here the
   previous TAB left the cursor in the middle of the word and that is
   remmebered.
3) Third TAB, menucompletion is immediatly started. Remembering that
   the cursor was in the middle of the word before the second TAB, it
   leaves it there.

That's it. When we added the `bashautolist' option and I did the
clean-ups in `do_ambiguous()' I mentioned that we can do this only
easily in the code by calling the completion code again (sorry, for
the strange wording, but whenever I talk about completion, I'm
thinking in terms of the code, I hope the stuff above made this
clearer). And calling it twice -- more precicesly: treating everything 
*after* the first TAB with `listambiguous' *like* the first TAB with
`listambiguous' unset is what makes this look different from the other 
cases you mentioned. But it isn't, you just have to remember that with 
`listambiguous' set the first TAB doesn't care about `automenu' and
happily does normal completion. With that the rest follows naturally.

Finally, your request for getting this cursor-left-in-word behavior
always: I've added the `compstate[to_end]' key just for this. If you
stick a `compstate[to_end]=single' in you `_main_complete' you'll get
what you want. I didn't add an option for this mainly because I'm
reluctant to add options (remembering times when we had many people
here complaining about too many options being added).


So question to everyone: is it important enough to add an option, say
  `menu_in_word', that makes the cursor be left inside the word when
  menucompletion is used and the cursor was *not* already in the word
  before menucompletion was started?

I may also say (again) that this is a relatively new problem because
previously we didn't have normal completion move the cursor somewhere
inside the word where it hadn't been before -- and not all these
matchers, functions, and stuff that make this useful.

To add or not to add...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx