bug#73386: [PATCH] Fix keybinding support for *-auto-reveal
Hello, I just realized that my earlier patch 8db1e90b6d25beb72b5ebbc706b6def64794dcf8 broke key-binding support for auto-reveal (i.e., using left/right rather than C-f/b to open previews and folds). The attached patch remedies this. Details below. Thanks, best, Paul --- The user option *-auto-reveal-commands consists of both functions and lists for keybinding: (defcustom preview-auto-reveal-commands '((key-binding [left]) (key-binding [right]) backward-char forward-char pop-to-mark-command undo) "List of commands that may cause a preview to be revealed. This list is consulted by the default value of `preview-auto-reveal'." :type '(repeat (choice (function :tag "Function") (sexp :tag "Key binding" When we call (apply #'preview-arrived-via preview-auto-reveal-commands), the lists for keybinding are not evaluated, so we never pick up the command to which left/right are bound. The attach patch remedies this issue by first evaluating any keybinding. In retrospect, a more uniform approach would have been to have all elements of *-auto-reveal-commands be "something that gets evaluated", i.e., (defcustom preview-auto-reveal-commands '((key-binding [left]) (key-binding [right]) #'backward-char #'forward-char #'pop-to-mark-command #'undo) ...) This would allow a more uniform default implementation of *-auto-reveal. Given that the docstring for *-auto-reveal-commands says that it should consist of either functions or key bindings, I think the proposed solution is acceptable. It's also a bit simpler for me, since I have a couple packages that add functions (rather than function symbols) to *-auto-reveal-commands. 0001-Fix-keybinding-support-for-auto-reveal.patch Description: Binary data ___ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#73302: TeX-find-closing-brace and verbatim macros
Hi Paul,
> Paul Nelson writes:
> I noticed just now that my patch can break the folding of
> \end{verbatim} environments when called via TeX-fold-region. Steps to
> reproduce:
> 1. After loading AUCTeX and tex-fold, evaluate
>(add-to-list 'TeX-fold-macro-spec-list '(identity ("end")))
> 2. Create a LaTeX file containing
> \begin{verbatim}
> blah
> \end{verbatim}
> 3. Make the region contain the line "\end{verbatim}", but none of the
> line "\begin{verbatim}"
> 4. C-c C-o C-r (TeX-fold-region).
> This results in [Error: No content or function found], resulting from
> a failure for TeX-fold-macro-nth-arg to recover the first argument to
> \end{verbatim}.
Confirmed.
> One can trace the issue to the following discrepancy:
> a. With point on the "{" in "\end{verbatim}", (TeX-verbatim-p) returns
> nil (as expected).
> b. If we repeat (a) after narrowing to a region that contains the line
> "\end{verbatim}" but none of the line "\begin{verbatim}", then it
> instead returns t.
Indeed.
> As a fix, we could either:
> (i) Do (save-restriction (widen) ...) in TeX-fold-macro-nth-arg before
> (TeX-verbatim-p).
> (ii) Do (save-restriction (widen) ...) in LaTeX-verbatim-p.
> The advantage of (ii) is that it arguably fixes the root cause rather
> than just patching it at the source. The disadvantage is that I don't
> know off hand whether this would affect other calls to
> LaTeX-verbatim-p in an undesired way. I lean in favor of (i) for now,
> and have updated my patch accordingly, but would welcome other
> feedback.
I don't have particular preference, so I think we can install your
change, provided that no objection is raised.
Thank you for your contribution!
Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
#Gaza #StopMassiveKilling #CeasefireNOW
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
