emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tags completion bug


From: Francesco Potorti`
Subject: tags completion bug
Date: Tue, 24 Sep 2002 16:36:59 +0200

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]