Re: [PATCH -v2] scipts/tags.sh: Add custom sort order

From: Masahiro Yamada <masahiroy@kernel.org>
To: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH -v2] scipts/tags.sh: Add custom sort order
Date: Thu, 3 Sep 2020 11:07:28 +0900	[thread overview]
Message-ID: <CAK7LNAS+0QtvgX1b77Y51cuMQ-eK4cKb8rebTQ=Ug3F2rkjP2g@mail.gmail.com> (raw)
In-Reply-To: <20200902162649.GL1362448@hirez.programming.kicks-ass.net>

On Thu, Sep 3, 2020 at 1:26 AM <peterz@infradead.org> wrote:
>
> 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>

Sorry, I intended Reported-by, not Reviewed-by.

> 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.

OK, but is there any idea
to make the code cleaner and easier to maintain?

People play with whatever they want to do in this script.

f81b1be40c44b33b9706d64c117edd29e627ad12
introduced file-level ordering.

4f491bb6ea2aef2f5b184f385904a73796d98554
broke it.
(I pointed it out in the review,
but akpm picked it anyway.)

Now, here is the tag-level ordering
(only for exuberant ctags).

Contributors stop caring after their code is merged,
but maintaining it is tiring.

Will re-implementing your sorting logic
in bash look cleaner?

Or, in hindsight, we should have used python or perl?

--
Best Regards
Masahiro Yamada