bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Augusto Stoffel
Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Date: Fri, 25 Feb 2022 21:16:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)

Hi David,

I took a superficial look at this thread, and this seems very nice.

I was wondering why you want to be able to find the definition of macros
with @ in their name.  Those are "private" macros that the user
shouldn't have occasion to use.  Is it for a TeX programmer mode?

Let me also mention a library I wrote for analyzing TeX code (accessible
to Emacs via LSP):

    https://github.com/astoff/digestif

It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
for flexible parsing.  If you want to be very ambitious about what you
are able to parse, I think regexps are not sufficient.

Digestif can handle \cite{messed up reference} just fine, for example.

On Thu,  3 Feb 2022 at 15:09, David Fussner via "Bug reports for GNU Emacs, the 
Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:

> I've recently been trying to use xref commands with a tags table in a
> TeX repository, and many of the results are sub-optimal.  This is a
> known issue -- within living memory there have been at least two
> discussions related to it on help-gnu-emacs:
>
> https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html
> https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg00436.html
>
> Neither discussion resulted in any code, at least not that I can find,
> and the issues mentioned there remain.  For example,
> xref-find-definitions on, say, '\mycommand' returns
>
> No definitions found for: mycommand.
>
> (The absence of the escape char in the search string makes the search
> fail, as the tag name in the table will be '\mycommand'.)
>
> Similarly, any xref command on 'my:citekey' will only search by default
> for the half of the symbol under point, stopping at the colon.
>
> There are many other behaviors that are suboptimal, as well, so in the
> end I wrote a new xref backend for TeX buffers (cloning large portions
> of the default etags backend), and wondered whether it might be welcome
> in GNU Emacs.
>
> A few remarks:
>
> 1. The code should work as it stands both in the AUCTeX and the in-tree
> modes.  The AUCTeX hooks I've included in the patch are provisional, as
> I would want to discuss with them how they would want to handle it,
> should the patch be accepted in some form.
>
> 2. Along the way I found some issues with how etags parses TeX files,
> issues which affect the usefulness of the xref commands, so I've made
> changes in etags.c as well.  When running the test suite for etags the
> only diffs occurred in the TeX-related sections of the resulting tags
> file, and location information in those sections was good.
>
> 3. The patch as it stands enables all the changes by default to give
> what I judge to be the best out-of-the-box experience, but wiser heads
> may well have other ideas.
>
> 4. If it looks like the patch will make it into Emacs in some form, I'm
> going to need to assign copyright, so I'd appreciate help with getting
> that started.
>
> Thanks,
>
> David.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]