GNU bug report logs - #53749
29.0.50; [PATCH] Xref backend for TeX buffers

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: David Fussner <dfussner <at> googlemail.com>
Cc: 53749 <at> debbugs.gnu.org
Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Date: Wed, 23 Feb 2022 04:21:17 +0200

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 <at> opt <at> uniquename@#1}
>      {\letcs\blx <at> uniquename{blx <at> opt <at> uniquename@#1}}
>      {\blx <at> err <at> invopt{uniquename=#1}{}}}
> \def\blx <at> opt <at> uniquename <at> false{false}
> \def\blx <at> opt <at> uniquename <at> init{init}
> \def\blx <at> opt <at> uniquename <at> true{full}
> \def\blx <at> opt <at> uniquename <at> full{full}
> \def\blx <at> opt <at> uniquename <at> allinit{allinit}
> \def\blx <at> opt <at> uniquename <at> allfull{allfull}
> \def\blx <at> opt <at> uniquename <at> mininit{mininit}
> \def\blx <at> opt <at> uniquename <at> minfull{minfull}
> 
> If you do M-? on \ifcsdef{blx <at> opt <at> uniquename@#1} using the default 
> backend, the default search string is blx <at> opt <at> 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 <at> opt <at> 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 <at> opt <at> uniquename <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.