[PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Don Mullis]

`make TAGS` produces a TAGS that causes the emacs v22.0.92 command 
'M-x tags-search' to repeatedly stop with complaints about missing files.
Proximate cause of this is "#line" directives in Linux source files.

`make tags` produces hundreds of lines of complaints about duplicate
entries.

The following ugly patch works around these problems.  Posting to
both kbuild-devel and emacs-devel in hopes something better can be worked out
for the Emacs v22 release.

---
 Makefile |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Index: linux-2.6/Makefile
===================================================================
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -1337,6 +1337,18 @@ define xtags
 		--langdef=dotconfig \
 		--language-force=dotconfig \
 		--regex-dotconfig='/^#?[[:blank:]]*(CONFIG_[[:alnum:]_]+)/\1/'; \
+	elif $1 --version 2>&1 | grep -iq 'ctags.* 22\.'; then \
+	    $(all-sources) | xargs $1 -a -w; \
+	    $(all-kconfigs) | xargs $1 -a -w \
+		--regex='/^[ \t]*config[ \t]+\([a-zA-Z0-9_]+\)/\1/'; \
+	    $(all-defconfigs) | xargs -r $1 -a -w \
+		--regex='/^#?[ \t]?\(CONFIG_[a-zA-Z0-9_]+\)/\1/'; \
+	elif $1 --version 2>&1 | grep -iq 'etags.* 22\.'; then \
+	    $(all-sources) | xargs $1 -a --no-line-directive; \
+	    $(all-kconfigs) | xargs $1 -a --no-line-directive \
+		--regex='/^[ \t]*config[ \t]+\([a-zA-Z0-9_]+\)/\1/'; \
+	    $(all-defconfigs) | xargs -r $1 -a --no-line-directive \
+		--regex='/^#?[ \t]?\(CONFIG_[a-zA-Z0-9_]+\)/\1/'; \
 	elif $1 --version 2>&1 | grep -iq emacs; then \
 	    $(all-sources) | xargs $1 -a; \
 	    $(all-kconfigs) | xargs $1 -a \

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Masatake YAMATO]

> `make TAGS` produces a TAGS that causes the emacs v22.0.92 command 
> 'M-x tags-search' to repeatedly stop with complaints about missing files.
> Proximate cause of this is "#line" directives in Linux source files.

Which symbol did you search to reproduce the stopping?

Masatake YAMATO

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Don Mullis]

On Mon, 2006-12-25 at 14:41 +0900, Masatake YAMATO wrote:
> > `make TAGS` produces a TAGS that causes the emacs v22.0.92 command 
> > 'M-x tags-search' to repeatedly stop with complaints about missing files.
> > Proximate cause of this is "#line" directives in Linux source files.
> 
> Which symbol did you search to reproduce the stopping?

"asdfjkl" will do it.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>> > `make TAGS` produces a TAGS that causes the emacs v22.0.92 command 
>> > 'M-x tags-search' to repeatedly stop with complaints about missing files.
>> > Proximate cause of this is "#line" directives in Linux source files.
>> 
>> Which symbol did you search to reproduce the stopping?
>
>"asdfjkl" will do it.

I am working on it.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>`make TAGS` produces a TAGS that causes the emacs v22.0.92 command 
>'M-x tags-search' to repeatedly stop with complaints about missing files.
>Proximate cause of this is "#line" directives in Linux source files.

I cannot reproduce this on a 2.6.18 Linux tree with Emacs 22.0.91.

By the way, I did not know that 22.0.92 was out.  Would someone please
tell me where I can download it?

Anyway, etags has not changed in that respect since 22.0.91.  Would you
please detail precisely the steps you followed to trigger the bug?  And,
just to be sure, please let me know the output of 
 strings `which etags` | fgrep revision

>`make tags` produces hundreds of lines of complaints about duplicate
>entries.

This also happens with the Emacs 21 version of etags.  Olaf Dabrunz once
suggested that ctags optionally allows for duplicate entries, which
modern versions of vi can handle.

Do people think that this would be a good idea?  If you want to try out
the result, look for "if (!dif)" in the source and disable that piece of
code.  I do not use vi myself, so I cannot thest this reliably.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Don Mullis]

