> --8<---------------cut here---------------start------------->8--- > diff --git a/tex-fold.el b/tex-fold.el > index 62f0834c..cb0f4592 100644 > --- a/tex-fold.el > +++ b/tex-fold.el > @@ -910,6 +910,11 @@ See `TeX-fold-auto-reveal' for definitions of MODE." > Return non-nil if called by one of the commands in LIST." > (memq this-command list)) > > +(defvar-local TeX-fold-auto-reveal-external-commands nil > + "List of external commands which may cause a fold to be revealed. > +This is list is intended for external packages where they can add their > +functions to.") > + > ;; Copy and adaption of `reveal-post-command' from reveal.el in GNU > ;; Emacs on 2004-07-04. > (defun TeX-fold-post-command () > @@ -932,7 +937,8 @@ Return non-nil if called by one of the commands in LIST." > (setq TeX-fold-open-spots (cdr spots)) > (when (or disable-point-adjustment > global-disable-point-adjustment > - (TeX-fold-auto-reveal-p TeX-fold-auto-reveal)) > + (TeX-fold-auto-reveal-p TeX-fold-auto-reveal) > + (TeX-fold-auto-reveal-p > TeX-fold-auto-reveal-external-commands)) > ;; Open new overlays. > (dolist (ol (nconc (when (and TeX-fold-unfold-around-mark > (TeX-active-mark)) > --8<---------------cut here---------------end--------------->8--- > > So we don't touch `TeX-fold-auto-reveal' and just check if > `TeX-fold-auto-reveal-external-commands' contains code, just like > `TeX-fold-auto-reveal'. WDYT?
This would need a bit of tweaking (since TeX-fold-auto-reveal doesn't accept a list argument), but assuming that tweak: I think with most use cases (including mine), there's no functional difference between this last proposal and the original patch. The comparison, as I see it, is that this last proposal (1) uses defvar-local rather than defcustom, and (2) hard-codes the "external-commands" alternative. My reason for preferring the alternative to (1) is that users might wish to add their own navigation-based commands, so making it a defcustom would improve discoverability. Also, I don't foresee defvar-local giving an advantage over defvar here, but might have missed something. For (2), I didn't want to deny the user of the flexibility that they currently enjoy, where they could customize the reveal behavior to depend upon the moon cycle. Finally, I'll remark that I planned to submit a follow-up patch to this one slightly expanding the default collection of reveal commands (adding #'undo and #'pop-to-mark-command). Do you see an advantage to modifying the behavior of the function rather than the default customization value? Thanks, best, Paul _______________________________________________ bug-auctex mailing list bug-auctex@gnu.org https://lists.gnu.org/mailman/listinfo/bug-auctex