Re: PATCH: was Re: Closing quotes in completion

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> That seems to fix the problem I was worried about.  One difficulty is you
> get a (removable) space between the end of the completion and the quote
> (where the cursor ends up) when there's a unique match.  That's not so bad,
> but it is it really correct deliberately to insert a space *before* a
> suffix?

Err, right. Since the space is considered to be the automatically
inserted separator for the next word and is not a part of the
completed string, we shouldn't insert it before the ISUFFIX.

>  (There's also the old problems with completing in quotes where you
> expect "filename wi<TAB> to complete to "filename with spaces", but if I
> remember right that's made difficult by the lexer.)

Which it does. The problem is that you don't get the backslashes if
you want them even inside quotes (`zsh -c "ls f<TAB>'). And there is
no way how the completion code could detect what you want.

> > This also reminds me of the last thing I'm still thinking about for
> > the new style completion stuff: a way to access and probably modify
> > the completions added.
> > 
> > Because of these problems I haven't implemented anything of this yet,
> > so I'd like to hear comments/suggestions about all this.
> 
> The only thing that strikes me is the idea of having a fairly raw access to
> the structures, i.e. if you really know what you're doing there's some
> option for you to modify pretty much anything.  But I don't know either the
> uses for or the difficulties with that.

The only uses I can think of are:

  - Getting information about an old list or about a new list after
    all completions have been added to find out what to insert.
    Some time ago, we had some people here asking if it would be
    possible to give different compctl-flag-lists for a command and
    then have the completion code first insert only matches from the
    first list, then invoke some other widget to skip over to the next 
    list and so on. If at all I would like to do such things with
    groups of matches. In fact, this is the reason why I made
    inserting the n'th match from the m'th group so easy with the
    compstate[insert] key. For that it would be nice to be able to get 
    information at least about the different groups (name, how many
    matches, etc.).
  - compadd allows more detailed control over some of the things then
    compgen (the is-a-file-flag, the remove-characters/function). Being
    able to set these fields in matches from compgen is currently the
    only thing I can think of where modifying the generated list of
    matches might be useful. And have to do this by hand is ugly, of
    course, options for compgen to give control over this would be
    much better. But we have only one more option-letter (plus some
    non-alphabetic characters) free for comp{ctl,gen}: `h'.
    Now, if we had support for long-options...

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Apr 27 11:03:35 1999
+++ Src/Zle/zle_tricky.c	Tue Apr 27 12:45:30 1999
@@ -7049,7 +7049,6 @@
 	/* If we didn't add a suffix, add a space, unless we are *
 	 * doing menu completion or we are completing files and  *
 	 * the string doesn't name an existing file.             */
-	cs = scs;
 	inststrlen(" ", 1, 1);
 	menuinsc++;
 	if (menuwe)

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx