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