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: Augusto Stoffel <arstoffel <at> gmail.com>
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: Sat, 26 Feb 2022 11:56:50 +0100

On Sat, 26 Feb 2022 at 09:29, David Fussner <dfussner <at> googlemail.com> wrote:

> Hi Augusto,
>
> On Fri, 25 Feb 2022 at 20:16, Augusto Stoffel <arstoffel <at> gmail.com> wrote:
>>
>> Hi David,
>
>>
>> I took a superficial look at this thread, and this seems very nice.
>
> Thanks!
>
>>
>> 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?
>
> I confess that TeX developers are indeed one of the main targets for
> the feature as I envisioned it.  For creating and following \labels,
> \refs, and \cites (of all sorts) I find RefTeX very handy, as well as
> for jumping around \chapters and \sections and the like.  What I miss
> when developing are the code-navigation features of something like
> xref, which are (from the user point of view) both simple and
> powerful.  My modest goal was to make Emacs' extensive infrastructure
> work a little better out of the box for TeX documents, especially for
> styles and other collections of macros.

Sorry for entering a tangent, but here's one more thing I dislike about
RefTeX you might want to consider.  If you type \label{something}, as
opposed to using the RefTeX command to add a label (or if you edit the
label by hand) then RefTeX will not reparse the document and get out of
sync.  Or at least that was the case when I still used RefTeX.  So it
might be worth considering some cache invalidation scheme there.
(Digestif has caching for multifile documents, but parsing a single file
is fast enough that this is not a problem I need to worry :-).)

>>
>> 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.
>>
>
> This looks very nice indeed, and if I'm reading it right provides a
> replacement both for RefTeX and for the code-navigation features I'm
> trying to implement.

That's right.  Also command completion (including snippets, if that's
your thing) and Eldoc.

>  I figure I'll continue trying to get improved
> out-of-the-box features into core, and if I manage to satisfy Dmitry
> we'll then have a choice, but in any case I'm going to have a longer
> look at digestif when I get some time.

Let me mention one last thing, since you seem interested in a TeX
programming mode.

Digestif will not work great out of the box for programming because it
correctly considers @ to have catcode "other" (so it can't be part of
the name of a command).  But this is trivial to change and, in fact,
Digestif already has a "latex-prog" mode that simulates the correct
catcodes.  It would be easy to include a "latex-expl3" mode as well.

The problem is that there's no way for Emacs to communicate that one of
these programming modes is to be used.  This could be fixed in two ways:

A. by creating latex-prog and latex-expl3 derived modes in Emacs, or

B. adding heuristics to Digestif to decide if a given file is "document"
   or "code".

Do you have any thoughts about A?  Would there be any other benefits in
Emacs to justify the latex-prog and latex-expl3 major modes?  It seems
that (at least in AUCTeX) @ is always considered a letter, which may be
innocuous but is kinda wrong.

>
> Thanks for the hint!
>
> David.

Previous Next

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