* RE: accept-and-infer-next-history in path completion
@ 1999-07-12 6:25 Sven Wischnowsky
0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 1999-07-12 6:25 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> and if you press a-a-i-n-h
>
> bor@itsrm2:~%> l /archive/pub/unix/zip/unzip532.tar.gz
> unzip532.tar.gz zcrypt27.zip zip22.tar.gz
> unzip540.tar.gz zcrypt28.zip
>
> it assumes, that SELCTMINis set to 0 or 1, so that menu selection is started
> immediately.
Err, it does that regardless of the value on SELECTMIN.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: accept-and-infer-next-history in path completion
1999-07-09 15:07 ` Bart Schaefer
@ 1999-07-09 15:17 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 1999-07-09 15:17 UTC (permalink / raw)
To: Bart Schaefer, Sven Wischnowsky, zsh-workers
>
> I'm a bit (er, a lot) behind on patches ... what's the difference between
> this and accept-and-menu-complete? And if there is a difference, maybe
> accept-and-hold would be a better widget to co-opt than a-a-i-n-h?
>
a-a-m-c accepts finishes the completion of current word and adds _new_ word with
next possible match. a-a-i-n-h in menu select accepts currently selected match
and continues to complete _the_current_word_. In case of multipart ambiguous
completion it makes a big difference:
bor@itsrm2:~%> l /a/p/u/z/*<TAB>
bor@itsrm2:~%> l /archive/pub/unix/z<TAB>
zip/ zmodem/ zsh/
bor@itsrm2:~%> l /archive/pub/unix/zip
zip/ zmodem/ zsh/
If you now press a-a-m-c you get:
bor@itsrm2:~%> l /archive/pub/unix/zip /archive/pub/unix/zmodem
zip/ zmodem/ zsh/
and if you press a-a-i-n-h
bor@itsrm2:~%> l /archive/pub/unix/zip/unzip532.tar.gz
unzip532.tar.gz zcrypt27.zip zip22.tar.gz
unzip540.tar.gz zcrypt28.zip
it assumes, that SELCTMINis set to 0 or 1, so that menu selection is started
immediately.
/andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: accept-and-infer-next-history in path completion
1999-07-09 8:19 Sven Wischnowsky
@ 1999-07-09 15:07 ` Bart Schaefer
1999-07-09 15:17 ` Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 1999-07-09 15:07 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
On Jul 9, 10:19am, Sven Wischnowsky wrote:
} Subject: Re: accept-and-infer-next-history in path completion
}
} > > This makes accept-and-infer-next-history be treated specially when in
} > > menu-selection. It accepts the current match and immediatly starts
} > > completion again.
} >
} > In this case a-a-i-n-h is probably misnomer ...
} > something like accept-and-continue-completion would be better.
}
} Sure it is. I just had to take what's there.
I'm a bit (er, a lot) behind on patches ... what's the difference between
this and accept-and-menu-complete? And if there is a difference, maybe
accept-and-hold would be a better widget to co-opt than a-a-i-n-h?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: accept-and-infer-next-history in path completion
@ 1999-07-09 8:19 Sven Wischnowsky
1999-07-09 15:07 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Sven Wischnowsky @ 1999-07-09 8:19 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> > This makes accept-and-infer-next-history be treated specially when in
> > menu-selection. It accepts the current match and immediatly starts
> > completion again. So if you have a list of files, place the mark on a
> > directory and execute a-a-i-n-h, you can select files in that
> > directory. Of course it would be nice to be able to go back again,
> > e.g. with undo, but implementing that is a bit more complicated...
>
> It just occured to me, that it is quite useful in path completion. E.g. if you
> have something like
>
> /tools/{share,src}/z/bla-bla-bla
>
> it is nice to hit a single key to accept ``share'' or ``src'' and immediately
> continue completion after that.
That's what I had in mind.
> In this case a-a-i-n-h is probably misnomer ...
> something like accept-and-continue-completion would be better.
Sure it is. I just had to take what's there.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* accept-and-infer-next-history in path completion
1999-07-07 8:23 PATCH: complist Sven Wischnowsky
@ 1999-07-09 7:47 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 1999-07-09 7:47 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
>
> This makes accept-and-infer-next-history be treated specially when in
> menu-selection. It accepts the current match and immediatly starts
> completion again. So if you have a list of files, place the mark on a
> directory and execute a-a-i-n-h, you can select files in that
> directory. Of course it would be nice to be able to go back again,
> e.g. with undo, but implementing that is a bit more complicated...
>
It just occured to me, that it is quite useful in path completion. E.g. if you
have something like
/tools/{share,src}/z/bla-bla-bla
it is nice to hit a single key to accept ``share'' or ``src'' and immediately
continue completion after that. In this case a-a-i-n-h is probably misnomer ...
something like accept-and-continue-completion would be better.
/andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-07-12 6:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-12 6:25 accept-and-infer-next-history in path completion Sven Wischnowsky
-- strict thread matches above, loose matches on Subject: below --
1999-07-09 8:19 Sven Wischnowsky
1999-07-09 15:07 ` Bart Schaefer
1999-07-09 15:17 ` Andrej Borsenkow
1999-07-07 8:23 PATCH: complist Sven Wischnowsky
1999-07-09 7:47 ` accept-and-infer-next-history in path completion 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).