* Re: Completion list is not cleared
@ 1999-01-26 13:45 Sven Wischnowsky
1999-01-26 14:08 ` Andrej Borsenkow
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 1999-01-26 13:45 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
>
> I think, this changed first in 3.1.x; I don't have 3.0.x to test it.
>
> the list of choices is not cleared after completion is done. Consider
>
> zsh -f
> itsrm2% pg M<TAB>
> Makefile MkKernOpts* Mksrc*
> <TAB>
(automenu?)
> itsrm2% pg Makefile
> Makefile MkKernOpts* Mksrc*
>
> If I now enter SPACE, I get
>
> itsrm2% pg Makefile <= cursor here
> Makefile MkKernOpts* Mksrc*
Is the cursor directly after the Makefile or after a space? I have it
after a space, which is certainly the right thing.
>
> I definitely remember being surprised seeing it for the first time. Is it
> intentional? It is not a big deal I admit, but what is the reason?
If you have selfinsert bound to space the behaviour should be the one
zsh always had (I think, I don't exactly remember 3.0.5 and I don't
have it anymore, but a 2.6-beta12 I just found behaves the same).
If you have space bound to magic-space I can understand that you would
like the list to disappear, but at least that 2.6 didn't remove it,
too (although zsh might have behaved differently in 3.0.x).
So, can anyone test how 3.0.5 did this? Should we change it? Did the
behavior change? If yes, was the old way better?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Completion list is not cleared
1999-01-26 13:45 Completion list is not cleared Sven Wischnowsky
@ 1999-01-26 14:08 ` Andrej Borsenkow
0 siblings, 0 replies; 6+ messages in thread
From: Andrej Borsenkow @ 1999-01-26 14:08 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
> >
> > itsrm2% pg Makefile <= cursor here
> > Makefile MkKernOpts* Mksrc*
>
> Is the cursor directly after the Makefile or after a space? I have it
> after a space, which is certainly the right thing.
>
After I press TAB the second time and automenu starts, it is directly after
Makefile.
And I mean the case, when I press SPACE after that, exiting current
completion. In this case cursor is after inserted space.
>
> If you have selfinsert bound to space the behaviour should be the one
> zsh always had (I think, I don't exactly remember 3.0.5 and I don't
> have it anymore, but a 2.6-beta12 I just found behaves the same).
> If you have space bound to magic-space I can understand that you would
> like the list to disappear, but at least that 2.6 didn't remove it,
> too (although zsh might have behaved differently in 3.0.x).
>
I must admit, I don't remember, when it changed. I started with late 2.x
beta, some time before version number was changed to 3.0.0. I never played
with bindkey for space. But I remember my surprise when I first have seen
list not disappearing. And I think, I even sent a message to this list at
this time ... gotta make a search ... no, sigh ... Hmmm about bindkey ...
there was large change in zle by Zefram. May it be, that some default
bindings changed at that time?
> So, can anyone test how 3.0.5 did this? Should we change it? Did the
> behavior change? If yes, was the old way better?
>
Well, this question actually belongs to zsh-users. I vote for clearing the
list :-)
/andrej
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Completion list is not cleared
@ 1999-01-26 15:53 Sven Wischnowsky
0 siblings, 0 replies; 6+ messages in thread
From: Sven Wischnowsky @ 1999-01-26 15:53 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
>
> >
> > I even forgot one question: when should it be deleted. Whenever a
> > menucompletion is left and whenever a normal completion gives only one
> > match (which is then inserted)? At least this sounds to me as if some
> > people might like to have it. On the other side there may be people
> > (like me) who would like to leave the list in place in these cases
> > (maybe I want to complete another word from it), but remove the list
> > if the completion code produces no matches (I have all beeps turned
> > off).
> >
>
> I understand now, what I really wanted. I wanted zsh to know, when I am
> through with selecting the best match. With all ZSH features, it probably
> won't read your mind ... not yet at least :-)
I think you are right, zsh could at least try to guess this. The
question, when zsh should remove the list (and a old list that has not
been removed when another completion attempt fails is certainly a bad
thing). If I would dare to do so, I would suggest an option...
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Completion list is not cleared
1999-01-26 14:15 Sven Wischnowsky
@ 1999-01-26 15:20 ` Andrej Borsenkow
0 siblings, 0 replies; 6+ messages in thread
From: Andrej Borsenkow @ 1999-01-26 15:20 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
>
> I even forgot one question: when should it be deleted. Whenever a
> menucompletion is left and whenever a normal completion gives only one
> match (which is then inserted)? At least this sounds to me as if some
> people might like to have it. On the other side there may be people
> (like me) who would like to leave the list in place in these cases
> (maybe I want to complete another word from it), but remove the list
> if the completion code produces no matches (I have all beeps turned
> off).
>
I see ... Well, folks, sorry for spam mail
I understand now, what I really wanted. I wanted zsh to know, when I am
through with selecting the best match. With all ZSH features, it probably
won't read your mind ... not yet at least :-)
regards
/andrej
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Completion list is not cleared
@ 1999-01-26 14:15 Sven Wischnowsky
1999-01-26 15:20 ` Andrej Borsenkow
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 1999-01-26 14:15 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> ...
>
> > So, can anyone test how 3.0.5 did this? Should we change it? Did the
> > behavior change? If yes, was the old way better?
> >
>
> Well, this question actually belongs to zsh-users. I vote for clearing the
> list :-)
I even forgot one question: when should it be deleted. Whenever a
menucompletion is left and whenever a normal completion gives only one
match (which is then inserted)? At least this sounds to me as if some
people might like to have it. On the other side there may be people
(like me) who would like to leave the list in place in these cases
(maybe I want to complete another word from it), but remove the list
if the completion code produces no matches (I have all beeps turned
off).
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Completion list is not cleared
@ 1999-01-26 12:30 Andrej Borsenkow
0 siblings, 0 replies; 6+ messages in thread
From: Andrej Borsenkow @ 1999-01-26 12:30 UTC (permalink / raw)
To: ZSH workers mailing list
I think, this changed first in 3.1.x; I don't have 3.0.x to test it.
the list of choices is not cleared after completion is done. Consider
zsh -f
itsrm2% pg M<TAB>
Makefile MkKernOpts* Mksrc*
<TAB>
itsrm2% pg Makefile
Makefile MkKernOpts* Mksrc*
If I now enter SPACE, I get
itsrm2% pg Makefile <= cursor here
Makefile MkKernOpts* Mksrc*
I definitely remember being surprised seeing it for the first time. Is it
intentional? It is not a big deal I admit, but what is the reason?
TIA
/andrej
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-01-26 15:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-26 13:45 Completion list is not cleared Sven Wischnowsky
1999-01-26 14:08 ` Andrej Borsenkow
-- strict thread matches above, loose matches on Subject: below --
1999-01-26 15:53 Sven Wischnowsky
1999-01-26 14:15 Sven Wischnowsky
1999-01-26 15:20 ` Andrej Borsenkow
1999-01-26 12:30 Andrej Borsenkow
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).