On Tue, 2006-12-26 at 15:13 +0100, Francesco Potorti` wrote:
> >`make TAGS` produces a TAGS that causes the emacs v22.0.92 command 
> >'M-x tags-search' to repeatedly stop with complaints about missing files.
> >Proximate cause of this is "#line" directives in Linux source files.
> 
> I cannot reproduce this on a 2.6.18 Linux tree with Emacs 22.0.91.
> 
> By the way, I did not know that 22.0.92 was out.  Would someone please
> tell me where I can download it?

ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.92.tar.gz  

> Anyway, etags has not changed in that respect since 22.0.91.  Would you
> please detail precisely the steps you followed to trigger the bug?  

The bug only appears if some `make *config` has succeeded.  Try:

	make allnoconfig
	make TAGS

I have verified that the above shows the bug with 2.6.18 Linux.

> And,
> just to be sure, please let me know the output of 
>  strings `which etags` | fgrep revision
        
        $ strings `which etags` | fgrep revision
        @(#) pot revision number is $Revision$

More usefully:

        $ etags --version
        etags (standalone 22.0.92)
        Copyright (C) 2006 Free Software Foundation, Inc. and Ken Arnold
        This program is distributed under the same terms as Emacs

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Richard Stallman]

    This also happens with the Emacs 21 version of etags.  Olaf Dabrunz once
    suggested that ctags optionally allows for duplicate entries, which
    modern versions of vi can handle.

Could you explain more clearly what this change means?
What does it mean to have "duplicate entries", and what would they do?

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>The bug only appears if some `make *config` has succeeded.  Try:
>
>	make allnoconfig
>	make TAGS
>
>I have verified that the above shows the bug with 2.6.18 Linux.

Okay, I found out why and corrected it.  Please try it yourself and let
me know.  Thank you for finding this bug.

This is the relevant Changelog entry:

2006-12-28  Francesco Potortì  <pot@gnu.org>

	* etags.c (readline): When creating a relative file name from a
	#line directive, leave the file name alone.  The previous
	behaviour was to make it relative to the tags file directory,
	under the hypothesis that the #line directive file name was
	relative to the directory of the tagged file.  That hypothesis is
	wrong with Cpp and Lex.

and this is the patch:

@@ -6285,7 +6285,7 @@ readline (lbp, stream)
 		  name = lbp->buffer + start;
 		  *endp = '\0';
 		  canonicalize_filename (name); /* for DOS */
-		  taggedabsname = absolute_filename (name, curfdp->infabsdir);
+		  taggedabsname = absolute_filename (name, tagfiledir);
 		  if (filename_is_absolute (name)
 		      || filename_is_absolute (curfdp->infname))
 		    taggedfname = savestr (taggedabsname);

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Don Mullis]

> and this is the patch:
> 
> @@ -6285,7 +6285,7 @@ readline (lbp, stream)
>  		  name = lbp->buffer + start;
>  		  *endp = '\0';
>  		  canonicalize_filename (name); /* for DOS */
> -		  taggedabsname = absolute_filename (name, curfdp->infabsdir);
> +		  taggedabsname = absolute_filename (name, tagfiledir);
>  		  if (filename_is_absolute (name)
>  		      || filename_is_absolute (curfdp->infname))
>  		    taggedfname = savestr (taggedabsname);

Thanks, that does fix the bug.

There is another inconvenience, one you may have noticed also -- upon visiting 
the TAGS file emacs complains about its size and requires confirmation before
continuing.  This is a bit of a nuisance for someone who mostly uses TAGS with
big programs such as the Linux kernel.  My scan of 
"customization buffer for group Etags" just now did not turn up a way to disable it.
Is there a way?

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>Thanks, that does fix the bug.

Good.  I installed it.  I am goiong to look at the other minor problems now.

>There is another inconvenience, one you may have noticed also -- upon visiting 
>the TAGS file emacs complains about its size and requires confirmation before
>continuing.  

This is a new Emacs feature, which is not dependent on tags.  Form the
NEWS file:

*** If the user visits a file larger than
    `large-file-warning-threshold', Emacs asks for confirmation.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Richard Stallman]

    There is another inconvenience, one you may have noticed also -- upon visiting 
    the TAGS file emacs complains about its size and requires confirmation before
    continuing.

This is controlled by large-file-warning-threshold.  It would be ok to
create a separate such variable to apply to tags files only;
visit-tags-table could bind large-file-warning-threshold to that other
value.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>    This also happens with the Emacs 21 version of etags.  Olaf Dabrunz once
>    suggested that ctags optionally allows for duplicate entries, which
>    modern versions of vi can handle.
>
>Could you explain more clearly what this change means?
>What does it mean to have "duplicate entries", and what would they do?

