complete (real C) tags

complete (real C) tags

[Peter Stephenson]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

I don't think I ever posted this; it allows the new completion system to
complete tags from a TAGS or tags file (i.e. the tags used by Emacs and vi,
nothing to do with completion tags).  I have it bound to ^Xt.

I was going to send it to zshu, until I realised it didn't use style tags,
and tried to make it by sticking the _wanted stuff in front, which failed,
so I took it off again.  Only one man will know why...

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


[-- Attachment #2: _complete_tag --]
[-- Type: text/plain, Size: 1404 bytes --]

#compdef -k complete-word \C-xt

# Complete tags using either TAGS or tags.  Looks up your directory
# hierarchy to find one.  If both exist, uses TAGS.
#
# You can override the choice of tags file with $TAGSFILE (for TAGS)
# or $tagsfile (for tags).
#
# Could be rewritten by some sed expert to use sed instead of perl.

# setopt localoptions xtrace

# Tags file to look for
local c_Tagsfile=${TAGSFILE:-TAGS} c_tagsfile=${tagsfile:-tags} expl
# Max no. of directories to scan up through
integer c_maxdir=10

local c_path=
integer c_idir
while [[ ! -f $c_path$c_Tagsfile &&
         ! -f $c_path$c_tagsfile && $c_idir -lt $c_maxdir ]]; do
  (( c_idir++ ))
  c_path=../$c_path
done

if [[ -f $c_path$c_Tagsfile ]]; then
  # prefer the more comprehensive TAGS, which unfortunately is a
  # little harder to parse.
  # could do this with sed, just can't be bothered to work out how,
  # after quarter of an hour of trying, except for
  #  rm -f =sed; ln -s /usr/local/bin/perl /usr/bin/sed
  # but that's widely regarded as cheating.
  # _wanted etags expl 'emacs tags'
  compadd - \
    $(perl -ne '/([a-zA-Z_0-9]+)[ \t:;,\(]*\x7f/ &&
	    print "$1\n"' $c_path$c_Tagsfile)
elif [[ -f $c_tagspath ]]; then
  # tags doesn't have as much in, but the tag is easy to find.
  # we can use awk here.
  # _wanted vtags expl 'vi tags'
  compadd - \
    $(awk '{ print $1 }' $c_path$c_Tagsfile)
else
  return 1
fi

Re: complete (real C) tags

[Bart Schaefer]

On May 17,  3:54pm, Peter Stephenson wrote:
} Subject: complete (real C) tags
}
} I don't think I ever posted this; it allows the new completion system to
} complete tags from a TAGS or tags file (i.e. the tags used by Emacs and vi,
} nothing to do with completion tags).  I have it bound to ^Xt.

Somebody sent me a similar thing for compctl.  Hmm, where did I put it?
 
}   # could do this with sed, just can't be bothered to work out how,
}     $(perl -ne '/([a-zA-Z_0-9]+)[ \t:;,\(]*\x7f/ &&
} 	    print "$1\n"' $c_path$c_Tagsfile)

