[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
From: |
Dmitry Gutov |
Subject: |
bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers |
Date: |
Wed, 23 Feb 2022 04:21:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 |
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.
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, David Fussner, 2022/02/03
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, Dmitry Gutov, 2022/02/20
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, David Fussner, 2022/02/21
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, David Fussner, 2022/02/21
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, Dmitry Gutov, 2022/02/21
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, David Fussner, 2022/02/22
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers,
Dmitry Gutov <=
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, David Fussner, 2022/02/23
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, Dmitry Gutov, 2022/02/23
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, David Fussner, 2022/02/24
- bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, Dmitry Gutov, 2022/02/21
bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, Arash Esbati, 2022/02/21
bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers, Augusto Stoffel, 2022/02/25