zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Subject: Re: all-matches with a suffix
Date: Thu, 16 Aug 2001 12:57:08 +0200	[thread overview]
Message-ID: <15227.42756.700159.266050@gargle.gargle.HOWL> (raw)
In-Reply-To: <OF1ABC579E.994F6597-ON80256AAA.00362C22@uk.jpmorgan.com>


martin.ebourne@arcordia.com wrote:

> > The problem here is that it has to cheat if you want to call it that.
> > There is this pseudo match I've been talking about already, containing
> > all the other matches.  In order to insert that match, it inserts the
> > other matches one by one, as if one were in a menu completion and
> > repeatedly using accept-and-menu-complete, typing spaces between the
> > matches.
> 
> I'm not surprised - it certainly looks like that's what its doing since the
> line visibly 'grows' as it is entered.
> 
> Is it not possible to build up the full match and add it in one go?

Eh?  It puts all matches into the command line without re-displaying
it after every match -- only redisplaying it at the end.

> ...
> 
> Well the option may not be such a bad idea. I can think of occasions where
> you would want a space separating the results, and others where you
> wouldn't. It's not obvious how the completion code could otherwise decide.

Yes, but that's not the real problem.  There are many different styles 
of how suffixes and all-matches should be handled (and that also
affects how prefixes are to be handled, as in your conv=value example).
I don't want to have yet another case of adding a bit and then some
more and some more and...

What I really want is to move more of the completion setup and
finalisation code into shell code, to make it more flexible and to
allow more people to play with it.  Then I'd even like to remove some
of the options to compadd (-q, -r, -R -- especially -R).  That means
identifying stuff for which we need C-code support and adding builtins 
and/or special parameters for that.  Then we can hopefully remove the
suffix handling from the zle module, and probably even get rid of the
difference between normal and completion widgets.  For things like
auto-removable suffixes zle would offer a hook or something equally
generic (some kind of {pre,post}-command-hook).  The rest would be in
shell code with a function to register prefixes and suffixes and to
say how they should be handled in different situations.

Or something like that.  I haven't thought that much about all this
yet, because I don't have much time now.  We had some discussion about 
suffix handling some time ago (last year, I think), but I'd have to
search for it in the archive, too, because somehow it fell from my
todo list.  Ahem.


Bye
  Sven

-- 
Sven Wischnowsky                    wischnow@informatik.hu-berlin.de


  reply	other threads:[~2001-08-16 10:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-16 10:28 martin.ebourne
2001-08-16 10:57 ` Sven Wischnowsky [this message]
     [not found] <OF8840F9F6.B6682A73-ON80256AA7.00697312@uk.jpmorgan.com>
2001-08-14 12:11 ` Sven Wischnowsky

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=15227.42756.700159.266050@gargle.gargle.HOWL \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.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).