Re: all-matches with a suffix

Re: all-matches with a suffix

[martin.ebourne]

> 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?

> Now the `-r' option means that the suffix (-S ', ') should
> be removed if the next character typed is a space (or a comma, or...).
> That auto-remove thing is certainly the right thing when used
> interactively, but for this all-matches thing...
>
> Hm, we had some discussion about all this suffix handling anyway, so
> maybe we should start collection other problems people see or have
> seen with it and then find the real solution.  At least I can't see
> any simple solution now, without adding another option to compadd,
> telling it how it should behave for a-a-m-c.  and that would look like
> a hack, somehow.

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.
Four cases I've though of so far are:

1. Expanding all matches on a list of directories, you would probably want
the trailing '/' removed, and the results separated by spaces. This is what
it does currently.

2. Expanding the SQL selection list you would want the separator ', ' used
as is (though an extra space wouldn't hurt). Currently the line ends up
being corrupted.

3. Expanding 'dd conv=*' you would want the separator ',' used as is, and
an extra space would be a problem. (eg. 'dd conv=ascii,lcase,') Currently
it expands to a list of 'conv=value ', which I guess is ok, but it's
probably not what I'd expect. Also it may depend on the command if that is
valid.

4. Expanding 'dd *' you would want the separator '=' used with a space
appended. This is what it does currently.

In addition, for case (2), if I had

     select table.* from table

and expanded after '*', I'd want

     select table.col1, table.col2, table.col3, from table

which is a lot like (3) currently behaves (though currently the line still
gets corrupted due to the ', ' suffix removal.)


Finally, a separate note about 3, is that if I enter:

     dd conv=a

and complete, I get

     dd conf=ascii,

which would be fine. But then instead of offering more completions for the
list when I try completion again, it tries to correct the word to 'ascii'
(1 error). It doesn't succeed though.

Cheers,

Martin.

Re: all-matches with a suffix

[Sven Wischnowsky]

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

all-matches with a suffix

[Sven Wischnowsky]

martin.ebourne@arcordia.com wrote:

> ...
> 
> I've tracked it down to the -r (or -q) option to compadd. The completions
> are added as:
> 
>     compadd -S ", " -r ", \t\n\-" -a _sql_columns
> 
> This is so that when you complete a column name normally in the select list
> it appends a comma and a space, but if you type comma or space it removes
> it again.
> 
> If I remove the -r then I get the much better:
> 
>     select environ,  gid,  name,  suid,  uid,  from sysusers
> 
> Presumably if the -r was in still, then typing space would remove that last
> comma?
> 
> Any idea what's up?

Yes ;-)

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.  Now the `-r' option means that the suffix (-S ', ') should
be removed if the next character typed is a space (or a comma, or...).

So.

So what do we do now?

That auto-remove thing is certainly the right thing when used
interactively, but for this all-matches thing...

Hm, we had some discussion about all this suffix handling anyway, so
maybe we should start collection other problems people see or have
seen with it and then find the real solution.  At least I can't see
any simple solution now, without adding another option to compadd,
telling it how it should behave for a-a-m-c.  and that would look like 
a hack, somehow.


Bye
  Sven

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