That's a valiant effort, but it doesn't agree with the way emacs parses
a TAGS file.  You'd be better off simply discarding everything after the
DEL character and also discarding all punctuation, and then treating the
remaining words on every line as if they were all candidates.  (Try using
find-tag on e.g. the word `static' in emacs sometime.)

BTW, here's the equivalent sed (actually, even slightly more accurate, if
the TAGS file is for a C or C++ program), using $'...' to interpolate \t
and \x7f.  It can still miss multiple identifiers that appear on the same
declaration line in the C source file (it picks out only the rightmost).

    sed -ne 's/^\(.*[a-zA-Z_0-9]\)[[ '$'\t'':;,()]*'$'\177''.*$/\1/' \
	-e 's/\(.*[^a-zA-Z_0-9]\)*\([a-zA-Z_0-9]*\)$/\2/p'

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: complete (real C) tags

[Peter Stephenson]

> Bart wrote:
> BTW, here's the equivalent sed (actually, even slightly more accurate, if
> the TAGS file is for a C or C++ program), using $'...' to interpolate \t
> and \x7f.  It can still miss multiple identifiers that appear on the same
> declaration line in the C source file (it picks out only the rightmost).
> 
>     sed -ne 's/^\(.*[a-zA-Z_0-9]\)[[ '$'\t'':;,()]*'$'\177''.*$/\1/' \
> 	-e 's/\(.*[^a-zA-Z_0-9]\)*\([a-zA-Z_0-9]*\)$/\2/p'

I've finally discovered why this doesn't work for me.  First, $'...''...'
is using RCQUOTES to interpolate a ' in the middle.  I suspect this is
wrong with $'...', since you can quote a single quote in that, but I'll
take counsel before trying to fix it.

Second, Solaris sed didn't seem to think much of the second pattern: it
seems to want to remove the whole line.  I've rewritten it as

   sed -ne 's/^\(.*[a-zA-Z_0-9]\)[[ '$'\t'':;,()]*'$'\177''.*$/\1/' \
       -e 's/^.*[^a-zA-Z_0-9]//' \
       -e '/^[a-zA-Z_].*/p'

and this seems to do roughly what I want.

Finally, I've noticed it's several *times* slower for a long tags list when
going through _main_complete (see Sven's patch for _complete_tag in 11459)
rather than just compadd, so I'm very tempted just to miss that out --- try
it with a full `etags -t **/*.[ch]' TAGS file for zsh: I get less than a
second with just compadd, something like five seconds with _main_complete
(on a Sun Enterprise server, too).  I suppose the problem is the huge array
being constantly set and restored as it passes through the shell functions
--- it may not have very much to do with completion as such, although I
think that saves and restores some of its state when calling functions,
too.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

PATCH: RC_QUOTES

[Peter Stephenson]

I wrote:
> I've finally discovered why this doesn't work for me.  First, $'...''...'
> is using RCQUOTES to interpolate a ' in the middle.  I suspect this is
> wrong with $'...', since you can quote a single quote in that, but I'll
> take counsel before trying to fix it.

Nobody replied.  Does anyone object to my changing it?  Given the wording
of the option description, I am even more inclined to regard this as a bug,
but I've made it explicit there, too.

Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.7
diff -u -r1.7 options.yo
--- Doc/Zsh/options.yo	2000/05/22 07:03:38	1.7
+++ Doc/Zsh/options.yo	2000/05/24 15:26:44
@@ -917,7 +917,9 @@
 cindex(quoting style, rc)
 item(tt(RC_QUOTES))(
 Allow the character sequence `tt('')' to signify a single quote
-within singly quoted strings.
+within singly quoted strings.  Note this does not apply in quoted strings
+using the format tt($')var(...)tt('), where a backslashed single quote can
+be used.
 )
 pindex(RCS)
 cindex(startup files, sourcing)
Index: Src/lex.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/lex.c,v
retrieving revision 1.6
diff -u -r1.6 lex.c
--- Src/lex.c	2000/05/23 08:20:57	1.6
+++ Src/lex.c	2000/05/24 15:26:44
@@ -1190,7 +1190,7 @@
 		    goto brk;
 		}
 		e = hgetc();
-		if (e != '\'' || unset(RCQUOTES))
+		if (e != '\'' || unset(RCQUOTES) || strquote)
 		    break;
 		add(c);
 	    }

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: RC_QUOTES

[Bart Schaefer]

On May 24,  4:34pm, Peter Stephenson wrote:
} Subject: PATCH: RC_QUOTES
}
} I wrote:
} > I've finally discovered why this doesn't work for me.  First, $'...''...'
} > is using RCQUOTES to interpolate a ' in the middle.  I suspect this is
} > wrong with $'...', since you can quote a single quote in that, but I'll
} > take counsel before trying to fix it.
} 
} Nobody replied.  Does anyone object to my changing it?

Do we know what other shells that have $'...' do?  (Probably none of
them have rc_quotes ....)

Absent other information, I believe you've made the right patch.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: RC_QUOTES

[Peter Stephenson]

Bart wrote:
> Do we know what other shells that have $'...' do?  (Probably none of
> them have rc_quotes ....)

They don't seem to.  It's come from BASIC rather than any other shell, as
far as I can see.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: complete (real C) tags

[Peter Stephenson]

Sven wrote:
>   Actually, I've been tempted from the beginning to allow compadd to
>   get the matches not only from its positional parameters, but also
>   from arrays whose names are given as arguments. That would allow us
>   to stuff the matches into some array and then call:
> 
>     foo=(...)
>     _wanted ... compadd -a foo
> 
>   or some such.

This sounds a simple and effective solution.  I presume it could be done
with minimal changes --- just modify compadd argument handling and then
pass down the argument `-a carefully_chosen_parameter_name' (so as no to
clash with any parameters in the middle).

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: complete (real C) tags

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> Finally, I've noticed it's several *times* slower for a long tags list when
> going through _main_complete (see Sven's patch for _complete_tag in 11459)
> rather than just compadd, so I'm very tempted just to miss that out --- try
> it with a full `etags -t **/*.[ch]' TAGS file for zsh: I get less than a
> second with just compadd, something like five seconds with _main_complete
> (on a Sun Enterprise server, too).  I suppose the problem is the huge array
> being constantly set and restored as it passes through the shell functions
> --- it may not have very much to do with completion as such, although I
> think that saves and restores some of its state when calling functions,
> too.

Only the $words, $PREFIX, $etc. parameters.

But yes, I noticed that, too. I see two `solutions' (until we have a
better parameter code, although I'm not sure how much that could be
improved, all those "$@"...):

- Suggest that at least in cases where huge lists of matches can be
  generated, the matches are generated as late as possible, using
  utility functions. The problem here is that to make it really fast,
  _wanted would have to be called with the name of the utility
  function and that only generates the matches and calls compadd with
  the arguments it got from _wantd/_all_labels.
  For some of the utility functions we have, this would mean to split
  them in two.
- Allow some option or whatever to _wanted and friends which says that 
  the command strings should be expanded at the very end, so that we
  only pass the string '$(sed...)' around.
- This could also be done by a new utility function which would be
  called instead of compadd and itself expands its arguments and call
  compadd with the result.
  Actually, I've been tempted from the beginning to allow compadd to
  get the matches not only from its positional parameters, but also
  from arrays whose names are given as arguments. That would allow us
  to stuff the matches into some array and then call:

    foo=(...)
    _wanted ... compadd -a foo

  or some such.
  That could be combined with the `...expands its arguments'. I.e., we 
  could add a utility function (`_compadd' ? >:->) that only calls
  compadd, but allows taking the matches from arrays, or from the keys 
  of named associations or that (all this selected via options)
  expands its arguments to get the matches. But I still think it would 
  be nice to put that in the C-code for compadd, to avoid even the
  final expansion of the array.

And of course, with something like these tags, I would use caching, at 
least if the stat module is available so that we can compare file
modification times.


That enhancement to compadd and/or the compadd-wrapper function... any 
opinions from anyone?

Bye
 Sven


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