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.