From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: RE: PATCH: was RE: PATCH: old lists compstate
Date: Tue, 30 Mar 1999 14:52:27 +0200 (MET DST) [thread overview]
Message-ID: <199903301252.OAA07471@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Andrej Borsenkow"'s message of Tue, 30 Mar 1999 16:02:42 +0400
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@informatik.hu-berlin.de
next reply other threads:[~1999-03-30 12:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-30 12:52 Sven Wischnowsky [this message]
1999-03-31 16:28 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
1999-03-30 11:10 Sven Wischnowsky
1999-03-30 12:02 ` Andrej Borsenkow
1999-03-30 10:07 Sven Wischnowsky
1999-03-30 10:22 ` Andrej Borsenkow
1999-03-30 8:37 Sven Wischnowsky
1999-03-30 9:34 ` Andrej Borsenkow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199903301252.OAA07471@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).