Re: etags regex for Lilypond & LY_DEFINE* tags

[John Wheeler]

On 5/7/22 06:05, David Kastrup wrote:
> David Kastrup<dak@gnu.org>  writes:
>
> > Jonas Hahnfeld via Discussions on LilyPond development
> > <lilypond-devel@gnu.org>  writes:
> >
> > > On Fri, 2022-05-06 at 20:42 -0500, John Wheeler wrote:
> > > > Please forgive this second attempt to reply:
> > > >
> > > > Jean,
> > > >
> > > > On 4/28/22 16:14, Jean Abou Samra wrote:
> > > > > Is it a large script?
> > > > > If so, it needs some consideration. If not, can it fit in an @example
> > > > > somewhere in the CG? That might also make it more visible.
> > > > The 'script' consists of a shell script to gather various cross-references,
> > > > two support files containing the regex needed to find LilyPond language
> > > > cross-references in .ly and .cc files, and a python script to mangle c++
> > > > identifiers.  Too large to fit in an example in the CG, I think.
> > > >
> > > > I did create a paragraph for CG 10.4 Finding Functions to describe its use.
> > > >
> > > > By consideration, were you suggesting I submit a merge request and ask
> > > > for review and comment?
> > > I've traditionally been opposed to adding more such scripts to the
> > > LilyPond tree, mostly because I spent way too much time trying to
> > > understand what existing and entirely undocumented ones were doing and
> > > how they were broken in a zillion ways. My take is that the LilyPond
> > > repository must only contain what is needed to build and maintain
> > > LilyPond. IMHO a convenience script (as far as I understand it) does
> > > not fall into this category, and I would vote *not* to include it.
> > I cannot follow the characterisation as a "convenience script" here:
> > making Emacs properly cross-reference functions is IDE support.  We
> > similarly have IDE support in `.dir-locals.el`.  There is no real point
> > in doing this in a separate repository since the only use is in
> > connection with working in the LilyPond source tree.
> By the way: the convention for making this work bypasses the means of
> implementation (convenience script, pattern file for etags, whatever)
> and provides this functionality as
>
>      make tags
>
> The resulting tags file is usable for both Emacs and vi (and other tools
> using the same mechanism).
Thank you for pointing out that this functionality should be handled by 
'make TAGS'.
For me, 'make TAGS' returns empty tags files, presumably because I am 
building
in a directory outside of the source tree.  I will admit that when I 
discovered that
behavior, I opted to write a script rather than to attempt to 
understand/modify the
make process.

I will investigate whether I can add my desired functionality to 'make 
TAGS'.

John Wheeler