Inside a tags file as generated by Emacs' Ctags, tag names are unique.
For example, Linux defines macros with the same name in different source
files, with alternative implementations.  While Etags tags them all,
Ctags does not.  There is nothing preventing Ctags from doing that, it
simply refuses to do it.

In a year-old mail, Olaf Dabrunz suggested to me that this behaviour of
Ctags, which I inherited, is there for compatibility with old editors,
like the original Vi, while Vim can take advantage of duplicate entries.
He then suggested that Ctags optionally allows for duplicate tags, which
is a trivial change.

Now I am asking: is there really any reason why Ctags should not create
duplicate entries?  Why not creating duplicate entries by default?  The
only drawback would be that the old Vi would jump to an unpredictable
one, but the current behaviour is not much better, because only the
first duplicate tag is created, the others are not included in the tags
file.

Olaf Dabrunz cites this proposed standard, used by at least Exhuberant
ctags and Vim: <http://ctags.sourceforge.net/FORMAT>, where the issue is
better explained.

In summary, I have three proposals for a change to Ctags, preferred first:

1. Duplicate entries are created, no warnings issued
2. Duplicate entries are created, warnings issued as they are now
3. An option is provided to create duplicate entries

If a consensus is reached quickly, I can do the change now, during the
pretest phase.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Don Mullis]

On Fri, 2006-12-29 at 17:58 -0500, Richard Stallman wrote:
>     There is another inconvenience, one you may have noticed also -- upon visiting 
>     the TAGS file emacs complains about its size and requires confirmation before
>     continuing.
> 
> This is controlled by large-file-warning-threshold.  It would be ok to
> create a separate such variable to apply to tags files only;
> visit-tags-table could bind large-file-warning-threshold to that other
> value.

Thanks for the explanation.

Judging only from my own modest user experience, the common 
large-file-warning-threshold seems adequate to the purpose.
Perhaps now might be a good time to raise the default value, though.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Richard Stallman]

    Now I am asking: is there really any reason why Ctags should not create
    duplicate entries?  Why not creating duplicate entries by default?  The
    only drawback would be that the old Vi would jump to an unpredictable
    one, but the current behaviour is not much better, because only the
    first duplicate tag is created, the others are not included in the tags
    file.

That seems plausible.  And why care about the old (non-free) vi anyway?

    Olaf Dabrunz cites this proposed standard, used by at least Exhuberant
    ctags and Vim: <http://ctags.sourceforge.net/FORMAT>, where the issue is
    better explained.

I cannot access that page.  If this is relevant, would you please
explain how?

    In summary, I have three proposals for a change to Ctags, preferred first:

    1. Duplicate entries are created, no warnings issued
    2. Duplicate entries are created, warnings issued as they are now
    3. An option is provided to create duplicate entries

I see no harm in #1 if that is what people would generally prefer.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Richard Stallman]

    Judging only from my own modest user experience, the common 
    large-file-warning-threshold seems adequate to the purpose.
    Perhaps now might be a good time to raise the default value, though.

10 meg seems like a reasonable value to me.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

After checking the behaviour of Exuberant ctags, I decided to follow the
same route and allow for duplicated tags in ctags mode.  I added an
undocumented option --no-duplicates, just for emergency, that may be
deleted in a future release of Etags.  I also undocumented the existing
--no-warn option.

If anyone wants to comment on this change, please let me know.

On a related issue, the Exuberant ctags standard for an extended Vi tags
format is described at <http://ctags.sourceforge.net/FORMAT>, and is
currently implemented and supported at least by Vim.  I am willing to
implement it in Etags, when it is working in ctags mode.  Again, if
anyone wants to comment on this, please let me know.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Frank Schmitt]

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

> After checking the behaviour of Exuberant ctags, I decided to follow the
> same route and allow for duplicated tags in ctags mode.  I added an
> undocumented option --no-duplicates, just for emergency, that may be
> deleted in a future release of Etags.  I also undocumented the existing
> --no-warn option.
>
> If anyone wants to comment on this change, please let me know.
>
> On a related issue, the Exuberant ctags standard for an extended Vi tags
> format is described at <http://ctags.sourceforge.net/FORMAT>, and is
> currently implemented and supported at least by Vim.  I am willing to
> implement it in Etags, when it is working in ctags mode.  Again, if
> anyone wants to comment on this, please let me know.

