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@xxxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxx> 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.
