Re: PATCH: Re: _netscape

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Oliver Kiddle wrote:

> ...
> 
> I've gone on to try to fix the handling of the closing bracket suffix in
> netscape remote commands which has resulted in the following thoughts on
> suffix handling in the new completion.
> 
> There are a few places where the contents of a remote command comes to a
> definite finish: a file/ftp/http URL that ends with a file or empty
> directory, a saveAs command after the file type, about: URLS. In these
> cases, it would be nice if completing the last stage added both the
> closing bracket (back-slash quoted if necessary) to terminate the remote
> command and any closing quote.
> 
> Adding a closing quote sometimes happens, for example:
> netscape -remote 'openURL(about:c<tab>
> this completes to the about:cache URL with the closing quote appended.
> Where does the quote come from: is the default suffix actually
> "$compstate[quote] " instead of just a space?

Approximately, yes. If the completion code thinks or knows that there
has to be a certain closing quote (or closing quotes) and there is no
other suffix, the quote is inserted. This was added at the last
completion-in-quotes overhaul (and in most cases gives one
automatically what one wants).

> ...
> 
> Basically, what a helper function needs to do is
> take the suffix passed to it and when it is completing a final component
> of itself, it should pass any suffix it wants with the one passed to it
> appended. Pulling out -S options from "$@" is going to look messy
> without some special handling at a lower level somewhere.

It's mostly a bit of [(i)...] stuff, but yes, it's probably common
enough... One idea would be to add an option to zparseopts to allow it 
to extract options. Actually, I've been wishing for something like
that, too.

> compadd seems
> to only use the first -S option it is passed but this isn't documented
> so I didn't want to rely on it.

It *is* documented, in the compadd entry, below the options.
_approximate always relied on it.

> If we do make it a documented feature
> then we still need to handle the situation where you are completing the
> final part of something and you want to use both your own suffix and the
> one passed to the function.

One problem I see here is that in some cases utility functions might
want to use their suffix only as a default, overridden by the one
given by a calling function (easy to solve). Another problem might be
the interaction with -[qrR].

> Note that _files can no longer complete subdirectories if you give it a
> -S option which is something other than a slash. _files should only add
> the suffix after a file (and possible after an empty directory).

Sometimes you want it, sometimes not...

> Returning to _netscape, the next issue was how to handle the closing
> bracket/quote already being there.
> I used compset -S '(|\\)\)*'. But this again comes up with a problem
> when we are not completing the final part of a URL. The suffix is only
> moved to ISUFFIX so for example:
> netscape -remote 'openURL(a<tab>)    i.e. cursor is at position of tab
> will complete the url to about:)' - advancing the cursor past the
> suffix. I'm able to prevent this by not using the suffix with compadd
> if the compset succeeded.

You may also want to have a look at $compstate[to_end]...

> This example shows how and leads me on to my next point:
> 
> _foo() {
>   local lsuf="" nsuf=""
>   compset -S '.*' || lsuf=". "
>   if compset -P "*:"; then
>     compadd -S "$lsuf" aaa bbb ccc
>   else
>     compset -S ':*' || nsuf=":"
>     compadd -S "$rsuf" one two three
>   fi
> }
> 
> foo o<tab>.  completes the one but moves the cursor past the '.'. I
> would prefer if it was only moved to the end of the :. We started off
> with just 'o.' so there was no :. this indicates to me that the part
> which comes after a colon is necessary so it is likely that the user
> will want to complete it. In the case of:
> foo o<tab>:ddd.
> it is fair enough in a way that the completion moves past the final '.'
> because there was a colon there to start with although even in this case
> I'd prefer it didn't. What I would actually want it to do in this case
> is move to the end of the 'ddd' but before the '.'. If 'ddd' was
> incomplete, I could finish it otherwise, another tab would advance me on
> to the next thing.

This, of course can't be solved even by to_end.


The way suffixes are handled has mostly historical reasons and, yes,
it is a bit simple minded. If someone wants to help to improve it, I'd 
like to have a short and comprehensive list of things one might want
to do, so that we can discuss it easliy and find the (hopefully few)
basic things we need for that. With that we could then think about
changing the code. Ok? (I don't think I'll have much time to think
about this...)


Bye
 Sven


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