bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers

[David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]

Hi Dmitry,

> Do you have a step-by-step scenario? Perhaps using one of the .texi
> manuals already existing in the repo?

I can't find a good example in the emacs repo, but I'll try to talk through
what happens with a code snippet from biblatex.sty, which I hope will
explain some of the issues we're discussing, even if it is a little
artificial.

\DeclareBiblatexOption{global,type}[string]{uniquename}[true]{%
  \ifcsdef{blx@opt@uniquename@#1}
    {\letcs\blx@uniquename{blx@opt@uniquename@#1}}
    {\blx@err@invopt{uniquename=#1}{}}}
\def\blx@opt@uniquename@false{false}
\def\blx@opt@uniquename@init{init}
\def\blx@opt@uniquename@true{full}
\def\blx@opt@uniquename@full{full}
\def\blx@opt@uniquename@allinit{allinit}
\def\blx@opt@uniquename@allfull{allfull}
\def\blx@opt@uniquename@mininit{mininit}
\def\blx@opt@uniquename@minfull{minfull}

If you do M-? on \ifcsdef{blx@opt@uniquename@#1} using the default backend,
the default search string is blx@opt@uniquename@, and you'll get two hits,
that line and the following one.  Stepping through
xref-references-in-directory shows that the semantic-symref search (using
grep) only finds those two using the :searchtype 'symbol, and they're
returned.  If you change 'symbol to 'regexp, grep finds all the matches in
that code snippet, but then xref--convert-hits uses (format "\\_<%s\\_>"),
which again loses all but the first two hits when it scans the list
provided by grep.  Either grep or emacs here will miss out on valid hits
unless you change both the semantic-symref instantiation and the format
specification.

> One way to deal with that is to treat all user inputs as regexps there.
Perhaps some will have to be more verbose that ideal, but as      > long as
the user is familiar with the regexp syntax, the behavior will be both
powerful and predictable

If I understand you right, I think that's what I'm trying to do, but
allowing for users who perhaps aren't too familiar with emacs regexps and
who might typically just accept the default search string offered by xref.

>  Could those be disambiguated when the tags are scanned, instead? Then
the user will tailor their input to find the one or the other.

If I understand you correctly, that's also what I try to do -- each tagged
command in the tags file is searched by the name of the tag, which in these
cases will either start with the escape char or not.  Looking at the
biblatex snippet, if you come across \csuse{blx@opt@uniquename@false}
somewhere in a file, and you want to see what the definition is, you can't
know apriori how it was defined, with \def or with \csdef.  This snippet
above mixes both styles, and I hoped that a user would be allowed to choose
whether to search for both styles without necessarily having to try both
forms of the string in separate searches.  In fact, as the code stands, it
only does the second search if the first one fails, so it still more or
less keeps the two command-naming styles separate.

The simplest fix is to remove the escape char from all tag names, which I
suggest to users of ctags in some commented-out code in etags.c. This does
lose the ability to differentiate \def'ed commands and \csdef'd ones,
especially as in some circumstances they can have the same name.  I'm not
sure how great a loss that is, on the other hand.  Is that what you had in
mind?

> Or if we want more fuzzier matching, perhaps creating mode-specific
values of etags-xref-find-definitions-tag-order could help.

Yeah, you're right, I'm pretty sure I could use a buffer-local value of
that variable to get xref-find-definitions to do the fuzzy matching I'm
after.  Does the discussion above at all help to convince you that there
are other issues that might still require a new backend?

David.

[-- Attachment #2: Type: text/html, Size: 4259 bytes --]