emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#20629: closed (25.0.50; Regression: TAGS broken, c


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#20629: closed (25.0.50; Regression: TAGS broken, can't find anything in C++ files.)
Date: Sat, 19 Mar 2016 18:46:01 +0000

Your message dated Sat, 19 Mar 2016 20:45:20 +0200
with message-id <address@hidden>
and subject line Re: bug#20629: 25.0.50; Regression: TAGS broken, can't find 
anything in C++ files.
has caused the debbugs.gnu.org bug report #20629,
regarding 25.0.50; Regression: TAGS broken, can't find anything in C++ files.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
20629: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20629
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 25.0.50; Regression: TAGS broken, can't find anything in C++ files. Date: Fri, 22 May 2015 07:57:38 +0200 User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
Hello.

Create this file as x.cc
-----------------------------------------------------------------------
class XX
{
public:
    int foo();
    void bar();
};

int
XX::foo()
{
    return 1;
}

void
XX::bar()
{
    foo();
}

int
main(int argc, char *argv[])
{
    XX xx;
    xx.bar();
    return 0;
}

-----------------------------------------------------------------------

Run etags on it:

% etags x.cc

In emacs, load the TAGS file, put the cursor on bar in xx.bar in main and press ESC .
Emacs says: "No known definitions for: bar".
Put cursor on foo in foo(); in XX::bar(), press ESC .
Emacs says: "No known definitions for: foo".

If you do the same thing in 24.5, it works as expected, i.e. the cursor
jumps to respective member definition.
The TAGS file produced by trunk etags and 24.5 etags are exactly the same.

This regression makes the etags feature totally useless for C++.

     Jan D.




In GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.3.0, NS appkit-1347.57 Version 10.10.3 (Build 14D136))
 of 2015-05-22 on <anon>
Windowing system distributor `Apple', version 10.3.1347
Configured using:
 `configure --enable-checking --verbose --with-ns --without-x CFLAGS=-g'

Configured features:
ACL LIBXML2 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: sv_SE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++/l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Starting a new list of tags tables
user-error: No known definitions for: bar
user-error: No known definitions for: foo

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils etags thingatpt xref cl-seq ring
eieio byte-opt gv bytecomp byte-compile cl-extra seq cconv eieio-core
cl-loaddefs pcase cl-lib cc-mode cc-fonts easymenu cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel ns-win term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 107206 5916)
 (symbols 48 21504 1)
 (miscs 40 49 143)
 (strings 32 21487 4677)
 (string-bytes 1 738790)
 (vectors 16 15321)
 (vector-slots 8 438795 3143)
 (floats 8 151 24)
 (intervals 56 245 4)
 (buffers 976 13))



--- End Message ---
--- Begin Message --- Subject: Re: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files. Date: Sat, 19 Mar 2016 20:45:20 +0200
> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 27 Nov 2015 05:54:39 +0200
> 
> On 11/26/2015 06:32 PM, Eli Zaretskii wrote:
> 
> > It wasn't done because the discussion didn't reach any consent.
> 
> FWIW, I left it with understanding that we should learn to generate both 
> qualified and unqualified tag names for C++. Whether to do that by 
> default or not, I'm not sure.
> 
> But Exuberant Ctags defaults to the latter option, and only generates 
> unqualified tag names by default. It would be a good idea to follow 
> suit, for consistency if nothing else.
> 
> And I'd like to revisit your previous comment:
> 
>  > Including the pattern (what you call "the implicit tag") in the
>  > completion table could serve as context for disambiguating otherwise
>  > similar tag names.
> 
> Even if that can work in many cases (patterns are displayed in the xref 
> buffer, for example), pattern won't necessarily contain the qualified 
> name either.
> 
> In Java, it never will, as long as the pattern is created from the 
> contents of the line with the method's definition (because there's no 
> class name on that line).
> 
> In C++, it won't if the method is defined inside the class definition 
> (Java-style), which seems to be recommended for short methods.

As we now have a dedicated feature request (bug#22995), I'm closing
this bug.


--- End Message ---

reply via email to

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