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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi David,

On 22.02.2022 17:19, David Fussner wrote:

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

Thank you.

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

That might call for a different implementation of 'references' indeed.

But could you make 'blx@opt@uniquename' the default search string in 
that example? Does that make sense?

And if not, all in all, I wouldn't worry too much about 
xref-find-references, since TeX is more of a text format (IMHO) than a 
program with well-defined identifiers. Perhaps using project-find-regexp 
most of the time will save you a lot of the trouble?

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

I'm not sure how I feel about the extra "fuzziness" in the behavior 
which comes with this approach.

>  >  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 parser could create both qualified (with \def or \csdef) and 
unqualified entries for the same definition. Maybe make it optional 
(with -Q argument to etags). Then the user could search using any of 
these formats.

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

The suggestion about a buffer-local value of that var was made in the 
context of trying to make it work with the current etags backend. At 
least, in the first patch. If only because I don't really like to see 
duplicated code.

If we find another place where we really want to diverge, we could also 
try adding some behavior-altering variable first.

After that, we might as well add a new backend (I'm not really against 
it, just prefer to exhaust other options first), but hopefully someone 
else (more familiar with tex-mode) could take over this discussion at 
that point, and the subsequent responsibility for the added code. That 
person could be yourself too, under right conditions.