tags completion bug

tags completion bug

[Francesco Potorti`]

This is a request for opinion.  There are two questions:
1) should I change the function etags-tags-completion-table? (NO)
2) should I move the latest etags.c to the RC branch?	     (YES)

================ 1)
Following a bug report, I discovered that tags completion (on the
pretest branch) is less than optimal, in that a C definition like this:

   char **tab_fill(char *str, char delim)
   {
   }

generates a completion like `**tab_fill', rather than `tab_fill' if you
ask for tag completion with TAB after M-..  The etags shipped with the
RC branch generates for this an entry like:

   char **tab_fill(^?0,1129

which is an unnamed entry (an entry for which the tag name is not
explicitely specified).

The function etags-tags-completion-table, which is used to build the
completion table, uses the tag name if present, else it tries to guess a
reasonable tag name.  For I don't know which reason, it consideres good
candidates for a tag name all the characters in "-a-zA-Z0-9_+*$?:".
Namely, I am not sure why the asterisk, plus and question mark are
there.

Does anyone know?  Should I change the current behaviour, by excluding
asterisk, plus and question mark?  This change would cure the observed
bug, but could prevent the etags-tags-completion-table from guessing the
names of some legitimate tags.

================ 2)
However, in the trunk Emacs, this problem is not apparent, because the
new etags.c generates a tag entry like this:

   char **tab_fill(^?tab_fill^A70,1129

which is a named entry with the correct function name, so the completion
table is correctly built.  The new etags.c, in fact, creates a named tag
whenever etags.el would make a mistake, so using the new etags.c cures
the problem as well.

This means that etags-tags-completion-table will not err on tags files
created by the new etags.c, whether it is changed or not, but a change
would influence its behaviour when using old tags files.

================
I suggest that nothing be changed on the trunk, and possibly that the
new etags.c is installed on the pretest (RC) branch.

Re: tags completion bug

[Stefan Monnier]

> This is a request for opinion.  There are two questions:
> 1) should I change the function etags-tags-completion-table? (NO)
> 2) should I move the latest etags.c to the RC branch?	     (YES)
> 
> ================ 1)
> Following a bug report, I discovered that tags completion (on the
> pretest branch) is less than optimal, in that a C definition like this:
> 
>    char **tab_fill(char *str, char delim)
>    {
>    }
> 
> generates a completion like `**tab_fill', rather than `tab_fill' if you
> ask for tag completion with TAB after M-..  The etags shipped with the
> RC branch generates for this an entry like:
> 
>    char **tab_fill(^?0,1129
> 
> which is an unnamed entry (an entry for which the tag name is not
> explicitely specified).
> 
> The function etags-tags-completion-table, which is used to build the
> completion table, uses the tag name if present, else it tries to guess a
> reasonable tag name.  For I don't know which reason, it consideres good
> candidates for a tag name all the characters in "-a-zA-Z0-9_+*$?:".
> Namely, I am not sure why the asterisk, plus and question mark are
> there.
> 
> Does anyone know?  Should I change the current behaviour, by excluding
> asterisk, plus and question mark?  This change would cure the observed
> bug, but could prevent the etags-tags-completion-table from guessing the
> names of some legitimate tags.

Isn't there a convention of when to use an explicit tagname and when
to use an implicit one (i.e. an unnamed entry) when generating the
TAGS file?
If this convention assumes that * would be part of the tagname, then
etags.c should be changed to use an explicitly named entry in the above
example, otherwise etags.el should be changed as you suggest so as not
to take the * as part of the tagname.

Looking at the comment before make_tag in etags.c it seems that * should
indeed be considered as part of the implicit tagname, so the bug is in
etags.c (it shouldn't have used an implicitly named entry).

> However, in the trunk Emacs, this problem is not apparent, because the
> new etags.c generates a tag entry like this:
> 
>    char **tab_fill(^?tab_fill^A70,1129
> 
> which is a named entry with the correct function name, so the completion
> table is correctly built.  The new etags.c, in fact, creates a named tag
> whenever etags.el would make a mistake, so using the new etags.c cures
> the problem as well.

Looks right.

> This means that etags-tags-completion-table will not err on tags files
> created by the new etags.c, whether it is changed or not, but a change
> would influence its behaviour when using old tags files.

Changing etags.el would also mean that it would fail to get the proper
name if the implicit entry's name contains * (which is frequent in
CommonLisp code, for example).

> I suggest that nothing be changed on the trunk,

100% agreement.


	Stefan

Re: tags completion bug

[Francesco Potorti`]

   Isn't there a convention of when to use an explicit tagname and when
   to use an implicit one (i.e. an unnamed entry) when generating the
   TAGS file?

There is one, but it is very recent, newer thatn the etags.c in the RC
branch.  The conventions is described in etc/ETAGS.EBNF.
   
   Looking at the comment before make_tag in etags.c it seems that * should
   indeed be considered as part of the implicit tagname, so the bug is in
   etags.c (it shouldn't have used an implicitly named entry).

The etags.c that is in the RC branch is older than that convention,
which defines what an implicitly named entry is.  I was suggesting to
put the new etags.c on the RC branch.
   
   Changing etags.el would also mean that it would fail to get the proper
   name if the implicit entry's name contains * (which is frequent in
   CommonLisp code, for example).

Okay, that is an answer to my first question, thanks.  This means that
etags.el should not be changed.

Re: tags completion bug

[Francesco Potorti`]

Hi Roland, hi Gerd,

I see that in etags-tags-completion-table you added the characters
"+*:?"  as legitimate in an identifier.  Stefan Monnier on emacs-devel
pointed out that the asterisk is used in Common Lisp.  What are the
other characters for?  I'd like to write this info in a comment inside
the function.

Also, would it be reasonable to use \(\sw\|\s_\), instead of the
bracketed lists of characters?


(defun etags-tags-completion-table ()
  (let ((table (make-vector 511 0)))
    (save-excursion
      (goto-char (point-min))
      ;; This monster regexp matches an etags tag line.
      ;;   \1 is the string to match;
      ;;   \2 is not interesting;
      ;;   \3 is the guessed tag name; XXX guess should be better eg DEFUN
      ;;   \4 is not interesting;
      ;;   \5 is the explicitly-specified tag name.
      ;;   \6 is the line to start searching at;
      ;;   \7 is the char to start searching at.
      (while (re-search-forward
	      "^\\(\\([^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
	      nil t)
	(intern	(if (match-beginning 5)
		    ;; There is an explicit tag name.
		    (buffer-substring (match-beginning 5) (match-end 5))
		  ;; No explicit tag name.  Best guess.
		  (buffer-substring (match-beginning 3) (match-end 3)))
		table)))
    table))

Re: tags completion bug

[Gerd Moellmann]

Francesco Potorti` <pot@gnu.org> writes:

> I see that in etags-tags-completion-table you added the characters
> "+*:?"  as legitimate in an identifier.  Stefan Monnier on emacs-devel
> pointed out that the asterisk is used in Common Lisp.  What are the
> other characters for?

`+' is conventionally used in Common Lisp for constants like
(defconstant +a-constant+ 42).

`?' is used in Scheme (and sometimes in CL) for predicates, for
instance `(define (some-predicate? x) ...)'.

Alas, I don't remember what the `:' is for.  Maybe for symbols, in CL,
that include package names, like in `(defun some-package:some-symbol
() ...)'?

> I'd like to write this info in a comment inside the function.
> 
> Also, would it be reasonable to use \(\sw\|\s_\), instead of the
> bracketed lists of characters?

I guess that would make sense.

I could think of other characters that are currently not in the
completion table, like `!' that's used in Scheme, as in `(define
(modify!  something) ...)', or maybe `%' that's conventionally used in
CL for internal-use-only functions, `(defun %internal-function ()
...)'.