From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: tags completion bug Date: Tue, 24 Sep 2002 11:31:50 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200209241531.g8OFVoW06623@rum.cs.yale.edu> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1032881589 22779 127.0.0.1 (24 Sep 2002 15:33:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 24 Sep 2002 15:33:09 +0000 (UTC) Cc: Emacs developers Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17trgR-0005vG-00 for ; Tue, 24 Sep 2002 17:33:07 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17tsNG-0004FL-00 for ; Tue, 24 Sep 2002 18:17:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17trgW-0003lH-00; Tue, 24 Sep 2002 11:33:12 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17trfL-0003cL-00 for emacs-devel@gnu.org; Tue, 24 Sep 2002 11:31:59 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17trfH-0003c8-00 for emacs-devel@gnu.org; Tue, 24 Sep 2002 11:31:58 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17trfG-0003c2-00; Tue, 24 Sep 2002 11:31:54 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g8OFVoW06623; Tue, 24 Sep 2002 11:31:50 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Francesco Potorti` Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8147 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8147 > 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