[Top][All Lists]

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

Re: [FR] RefTex support for zref-xr

From: Gustavo Barros
Subject: Re: [FR] RefTex support for zref-xr
Date: Sat, 11 Dec 2021 16:21:01 -0300
User-agent: mu4e 1.6.10; emacs 27.2

Hi Arash,

On Fri, 10 Dec 2021 at 23:14, Arash Esbati <> wrote:

Now we are 2 ;-)

I'm thinking here, and since we are trying some ideas out, I'd like to take a step back, and make an argument. Perhaps you'll disagree, but please bear with me.

(I'm reordering your comments to highlight some connections).

This is the `Naked label' in RefTeX.  Our labels are not bound to any
sections/environments, and for the others, RefTeX takes \label (which is
hard-coded, AFAICT).

The issue is that \zlabel doesn't get a prefix like 'fig:' in the first
place [...].

I was unsure about this in the last message, but I thought it through and tested things out, and this limitation is actually a consequence of using `(reftex-add-label-environments '(("\\zlabel{*}" ?z nil nil nil))', because, if we use `(reftex-add-label-environments '(("\\zlabel{*}" nil nil nil nil)))', we do get prefixes and context derived labels, as 'fig:', 'sec:section-1' etc. (The prompt does say "Naked label", but the content is just the same as for regular `\label's).

So we actually loose functionality both in label querying for setting references and in label setting itself. In the first case we loose the capacity to narrow by type of label. In the second we loose all prefix and context derived labels by RefTeX.

It is quite a lot to forgo, I'd say. In my last message I had understood the first, but I'm adding the second to the discussion.

Thanks, I think this can a be compromise for all users: Serious \zlabel
users will to use it exclusive as a replacement for \label, and casual
users will have two label circles.

[...] adding 'z:' should be easy with RefTeX (didn't test it though).

I'm no longer sure the `("\\zlabel{*}" ?z nil nil nil)' is the best approach, for the reasons mentioned above. If it turns out to be the only one, then there's no choice. But *if* the "z:" prefix to the labels is indeed feasible, I think using it with `("\\zlabel{*}" nil nil nil nil)' would be a superior alternative.

It is (much) less complex, we'd get full support from RefTeX, including narrowing by type, label prefixes, and context derived labels. And it does avoid the potential clashes of the two separate sets of labels on the LaTeX side: with the "z:" prefix, they don't mix. Hence, RefTeX does not confuse them, no duplicate problems. And users do not confuse them either, since they have the prefix hint.

Admittedly, your `LaTeX-zref-replace-label' would mitigate the limitations of `("\\zlabel{*}" ?z nil nil nil)', but we'd still have two ways of setting the zlabel with radically different behaviors.

So, for now, I'm refraining from entering into the details of implementation in this area. Because, in the chance I was able to convince you, those might be superfluous. But, if you do disagree, then I'll come back and comment on them with pleasure.

Still, a thank you for `LaTeX-zref-reftex-quick-id-key', is due. It is great. :-)

I have another idea: For serious users, we can replace \label with
\zlabel.  For sectionning commands, we need to add function to
`LaTeX-section-hook' which looks back for a \label and adds a 'z' to it.
For environments, the same logic would apply, but
`LaTeX-after-insert-env-hook' is not the right place since it is run to
early.  I have to think about it.  See attached a new version with the
first idea implemented.  Maybe you want to give it a roll. You have to
set `LaTeX-zref-replace-label' before it works.

This is to some extend a separate issue, and is good stuff. It was actually in my list to discuss later on, so I'm glad you brought it up.

Besides the above mention that this is much welcome, I have two further comments. One about some `zref's limits, with some implications to label setting, and the other about the technical side of getting `\zlabel's out of `reftex-label'.

About the first, even for users who want to use `zref' as their main reference system, it may be quite hard to use it exclusively because some places which handle labeling specially, do not offer support for `zlabel'. There are two conspicuous general cases for this: places where `\label' cannot be set directly and must be passed as an argument to a command or environment; places where `\label' has special support.

One relevant example of this are `amsmath' display environments: There are work-arounds to get things working for `zref':, but they rely on making `\label' set a `\zlabel' for us. Therefore, within them, `\label' is all AUCTeX/RefTeX will ever see when parsing the document.

All this to say some exception handling may be needed when replacing `\label's with `\zlabel's. However, even when it's not possible to do so, a way to get `\zlabel's from `reftex-label' (called directly, or indirectly by some hook), as you are proposing, is still much welcome. And I concur it should be "opt-in", as you made it.

On the technical side, I have some stuff to do the same job here, using `reftex-format-label-function', which may interest you. It's a little crude, but only the basic idea is relevant anyway:

#+begin_src elisp
(defvar gb/LaTeX-prefer-zlabel nil
"If non-nil prefer '\\zlabel' over '\\label' when zref-user is loaded.")

(defun gb/zref-user-reftex-format-label-function (label default)
 (if (and gb/LaTeX-prefer-zlabel
          (string= default "\\label{%s}")
          ;; 'amsmath' display environments do not support 'zlabel'.
          (not (and (TeX-match-style "amsmath")
     (format "\\zlabel{%s}" label)
   (format default label)))

(setq-local reftex-format-label-function

I may be missing something you are trying to do with `LaTeX-zref-replace-label-section' and `LaTeX-zref-replace-label-environment' but, as far as I grasp, it is pretty much the same job, in which case `reftex-format-label-function' may be an interesting alternative "hook". I'm not sure if "better", just bringing it in for your consideration.

Thank you very much once again.

And once you let me know what you think about the `reftex-add-label-environments' issue, I'll be glad to provide further comments appropriate to the ensuing "branching".

Best regards,

reply via email to

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