Why shipping an own ctags/etags implementation at all? I mean Exuberant
ctags works really well (at least in my experience as a C++ coder much
better than the Emacs etags) and it's GPL software.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Richard Stallman]

    On a related issue, the Exuberant ctags standard for an extended Vi tags
    format is described at <http://ctags.sourceforge.net/FORMAT>, and is
    currently implemented and supported at least by Vim.  I am willing to
    implement it in Etags, when it is working in ctags mode.

This would be something for after the release.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Eli Zaretskii]

> Date: Tue, 02 Jan 2007 12:41:40 +0100
> From: Francesco Potorti` <pot@gnu.org>
> Cc: Don Mullis <dwm@meer.net>, Olaf Dabrunz <od@suse.de>,
> 	Darren Hiebert <darren@users.sourceforge.net>,
> 	Bram Moolenaar <Bram@vim.org>, emacs-devel@gnu.org
> 
> After checking the behaviour of Exuberant ctags, I decided to follow the
> same route and allow for duplicated tags in ctags mode.  I added an
> undocumented option --no-duplicates, just for emergency, that may be
> deleted in a future release of Etags.  I also undocumented the existing
> --no-warn option.
> 
> If anyone wants to comment on this change, please let me know.

Should this change in behavior be mentioned in etc/NEWS?

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>    On a related issue, the Exuberant ctags standard for an extended Vi tags
>    format is described at <http://ctags.sourceforge.net/FORMAT>, and is
>    currently implemented and supported at least by Vim.  I am willing to
>    implement it in Etags, when it is working in ctags mode.
>
>This would be something for after the release.

Sure.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>> After checking the behaviour of Exuberant ctags, I decided to follow the
>> same route and allow for duplicated tags in ctags mode.  I added an
>> undocumented option --no-duplicates, just for emergency, that may be
>> deleted in a future release of Etags.  I also undocumented the existing
>> --no-warn option.
>> 
>> If anyone wants to comment on this change, please let me know.
>
>Should this change in behavior be mentioned in etc/NEWS?

I did not because the Emacs manual does not mention the ctags
functionalities of etags at all.  But maybe yes, since it is only a
couple of lines in an already huge file, it probably makes sense.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

>Why shipping an own ctags/etags implementation at all? I mean Exuberant
>ctags works really well

The reason etags is there is fundamentally that it always was there, and
that it works well.  Its maintenance has very low cost (I do it myself,
and I spend very little time on it), and having two more or less
equivalent implementation is not a bad thing, until they are
approximately the same quality.  Finally, etags' copyright is FSF's,
like most GNU software.

That said, your question makes a lot of sense.  Duplicating effort is
not a wise thing.  For a start, I worked a lot with Xemacs people in the
past, and we succeded in using the exact same version of etags for both
the Emacs and the Xemacs distributions.

As far as four years ago, I had a brief mail exchange with Darren
Hiebert, the author of exuberant ctags.  We both said we were interested
in studying the possibility of dropping etags in favour of exctags
(short for the real name), but no one of us had then the time to do a
deeper research on the relative strenghts and weaknesses.

What I discovered by then (note, four years ago) is that:
- etags was faster and generated a smaller tags file
- exctags has a much cleaner code, which is probably easier to maintain
- etags made a slightly better job at tagging complex C/C++ constructs
- etags knew about some structures for Emacs code (DEFUN, etc.)
- etags had a slightly wider choice of known languages
- exctags has an -R option for recursively tagging files in a dir tree
- exctags has a way of specifying some constructs on the command line

In fact, the only really significant differences I found was the code
cleanliness of exctags, and the -R option.  The former is really
important only for the C/C++ parsing, which in etags is really
unreadable, but incredibly it works very well.  The latter *the -R
option) is very nice, but I never had the time to implement it in etags.

Since then, maybe exctags has progressed.  Etags has progressed little,
but something was done:
- etags recognises and parses #line directives
- etags supports regular expressions with regexp modifiers à la Perl
- etags now parses Html, Lua, Php and, to a lesser extent, Forth

>(at least in my experience as a C++ coder much better than the Emacs
>etags) and it's GPL software.

I am interested in this.  Have you ever tried the version of ctags in
pretest?  Even if in pretest, it is quite mature, and should perform
better than the etags shipped with Emacs 21.  Would you send me a source
file where exctags performs better than etags?

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Frank Schmitt]

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

>>(at least in my experience as a C++ coder much better than the Emacs
>>etags) and it's GPL software.
>
> I am interested in this.  Have you ever tried the version of ctags in
> pretest?  Even if in pretest, it is quite mature, and should perform
> better than the etags shipped with Emacs 21.  Would you send me a source
> file where exctags performs better than etags?

Sorry, I don't have an example at hand, because my switch was somewhere
in summer. But I used emacs CVS head etags till then and had problems,
that a special case of templated functions in C++ were not listed in
TAGS. I'll switch back to Emacs etags and report when I find something
which Emacs etags doesn't tag.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Frank Schmitt]

Frank Schmitt <ich@frank-schmitt.net> writes:

> Sorry, I don't have an example at hand, because my switch was somewhere
> in summer. But I used emacs CVS head etags till then and had problems,
> that a special case of templated functions in C++ were not listed in
> TAGS. I'll switch back to Emacs etags and report when I find something
> which Emacs etags doesn't tag.

I did some testing and found out that I just didn't RTFM. Emacs etags
defaults to not TAG member variables of C++ classes (which doesn't make
much sense in my eyes) while exuberant ctags does tag those. However
after aliasing etags to etags --members it works just as well for me as
exuberant ctags does.

One question though: Say I have a class like this:

template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels, typename ipc3dLinkControl, typename ipc3dLinkControlSetup>
class CMultiChannelCSC19_3D
{
public:
	ipc3dLinkControlSetup setup;
	ipc3dCSC19<ipc3dIslandHierarchy,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipc3dLinkControl> mcCSC; 
	advTimer cscInitTime;
	advTimer cscSegmentationTime;
	advTimer outputTime;
	void execute(CPluginCSCState& p, int w, int h, int d, const ipcMultiChannel<ipc3dChannelType,numOfChannels>* orgImage, ipcMultiChannel<ipc3dChannelType,numOfChannels>* regionImage, unsigned int* mapImage, ipc3dBlockCompressedLabelImage* compressedMapImage=NULL)
	{
		if (orgImage!=NULL)
		{
				  //do something
		}
	}
};

what Emacs etags generates is

foo.h,936
template <typename ipc3dIslandHierarchy,1,0
template <typename ipc3dIslandHierarchy, typename ipc3dChannelType,1,0
template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels,1,0
template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels, typename ipc3dLinkControl,1,0
class CMultiChannelCSC19_3D2,151
	ipc3dLinkControlSetup setup;CMultiChannelCSC19_3D::setup5,189
	ipc3dCSC19<CMultiChannelCSC19_3D::ipc3dCSC196,219
	ipc3dCSC19<ipc3dIslandHierarchy,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipc3dLinkControl> mcCSC;CMultiChannelCSC19_3D::mcCSC6,219
	advTimer cscInitTime;CMultiChannelCSC19_3D::cscInitTime7,374
	advTimer cscSegmentationTime;CMultiChannelCSC19_3D::cscSegmentationTime8,397
	advTimer outputTime;CMultiChannelCSC19_3D::outputTime9,428
	void execute(CMultiChannelCSC19_3D::execute10,450

while exuberant ctags skips those first four lines:

foo.h,680
class CMultiChannelCSC19_3DCMultiChannelCSC19_3D2,151
	ipc3dLinkControlSetup setup;setup5,189
	ipc3dCSC19<ipc3dIslandHierarchy,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipc3dLinkControl> mcCSC; mcCSC6,219
	advTimer cscInitTime;cscInitTime7,374
	advTimer cscSegmentationTime;cscSegmentationTime8,397
	advTimer outputTime;outputTime9,428
	void execute(CPluginCSCState& p, int w, int h, int d, const ipcMultiChannel<ipc3dChannelType,numOfChannels>* orgImage, ipcMultiChannel<ipc3dChannelType,numOfChannels>* regionImage, unsigned int* mapImage, ipc3dBlockCompressedLabelImage* compressedMapImage=NULL)execute10,450

what do they mean?

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`

