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

Previous Next

Full log

Message #44 received at 53749 <at> debbugs.gnu.org (full text, mbox):

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

Hi David,

On 23.02.2022 12:45, David Fussner via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:

> I guess it might be possible to come up with a regexp to suppress the
> @ in some positions in the string, but the bad news is that if you M-?
> with that search string you get no results at all with the default
> backend. Grep finds the same two as before, but the default format
> specification eliminates even those.  So you're left looking at a
> string in your buffer and xref is telling you it isn't there.

That's odd. I've tried searching for 'blx <at> opt <at> uniquename' inside \...@, 
and 'grep -w' successfully finds it. Post-processing fails, apparently, 
but that depends on the contents of the syntax table. So one solution 
might be to update tex-mode's syntax table.

>> 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?
>>
> 
> You're quite right that C-x p g works well in this instance, and I
> tried to improve how thing-at-point finds search strings in TeX
> buffers for this command.  I guess TeX is a little bit of a bad fit
> both for text modes and for prog modes, but I confess I'm still uneasy
> at the thought of M-? returning such misleading results.  What would
> you think about putting project-find-regexp on M-? in TeX buffers?
> That is, assuming I don't find reasonably common TeX constructs that
> defeat it?

At the face of it, the suggestion seems odd (those command's features 
and user expectations are different), but it wouldn't be out of the 
question to circle back to it later.

>> 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.
>>
> 
> I guess we could make etags do some of the work, perhaps adding also a
> distinction between tagged commands that require this duplication
> (\def & \csdef) and those that don't (\chapter).  Aside from making
> tags files a lot bigger, and possibly adding another option to a
> program already overloaded with them -- neither of which is a
> showstopper -- I suspect it could work pretty well for
> xref-find-definitions.

IIUC tag files for LaTeX aren't going to be particularly big anyway 
(book projects are almost always smaller than even a mid-sized software 
project), so the size might never be a problem.

But then again, I could be very wrong about that.

>> 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.
> 
> I certainly concur about duplicated code, and I really did try hard to
> get by without a new backend, but I won't pretend that I exhausted all
> or even nearly all of the possibilities. If I'm understanding you
> correctly, you'd prefer a few, small changes to the backend code in
> etags.el (and xref.el), should that be necessary, to a whole new
> backend which limits changes to tex-mode.el.  If this understanding is
> reasonably accurate, I can have another look at earlier iterations of
> the code to see what I missed, and perhaps come up with something that
> works right without so much duplication. It may well take me some
> time, so apologies in advance for being slow.

Yes, please.

Previous Next

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