lkml.org 
[lkml]   [2020]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v2] scipts/tags.sh: Add custom sort order
On Thu, Sep 03, 2020 at 12:58:14AM +0900, Masahiro Yamada wrote:

> Sorry for the long delay.
>
> First, this patch breaks 'make TAGS'
> if 'etags' is a symlink to exuberant ctags.
>
>
> masahiro@oscar:~/ref/linux$ etags --version
> Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
> Addresses: <dhiebert@users.sourceforge.net>, http://ctags.sourceforge.net
> Optional compiled features: +wildcards, +regex
>
> masahiro@oscar:~/ref/linux$ make TAGS
> GEN TAGS
> etags: Warning: include/linux/seqlock.h:738: null expansion of name pattern "\2"
> sed: can't read TAGS: No such file or directory
> make: *** [Makefile:1820: TAGS] Error 2
>
> The reason is the hard-coded ' > tags',
> and easy to fix.

Ah, my bad, I forgot to check.

> But, honestly, I am not super happy about this patch.
>
> Reason 1
> In my understanding, sorting by the tag kind only works
> for ctags. My favorite editor is emacs.
> (Do not get me wrong. I do not intend emacs vs vi war).
> So, I rather do 'make TAGS' instead of 'make tags',
> but this solution would not work for etags because
> etags has a different format.
> So, I'd rather want to see a more general solution.

It might be possible that emacs' tags implementation can already do this
natively. Initially I tried to fix this in vim, with a macro, but I
couldn't get access to the 'kind' tag.

> Reason 2
> We would have more messy code, mixing two files/languages

I could try and write the whole thing in bash I suppose.

> When is it useful to tag structure members?

Often, just not when there is a naming conflict.

> If they are really annoying, why don't we delete them
> instead of moving them to the bottom of the tag file?

Because they're really useful :-)

> I attached an alternative solution,
> and wrote up my thoughts in the log.
>
> What do you think?

> Exuberant Ctags supports the following kinds of tags:
>
> $ ctags --list-kinds=c
> c classes
> d macro definitions
> e enumerators (values inside an enumeration)
> f function definitions
> g enumeration names
> l local variables [off]
> m class, struct, and union members
> n namespaces
> p function prototypes [off]
> s structure names
> t typedefs
> u union names
> v variable definitions
> x external and forward variable declarations [off]
>
> This commit excludes 'm', 'v', and 'x'.

So my main beef is with m vs s conflicts (they're pretty prevalent),
removing v is insane, but even removing m is undesired IMO.

> Reviewed-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Very much not I'm afraid. I really do like my tags, it's just that I'd
like to have a set precedence when there's a naming conflict.

My claim is that a structure definition is more interesting than a
member variable, not that member variables are not interesting.

\
 
 \ /
  Last update: 2020-09-02 18:28    [W:0.092 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site