Compctl fixes & a query

Compctl fixes & a query

[Zefram]

-----BEGIN PGP SIGNED MESSAGE-----

The patch below fixes a few problems with the compctl builtin, and
cleans up a couple of bits of the code.  It fixes the rather buggy
handling of the command "+", and allows command names to be preceded by
a single dash on the command line (useful for commands beginning with a
dash, and for "+").  It causes a warning message to be output if
command names are given in addition to one of -C, -D and -T, because
that doesn't work at the moment.  A warning is also printed if the
default completion is specified with a trailing + (meaning to use the
default completion), and the trailing + is ignored.  It fixes the minor
problem of an extra '' appearing at the end of the -C, -D and -T
completions when they are listed with -L.

The practcal upshot of all that is that compctl won't do anything silly
to compctls you don't intend to modify; won't silently lose bits of its
command line; can be told to set up completion for absolutely any
command name; and will have produce a fully accurate list if given the
- -L option.  It even handles cases like "compctl -C +" gracefully,
showing that command in the listing.  ("compctl + commnd" removes
command's compctl, making it a default completion.  "compctl -C +"
makes the command completion always use default completion.)

On a separate matter, does anyone ever use the numerical equals
expansion?  (That is, =1 expands to the directory at the top of the
stack, =2 to the next directory in the stack, etc.)  I find it rather
annoying, as some of the commands here begin with a digit, and =command
won't work on them with this feature.  I think that = expansion should
always be on command names.  I suggest that ~1, ~2 etc. be used
instead, as the ~ sequences are all (supposed to be) directories,
whereas the normal result of = expansion is a pathname or command.
Admittedly, having ~2 handled specially could cause problems if one has
done a few "hash -d" commands, but we already have ~+ and ~- handled
specially anyway.

 -zefram

      *** Src/builtin.c.old	Sun Jul 16 08:16:08 1995
      --- Src/builtin.c	Sun Jul 16 14:54:37 1995
      ***************
      *** 1660,1668 ****
        		printcompctl("", &cc_default);
         	    if (cclist & 8)
         		printcompctl("", &cc_first);
      ! 	} else if (*argv)
        	    /* assign the compctl to the commands given */
        	    compctl_process_cc(argv, cc);
        
        	/* remember flags for printing */
        	flags = cc->mask;
      --- 1660,1676 ----
        		printcompctl("", &cc_default);
         	    if (cclist & 8)
         		printcompctl("", &cc_first);
      ! 	} else if (*argv) {
      ! 	    /* Zefram 1995-07-16: I think this is needed on the grounds that
      ! 	    the -C, -D and -T flags don't combine successfully with command
      ! 	    names (or each other). */
      ! 	    if((cclist & 14) && *argv) {
      ! 		zwarnnam(name, "extraneous commands ignored", NULL, 0);
      ! 		*argv = NULL;
      ! 	    }
        	    /* assign the compctl to the commands given */
        	    compctl_process_cc(argv, cc);
      + 	}
        
        	/* remember flags for printing */
        	flags = cc->mask;
      ***************
      *** 1671,1677 ****
        	if (!*argv || (cclist & 1))
        	    freecompctl(cc);
            }
      !      if (!*argv && !(cclist & 14)) {
         	/* no commands and no -C, -T, or -D, so just list */
        	showflag = (cclist & 1) ? 0 : flags;
        	scanhashtable(compctltab, (HFunc) printcompctlp);
      --- 1679,1685 ----
        	if (!*argv || (cclist & 1))
        	    freecompctl(cc);
            }
      !     if (!*argv && !(cclist & 14)) {
         	/* no commands and no -C, -T, or -D, so just list */
        	showflag = (cclist & 1) ? 0 : flags;
        	scanhashtable(compctltab, (HFunc) printcompctlp);
      ***************
      *** 1699,1706 ****
            /* Handle `compctl + foo ...' specially:  turn it into
             * a default compctl by removing it from the hash table.
             */
      !     if (first && **argv == '+' && !(*argv)[1] &&
      ! 	*argv[1] != '-') {
        	freecompctl(cc);
         	cclist = 16;
        	return 0;
      --- 1707,1718 ----
            /* Handle `compctl + foo ...' specially:  turn it into
             * a default compctl by removing it from the hash table.
             */
      !     if (first && argv[0][0] == '+' && !argv[0][1] &&
      ! 	    !(argv[1] && argv[1][0] == '-' && argv[1][1])) {
      ! 	argv++;
      ! 	if(*argv && **argv == '-')
      ! 	    argv++;
      ! 	*av = argv;
        	freecompctl(cc);
         	cclist = 16;
        	return 0;
      ***************
      *** 1708,1719 ****
        
            memset((void *)&cct, 0, sizeof(cct));
        
      !     for (; !ready && *argv && **argv == '-';) {
        	/* Loop through the flags until we have no more:
        	 * those with arguments are not properly allocated yet,
        	 * we just hang on to the argument that was passed.
        	 */
      ! 	if (**argv == '-' && !(*argv)[1])
        	    *argv = "-+";
        	while (!ready && *++(*argv))
        	    switch (**argv) {
      --- 1720,1731 ----
        
            memset((void *)&cct, 0, sizeof(cct));
        
      !     for (; !ready && *argv && **argv == '-' && (argv[0][1] || !first);) {
        	/* Loop through the flags until we have no more:
        	 * those with arguments are not properly allocated yet,
        	 * we just hang on to the argument that was passed.
        	 */
      ! 	if (!(*argv)[1])
        	    *argv = "-+";
        	while (!ready && *++(*argv))
        	    switch (**argv) {
      ***************
      *** 1838,1844 ****
        		break;
        	    case 'P':
        		if (hx) {
      ! 		    zerrnam(name, "no prefix allowed in or'd (+) completion",
        			    NULL, 0);
        		    return 1;
        		}
      --- 1850,1856 ----
        		break;
        	    case 'P':
        		if (hx) {
      ! 		    zerrnam(name, "no prefix allowed in xor'd (+) completion",
        			    NULL, 0);
        		    return 1;
        		}
      ***************
      *** 1855,1861 ****
        		break;
        	    case 'S':
        		if (hx) {
      ! 		    zerrnam(name, "no suffix allowed in or'd (+) completion",
        			    NULL, 0);
        		    return 1;
        		}
      --- 1867,1873 ----
        		break;
        	    case 'S':
        		if (hx) {
      ! 		    zerrnam(name, "no suffix allowed in xor'd (+) completion",
        			    NULL, 0);
        		    return 1;
        		}
      ***************
      *** 2002,2008 ****
        	     */
        	    if (cc_assign(name, &cc, &cct, first && !hx))
        		return 1;
      - 
        	    hx = 1;
        	    ready = 0;
        
      --- 2014,2019 ----
      ***************
      *** 2010,2029 ****
        		(**argv == '-' && (!argv[0][1] ||
        				   (argv[0][1] == '-' && !argv[0][2])))) {
        		/* No argument to +, which means do default completion */
      ! 		if (isdef) {
      ! 		    zerrnam(name,
      ! 			    "recursive or'd default completions not allowed",
        			    NULL, 0);
      ! 		    return 1;
      ! 		}
      ! 		cc->xor = &cc_default;
      ! 		if (!*argv || **argv == '-') {
      ! 		    /* Nothing left after final + */
      ! 		    if (*argv)
      ! 			(*argv)--;
      ! 		    argv--;
      ! 		    ready = 1;
      ! 		}
        	    } else {
        		/* more flags follow:  prepare to loop again */
        		cc->xor = (Compctl) zcalloc(sizeof(*cc));
      --- 2021,2032 ----
        		(**argv == '-' && (!argv[0][1] ||
        				   (argv[0][1] == '-' && !argv[0][2])))) {
        		/* No argument to +, which means do default completion */
      ! 		if (isdef)
      ! 		    zwarnnam(name,
      ! 			    "recursive xor'd default completions not allowed",
        			    NULL, 0);
      ! 		else
      ! 		    cc->xor = &cc_default;
        	    } else {
        		/* more flags follow:  prepare to loop again */
        		cc->xor = (Compctl) zcalloc(sizeof(*cc));
      ***************
      *** 2032,2037 ****
      --- 2035,2042 ----
        	    }
        	}
            }
      +     if (!ready && *argv && **argv == '-')
      + 	argv++;
        
            /* assign the last set of flags we parsed */
            if (cc_assign(name, &cc, &cct, first && !hx))
      ***************
      *** 2042,2052 ****
            return 0;
        }
        
        /**/
        int
        get_xcompctl(char *name, char ***av, Compctl cc, int isdef)
        {
      -     /* Handle the -x ... -- part of compctl. */
            char **argv = *av, *t, *tt, sav;
            int n, l = 0, ready = 0;
            Compcond m, c, o;
      --- 2047,2058 ----
            return 0;
        }
        
      + /* Handle the -x ... -- part of compctl. */
      + 
        /**/
        int
        get_xcompctl(char *name, char ***av, Compctl cc, int isdef)
        {
            char **argv = *av, *t, *tt, sav;
            int n, l = 0, ready = 0;
            Compcond m, c, o;
      ***************
      *** 2468,2474 ****
        	    if ((flags & (CC_ALREG | CC_ALGLOB)) == (CC_ALREG | CC_ALGLOB))
        		putchar('a'), flags &= ~(CC_ALREG | CC_ALGLOB);
        	    while (*css) {
      ! 		if ((flags & 1) && (t & 1))
        		    putchar(*css);
        		css++;
        		flags >>= 1;
      --- 2474,2480 ----
        	    if ((flags & (CC_ALREG | CC_ALGLOB)) == (CC_ALREG | CC_ALGLOB))
        		putchar('a'), flags &= ~(CC_ALREG | CC_ALGLOB);
        	    while (*css) {
      ! 		if (flags & t & 1)
        		    putchar(*css);
        		css++;
        		flags >>= 1;
      ***************
      *** 2477,2486 ****
        	}
        	/* now flags with arguments */
        	flags = cc->mask;
      ! 	if (cc->keyvar) {
      ! 	    printf(" -k ");
      ! 	    printquoted(cc->keyvar);
      ! 	}
        	printif(cc->func, 'K');
        	printif(cc->explain, 'X');
        	printif(cc->prefix, 'P');
      --- 2483,2489 ----
        	}
        	/* now flags with arguments */
        	flags = cc->mask;
      ! 	printif(cc->keyvar, 'k');
        	printif(cc->func, 'K');
        	printif(cc->explain, 'X');
        	printif(cc->prefix, 'P');
      ***************
      *** 2555,2567 ****
        		printf(" --");
        	}
        	if (cc && cc->xor) {
      ! 	    /* print or'd (+) completions */
        	    printf(" +");
        	    if (cc->xor != &cc_default)
        		printcompctl((char *) NULL, cc->xor);
        	}
        	if (s) {
      ! 	    if (cclist & 1) {
        		putchar(' ');
        		printquoted(s);
        	    }
      --- 2558,2573 ----
        		printf(" --");
        	}
        	if (cc && cc->xor) {
      ! 	    /* print xor'd (+) completions */
        	    printf(" +");
        	    if (cc->xor != &cc_default)
        		printcompctl((char *) NULL, cc->xor);
        	}
        	if (s) {
      ! 	    if ((cclist & 1) && cc != &cc_compos &&
      ! 		    cc != &cc_default && cc != &cc_first) {
      ! 		if(s[0] == '-' || (s[0] == '+' && !s[1]))
      ! 		    printf(" -");
        		putchar(' ');
        		printquoted(s);
        	    }

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQBVAgUBMAkjMmWJ8JfKi+e9AQEJUQH9GU/lZTMaBR1VlnHissyFo7hMFHbZTY5A
xibbLzpTZ8Ya5w8ceminhP0Qi6EQv9hJqGzcp787f7hWv/2C9pXmNQ==
=w+az
-----END PGP SIGNATURE-----

Re: Compctl fixes & a query

[P.Stephenson]

A.Main@dcs.warwick.ac.uk wrote:
> On a separate matter, does anyone ever use the numerical equals
> expansion?

Yes, but tildes would be more in keeping with other syntax for
directories (~+ and ~- being sort of tied to the directory stack
anyway): also, there's no good reason for associating this behaviour
with the noequals option as is currently the case.  If implemented
properly it would even allow trailing characters after a number to be
a separate directory name, since only a / or end of word would be a
separator, unlike the present case with =<num>.  At the moment, it
doesn't look like ~<num> works at all, i.e. even with `hash -d 1 dir',
so there aren't compatibility problems there (in fact there's a bug,
since the directory will appear as ~1 in the stack).

We could possibly kludge =<num> followed by a slash or space where
<num> is not a command for the time being, but maybe going straight to
tildes is the right thing.

Now I've got my working directory called ~1, which I can't alter...

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.

Re: Compctl fixes & a query

[Vinnie Shelton]

In message <14608.199507161434@stone.dcs.warwick.ac.uk>, Zefram wrote:
>On a separate matter, does anyone ever use the numerical equals
>expansion?  (That is, =1 expands to the directory at the top of the
>stack, =2 to the next directory in the stack, etc.)

I use =1 and =2 a lot; it's in my fingers... but I suppose ~1 et al
is more consistent.  I could adapt to a change in syntax, as long as
the functionality remained.

--Vin

Re: Compctl fixes & a query

[Zefram]

>A.Main@dcs.warwick.ac.uk wrote:
>> On a separate matter, does anyone ever use the numerical equals
>> expansion?
>
>Yes, but tildes would be more in keeping with other syntax for
>directories (~+ and ~- being sort of tied to the directory stack
>anyway): also, there's no good reason for associating this behaviour
>with the noequals option as is currently the case.  If implemented
>properly it would even allow trailing characters after a number to be
>a separate directory name, since only a / or end of word would be a
>separator, unlike the present case with =<num>.

That's the basic idea.  ~whatever is a directory, but =whatever is a
file.  Also, there's no problem with ksh kompatibility, as ksh doesn't
do this (though it does have ~+ and ~-).

>                                                 At the moment, it
>doesn't look like ~<num> works at all, i.e. even with `hash -d 1 dir',
>so there aren't compatibility problems there (in fact there's a bug,
>since the directory will appear as ~1 in the stack).

Yes.  The routine that looks up a name for a directory uses whatever's
in the table, regardless of what characters are in the name (including
/, *, etc.).  The filename substitution routine will ignore a name that
starts with any non-alphabetic character or contains anything other
than alphanumerics, - or _.  It also treats ~/whatever specially, not
looking it up in the table.  Similarly ~+ and ~-, which don't go into
the table (otherwise your cwd would always appear as ~+ in the prompt,
except when you're in / or ~).

I'd like to fix the above consistency problems.  This requires a couple
of changes in behaviour:

o hash mustn't accept names that include /, or begin with + or - (note
  that no such name would be a legal parameter name).  This, in respect
  of /, would apply to command hashing too, but the PATH_DIRS option
  makes it make sense in that case.

o As an alternative to the above, the routine that looks up a name for
  a given directory must ignore names starting with + and -, or
  containing a /.  I'm not sure which of these two controls should be
  used.

o The name lookup routine that looks up the meaning of a ~ expression
  must not treat ~/ specially, but must look it up in the normal way.
  It may only treat names starting with + and - specially.

I think that, in the interests of consistency and name space
preservation, it would be a good idea to use ~+n rather than ~n, as
this reduces the number of characters that are treated specially.  ~+n
and ~-n can then be interpreted however pushd interprets +n and -n,
depending on whether PUSHD_MINUS is set or not.  What do people think
of this?

>We could possibly kludge =<num> followed by a slash or space where
><num> is not a command for the time being, but maybe going straight to
>tildes is the right thing.

It's *much* easier to change it straight to ~.

>Now I've got my working directory called ~1, which I can't alter...

hash -dr; rehash -d; hash -d 1 /; # there's always more than one way in Zsh.

-zefram

Re: Compctl fixes & a query

[Vinnie Shelton]

In message <27816.199507171717@stone.dcs.warwick.ac.uk>, Zefram wrote:
>I think that, in the interests of consistency and name space
>preservation, it would be a good idea to use ~+n rather than ~n, as
>this reduces the number of characters that are treated specially.  ~+n
>and ~-n can then be interpreted however pushd interprets +n and -n,
>depending on whether PUSHD_MINUS is set or not.  What do people think
>of this?

I think that =1 is easy to type (no shift key).  I think that ~1 is a little more annoying (1 shift).  But I think that ~+1 is too cumbersome, IMHO.

Consider this:
=n is an absolute directory reference which corresponds directly to the directory stack, ie:

src/gnu Mon 17 13:59 % dirs -v
0       /pd/src/gnu
1       ~csim
2       ~
src/gnu Mon 17 13:59 % echo =1
/vobs/devel/shared/hsd100/sim

~+1 and ~-1 would refer to relative entries on the directory stack.  I prefer the absolute naming scheme, personally.

--Vin

Re: Compctl fixes & a query

[Zefram]

>I think that =1 is easy to type (no shift key).  I think that ~1 is a
>little more annoying (1 shift).  But I think that ~+1 is too
>cumbersome, IMHO.

On a lot of keyboards, ~ and + are adjacent -- or at least close -- and
both shifted.  I find it only a little harder to type than =.

>Consider this:
>=n is an absolute directory reference which corresponds directly to
>the directory stack, ie:
[...]
>~+1 and ~-1 would refer to relative entries on the directory stack.  I
>prefer the absolute naming scheme, personally.

I'm not sure what you mean here by "absolute" and "relative" stack
entries.  My intention is that ~+n do exactly what =n currently does,
and that ~-1 do what =- currently does, with the extensions that ~-n
can be used and that those who prefer to number the stack the other way
can use their preferred notation.

-zefram

Re: Compctl fixes & a query

[P.Stephenson]

A.Main@dcs.warwick.ac.uk wrote:
> I think that, in the interests of consistency and name space
> preservation, it would be a good idea to use ~+n rather than ~n, as
> this reduces the number of characters that are treated specially.  ~+n
> and ~-n can then be interpreted however pushd interprets +n and -n,
> depending on whether PUSHD_MINUS is set or not.  What do people think
> of this?

I'm not keen on this either, it's just too long for a short cut.
Furthermore, on this keyboard ~ and + are at opposite ends of the
keyboard.  I can do both with a left shift or right shift but it's a
little messy.  I'm not very accurate with touch-typing the top row and
this maximises the difficulty.

It shouldn't be too cumbersome to check for a row of numbers followed
by either a slash or the end of the word.  Presumably named
directories are going to have to take priority anyway in case there
are numeric user names (and on the basis that if you put it there, you
want it back again).

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.

Re: Compctl fixes & a query

[Mark Borges]

>> P Stephenson(PWS) wrote on Tue, 18 Jul 95 11:27:40 +0100:
PWS> A.Main@dcs.warwick.ac.uk wrote:
>> I think that, in the interests of consistency and name space
>> preservation, it would be a good idea to use ~+n rather than ~n, as
>> this reduces the number of characters that are treated specially.  ~+n
>> and ~-n can then be interpreted however pushd interprets +n and -n,
>> depending on whether PUSHD_MINUS is set or not.  What do people think
>> of this?

PWS> I'm not keen on this either, it's just too long for a short cut.
me neither. if it's hard to type, i'd venture people won't use it. so
why bother?

PWS> Furthermore, on this keyboard ~ and + are at opposite ends of the
PWS> keyboard.
mine too (a SUN type5 PC, which I suspect there are a lot around).

if it absolutely must go on ~+n, will there be any way for the user to
customize it?

  -mb-

Re: Compctl fixes & a query

[Zefram]

>I'm not keen on this either, it's just too long for a short cut.
>Furthermore, on this keyboard ~ and + are at opposite ends of the
>keyboard.  I can do both with a left shift or right shift but it's a
>little messy.  I'm not very accurate with touch-typing the top row and
>this maximises the difficulty.

Yes.  I suppose it will have to be ~n rather than ~+n, or maybe both
could be available.  It would just be very neat to have only ~+whatever
and ~-whatever treated specially.

>It shouldn't be too cumbersome to check for a row of numbers followed
>by either a slash or the end of the word.  Presumably named
>directories are going to have to take priority anyway in case there
>are numeric user names (and on the basis that if you put it there, you
>want it back again).

There's a slight problem there if a numeric username clashes with a
directory stack reference.  Unless anyone has any major objections,
then when the next testing/beta release is made I'll code the following
semantics:

o It will not be possible to add a directory name starting with +, - or
  a digit to the hash table;

o When a directory is looked up for %~ prompt sequences and similar,
  only entries in the hash table will be used (this is actually what is
  currently done);

o When a ~ sequence is expanded, anything starting with +, - or a digit
  will not be looked up in the hash table, though the empty sequence
  (i.e. ~/whatever) will be;

o ~+ and ~- will be as they are now, ~n will refer to what =n currently
  refers to regardless of PUSHD_MINUS (is this what was meant by
  "absolute" stack references?), and (this is the only really new bit,
  does anyone want it?) ~+n and ~-n will refer to directory stack
  entries in accordance with PUSHD_MINUS.

-zefram