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: Mon, 28 Feb 2022 14:05:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)

On Mon, 28 Feb 2022 at 09:09, David Fussner <dfussner@googlemail.com> wrote:

> For what it's worth, I've always just done what Arash suggests when
> RefTeX gets out of sync, and haven't had any issues with it that I can
> remember.  (To be fair, my use cases haven't exactly been exotic.)

Sure, I'm aware you have to do the manual resync when using RefTeX.  I
just think it's a totally unnecessary hurdle at this time and age.  I
used to advice the RefTeX commands so they would reparse the document
every time, and this worked just fine.  (Granted, I never worked on
anything over 100 pages or so, but it should also be possible to reparse
individual files of a multifile project so that the file sizes never
become an issue.)

>> 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.
>
> The only thought I have is that it sounds like a new major mode would
> be overkill for what you need here.  I would think that a variable or
> defcustom might do the trick, or at most maybe a minor mode?  When
> navigating code I really want to be able to follow the commands to
> their source no matter whether the command is internal or for users,
> though I can see how in a code-completion setting you might want to be
> able to separate the two more cleanly.  Obviously, I'm not the person
> you need to convince about all of this -- that would be Arash and the
> emacs maintainers, themselves.

Okay, thanks for your insight.

>
> Best,
>
> David.
>
> On Sun, 27 Feb 2022 at 18:43, Arash Esbati <arash@gnu.org> wrote:
>>
>> Augusto Stoffel <arstoffel@gmail.com> writes:
>>
>> > 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.
>>
>> If you know the known labels to RefTeX are out of sync, you can issue
>> `C-c )' with a prefix argument:
>>
>> ,----[ C-h f reftex-reference RET ]
>> | reftex-reference is an interactive native compiled Lisp function in
>> | ‘reftex-ref.el’.
>> |
>> | (reftex-reference &optional TYPE NO-INSERT CUT)
>> |
>> | Make a LaTeX reference.  Look only for labels of a certain TYPE.
>> | With prefix arg, force to rescan buffer for labels.  This should only be
>> | necessary if you have recently entered labels yourself without using
>> | reftex-label.  Rescanning of the buffer can also be requested from the
>> | label selection menu.
>> | The function returns the selected label or nil.
>> | If NO-INSERT is non-nil, do not insert \ref command, just return label.
>> | When called with 2 C-u prefix args, disable magic word recognition.
>> |
>> |   Probably introduced at or before Emacs version 20.1.
>> |
>> `----
>>
>> Or in the labels *RefTeX select* buffer, you have these choices:
>>
>>  r / C-u r  Reparse document / Reparse entire document.
>>
>> I usually hit r when I don't find the label I'm looking for.
>>
>> > Or at least that was the case when I still used RefTeX.  So it might
>> > be worth considering some cache invalidation scheme there.
>>
>> The question is if it's worth the effort where a remedy is already in
>> place.
>>
>> Best, Arash





reply via email to

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