zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: Re: _netscape
@ 2000-05-23 13:58 Sven Wischnowsky
  0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-05-23 13:58 UTC (permalink / raw)
  To: zsh-workers


Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> 
> > > > 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.
> 
> > This is so simple to write that I think it's worth adding. So, this
> > adds the -E option to zparseopts that can be used to extract options
> > from the positional parameters. When combined with -D, the options
> > described are actually removed from $*.
> 
> On the basis that compadd does only use the first -S option that it is
> passed, being able to remove an option is not what is wanted: what is
> wanted is a way to separate the first -S option and have it available in
> a parameter.

Ever had a look at zparseopts?

  foo() {
    local suffix

    zparseopts -D -E 'S:=suffix'

    print "user-supplied suffix: ${suffix:-<none>}"
    print "remaining arguments:  $*"
  }

  % foo -J group -S test -X format other arguments
  user-supplied suffix: -S test
  remaining arguments:  -J group -X format other arguments
  % foo -J group -X format no suffix here
  user-supplied suffix: <none>
  remaining arguments:  -J group -X format no suffix here

What else do you need?

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: PATCH: Re: _netscape
@ 2000-05-24  8:05 Sven Wischnowsky
  0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-05-24  8:05 UTC (permalink / raw)
  To: zsh-workers


Oliver Kiddle wrote:

> ...
> 
> > > 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...
> 
> When might you not want it (the slash)? If you don't want to decend
> directories, it would be easier to use compadd * than _files. I'd have
> thought that in the vast majority of cases, the passed suffix would be
> wanted only after a file or empty directory.

When completing only directories.

> ...
> 
> > 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...)
> 
> I'll try to come up with such a list but it may be a little while before
> I have time. Does anyone know of any parts of the completion system
> where there is an interesting sitation or currently not very good
> handling of suffixes: it might be useful if I investigate a few
> different instances first.

You have every time you want or need, I don't think we really need to
do this before 3.1.7.

And, no, off the top of my head I can't think of places where
suffix-handling caused that much trouble.

Oh, and, btw, when thinking about suffix handling, we should probably
also re-think the -R stuff (auto-removal in general). Maybe we find
something better, maybe we don't...

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: PATCH: Re: _netscape
@ 2000-05-23 13:15 Sven Wischnowsky
  2000-05-23 13:50 ` Oliver Kiddle
  0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 2000-05-23 13:15 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> Oliver Kiddle wrote:
> 
> > ...
> > 
> > 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.

This is so simple to write that I think it's worth adding. So, this
adds the -E option to zparseopts that can be used to extract options
from the positional parameters. When combined with -D, the options
described are actually removed from $*.

Bye
 Sven

Index: Doc/Zsh/mod_zutil.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_zutil.yo,v
retrieving revision 1.6
diff -u -r1.6 mod_zutil.yo
--- Doc/Zsh/mod_zutil.yo	2000/05/22 09:32:33	1.6
+++ Doc/Zsh/mod_zutil.yo	2000/05/23 13:14:08
@@ -131,7 +131,7 @@
 This implements the internals of the `tt(_regex_arguments)'.
 )
 findex(zparseopts)