[Francesco Potorti`]

Sorry for the delay in my response.  Frank, you had written:

>One case I've just found: For the following class Emacs etags fails to
>tag the class members and adds some strange lines for the template
>parameters while exuberant ctags gives a much nicer result (see below)

In fact, that happens when etags is called without the --members option.
What I usually do is calling it with both --declarations and --members,
whose meaning is:
--declarations
	In C and derived languages, create tags for function declarations,
	and create tags for extern variables unless --no-globals is used.
--members
	Create tag entries for members of structures in some languages.

The reason why these are not the default is for compatibility with the
ancient ctags, because they were new when first introduced, and because
they make the TAGS file bigger.  None of these reasons seems to hold any
more, so maybe I should make these the default and adding --no-members
and --no-declarations options.

I am confident that setting at least --members as the default is good
idea, so in the absence of contrary feedback, I will make --members the
default and leaving --declarations as it is now, but I would gladly
listen for opinions on this matter.

At the end of the message I am including the output of etags with
--members for the code snippet you propose.

>code:
>---------------------------------------------------------------------
>template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels, typename ipc3dLinkControl, typename ipc3dLinkControlSetup>
>class CMultiChannelCSC19_3D
>{
>private:
>        ipc3dLinkControlSetup setup;
>        ipc3dCSC19<ipc3dIslandHierarchy,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipc3dLinkControl> mcCSC; 
>        advTimer cscInitTime;
>        advTimer cscSegmentationTime;
>        advTimer outputTime;
>public:
>        void execute(CPluginCSCState& p, int w, int h, int d, const ipcMultiChannel<ipc3dChannelType,numOfChannels>* orgImage, ipcMultiChannel<ipc3dChannelType,numOfChannels>* regionImage, unsigned int* mapImage, ipc3dBlockCompressedLabelImage* compressedMapImage=NULL)
>        {
>                if (orgImage!=NULL)
>                {
>                                  //do something
>                }
>        }
>};
>---------------------------------------------------------------------
>TAGS by emacs etags:
>---------------------------------------------------------------------
>
>foo.h,423
>template <typename ipc3dIslandHierarchy,1,0
>template <typename ipc3dIslandHierarchy, typename ipc3dChannelType,1,0
>template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels,1,0
>template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels, typename ipc3dLinkControl,1,0
>class CMultiChannelCSC19_3D2,151
>        void execute(CMultiChannelCSC19_3D::execute11,459
>---------------------------------------------------------------------
>TAGS by exuberant ctags:
>---------------------------------------------------------------------
>
>foo.h,680
>class CMultiChannelCSC19_3DCMultiChannelCSC19_3D2,151
>        ipc3dLinkControlSetup setup;setup5,190
>        ipc3dCSC19<ipc3dIslandHierarchy,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipc3dLinkControl> mcCSC; mcCSC6,220
>        advTimer cscInitTime;cscInitTime7,375
>        advTimer cscSegmentationTime;cscSegmentationTime8,398
>        advTimer outputTime;outputTime9,429
>        void execute(CPluginCSCState& p, int w, int h, int d, const ipcMultiChannel<ipc3dChannelType,numOfChannels>* orgImage, ipcMultiChannel<ipc3dChannelType,numOfChannels>* regionImage, unsigned int* mapImage, ipc3dBlockCompressedLabelImage* compressedMapImage=NULL)execute11,459

This is the output with --members.  The first four lines make a tag for
the templates, which extags does not do (as far as I know).  A tag for
ipc3dCSC19 is emitted, which exctags does not do.  The tag names are of
the form class::tag, allowing to search tags more easily.

/tmp/t.cc,1293
template <typename ipc3dIslandHierarchy,^?1,0
template <typename ipc3dIslandHierarchy, typename ipc3dChannelType,^?1,0
template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels,^?1,0
template <typename ipc3dIslandHierarchy, typename ipc3dChannelType, unsigned numOfChannels, typename ipc3dLinkControl,^?1,0
class CMultiChannelCSC19_3D^?2,151
        ipc3dLinkControlSetup setup;^?CMultiChannelCSC19_3D::setup^A5,190
        ipc3dCSC19<^?CMultiChannelCSC19_3D::ipc3dCSC19^A6,227
        ipc3dCSC19<ipc3dIslandHierarchy,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipcMultiChannel<ipc3dChannelType,numOfChannels>,ipc3dLinkControl> mcCSC;^?CMultiChannelCSC19_3D::mcCSC^A6,227
        advTimer cscInitTime;^?CMultiChannelCSC19_3D::cscInitTime^A7,388
        advTimer cscSegmentationTime;^?CMultiChannelCSC19_3D::cscSegmentationTime^A8,418
        advTimer outputTime;^?CMultiChannelCSC19_3D::outputTime^A9,456
        void execute(^?CMultiChannelCSC19_3D::execute^A11,493