-item(tt(zparseopts) [ tt(-D) ] [ tt(-a) var(array) ] [ tt(-A) var(assoc) ] var(specs))(
+item(tt(zparseopts) [ tt(-D) ] [ tt(-E) ] [ tt(-a) var(array) ] [ tt(-A) var(assoc) ] var(specs))(
 This builtin simplifies the parsing of options in positional
 parameters, i.e. the set of arguments given by tt($*).  Each var(spec)
 describes one option and should be of the form
@@ -166,6 +166,9 @@
 positional parameters, up to but not including any not described by the
 var(specs).  This means that any options processed by tt(zparseopts) are
 removed from the positional parameters.
+
+The tt(-E) option allows to extract the options described by the
+var(specs) from the positional parameters, ignoring all other strings.
 
 For example,
 
Index: Src/Modules/zutil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zutil.c,v
retrieving revision 1.4
diff -u -r1.4 zutil.c
--- Src/Modules/zutil.c	2000/05/22 09:32:33	1.4
+++ Src/Modules/zutil.c	2000/05/23 13:14:09
@@ -1261,8 +1261,8 @@
 static int
 bin_zparseopts(char *nam, char **args, char *ops, int func)
 {
-    char *o, *p, *n, **pp, **aval, **ap, *assoc = NULL;
-    int del = 0, f;
+    char *o, *p, *n, **pp, **aval, **ap, *assoc = NULL, **cp, **np;
+    int del = 0, f, extract = 0;
     Zoptdesc sopts[256], d;
     Zoptarr a, defarr = NULL;
     Zoptval v;
@@ -1290,6 +1290,14 @@
 		}
 		del = 1;
 		break;
+	    case 'E':
+		if (o[2]) {
+		    args--;
+		    o = NULL;
+		    break;
+		}
+		extract = 1;
+		break;
 	    case 'a':
 		if (defarr) {
 		    zwarnnam(nam, "default array given more than once", NULL, 0);
@@ -1400,10 +1408,19 @@
 	if (!o[1])
 	    sopts[STOUC(*o)] = d;
     }
-    for (pp = pparams; (o = *pp); pp++) {
-	if (*o != '-')
-	    break;
+    np = cp = pp = ((extract && del) ? arrdup(pparams) : pparams);
+    for (; (o = *pp); pp++) {
+	if (*o != '-') {
+	    if (extract) {
+		if (del)
+		    *cp++ = o;
+		continue;
+	    } else
+		break;
+	}
 	if (!o[1] || (o[1] == '-' && !o[2])) {
+	    if (del && extract)
+		*cp++ = o;
 	    pp++;
 	    break;
 	}
@@ -1429,8 +1446,14 @@
 		} else
 		    add_opt_val(d, NULL);
 	    }
-	    if (!o)
-		break;
+	    if (!o) {
+		if (extract) {
+		    if (del)
+			*cp++ = *pp;
+		    continue;
+		} else
+		    break;
+	    }
 	} else {
 	    if (d->flags & ZOF_ARG) {
 		char *e = o + strlen(d->name) + 1;
@@ -1450,6 +1473,10 @@
 		add_opt_val(d, NULL);
 	}
     }
+    if (extract && del)
+	while (*pp)
+	    *cp++ = *pp++;
+
     for (a = opt_arrs; a; a = a->next) {
 	aval = (char **) zalloc((a->num + 1) * sizeof(char *));
 	for (ap = aval, v = a->vals; v; ap++, v = v->next) {
@@ -1498,9 +1525,15 @@
 	sethparam(assoc, aval);
     }
     if (del) {
-	pp = zarrdup(pp);
-	freearray(pparams);
-	pparams = pp;
+	if (extract) {
+	    *cp = NULL;
+	    freearray(pparams);
+	    pparams = zarrdup(np);
+	} else {
+	    pp = zarrdup(pp);
+	    freearray(pparams);
+	    pparams = pp;
+	}
     }
     return 0;
 }

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


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: PATCH: Re: _netscape
@ 2000-05-22  8:37 Sven Wischnowsky
  2000-05-23 16:07 ` Oliver Kiddle
  0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 2000-05-22  8:37 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 8+ messages in thread
* PATCH: Re: _netscape
@ 2000-05-18 11:02 Sven Wischnowsky
  2000-05-19 18:39 ` Oliver Kiddle
  0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 2000-05-18 11:02 UTC (permalink / raw)
  To: zsh-workers


Oliver Kiddle wrote:

> ...
> 
> Where things go wrong is when I don't use a quote:
> 
> netscape -remote open<tab> completes '\(', subsequent tabs insert more, I would
>     expect to see openFile and openURL listed
> netscape -remote openU<tab> works - completes to openURL\(
> netscape -remote openURL\(<tab> also works - it completes URLs.
> 
> The first of these is where it isn't workling. The thing which is missing is that I never get the list of matches, just the inserted brackets.

So why do we use `-s', then.

This'll do? 

Bye
 Sven

Index: Completion/User/_netscape
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_netscape,v
retrieving revision 1.4
diff -u -r1.4 _netscape
--- Completion/User/_netscape	2000/04/11 07:57:57	1.4
+++ Completion/User/_netscape	2000/05/18 11:02:38
@@ -56,15 +56,9 @@
       fi
     ;;
     *)
-      if [[ -z "$QIPREFIX" ]]; then
-	_wanted commands expl 'remote commands' \
-  	    compadd -s'(' -S '' -M 'm:{a-zA-Z}={A-Za-z}' - \
-                    $remote_commands && ret=0
-      else
-	_wanted commands expl 'remote commands' \
-            compadd -qS '(' -M 'm:{a-zA-Z}={A-Za-z}' - \
-                    $remote_commands && ret=0
-      fi
+      _wanted commands expl 'remote commands' \
+  	  compadd -qS "${${QIPREFIX:+(}:-\(}" -M 'm:{a-zA-Z}={A-Za-z}' - \
+                  $remote_commands && ret=0
     ;;
   esac
 fi

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2000-05-24  8:07 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-23 13:58 PATCH: Re: _netscape Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
2000-05-24  8:05 Sven Wischnowsky
2000-05-23 13:15 Sven Wischnowsky
2000-05-23 13:50 ` Oliver Kiddle
2000-05-22  8:37 Sven Wischnowsky
2000-05-23 16:07 ` Oliver Kiddle
2000-05-18 11:02 Sven Wischnowsky
2000-05-19 18:39 ` Oliver Kiddle

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).