Re: AUCTeX and "builtin latex mode" integration
> Ikumi Keita writes: > OK, it doesn't pick up an entry of latex-mode for japanese-LaTeX-mode > yet, I expect I can arrange it to cover such cases as well. Thank you. Here is such a code. It seems to work on my side. >From 248a8ae6a3ba7c29555c97eca2b431fcbba05238 Mon Sep 17 00:00:00 2001 From: Ikumi Keita Date: Thu, 9 Nov 2023 15:01:37 +0900 Subject: [PATCH] Enable dir local vars for former mode names Since major mode names have changed, Emacs doesn't apply directory local variables prepared for former mode names. We need somewhat dirty hack to work around that problem. * tex.el (TeX--extra-mode-parents): New constant alist to indicate pseudo mode names which should be regarded as parent modes for the respective major mode. (TeX--compat-derived-mode-p): New function to advice `derived-mode-p'. Regard the pseudo modes indicated by `TeX--extra-mode-parents' as parent modes as well. --- tex.el | 29 + 1 file changed, 29 insertions(+) diff --git a/tex.el b/tex.el index d4fded73..e0e91f5f 100644 --- a/tex.el +++ b/tex.el @@ -3875,6 +3875,35 @@ Run after mode hooks and file local variables application." ;;;###autoload (put 'TeX-mode 'auctex-function-definition (symbol-function 'TeX-mode)) +;; Compatibility hack to enable directory local variables for modes +;; with former names. It is expected that we can remove plain-TeX, +;; LaTeX, docTeX and TeXinfo modes, which once had overlapped names +;; with built-in modes, from this list for Emacs 30, but the others +;; would still need this. +(defconst TeX--extra-mode-parents + '((plain-TeX-mode plain-tex-mode) +(LaTeX-mode latex-mode) +;; XXX: Should we add latex-mode to pseudo-parent of docTeX-mode? +;; It's reasonable, but is not compatible with former AUCTeX +;; behavior. +(docTeX-mode doctex-mode) +(Texinfo-mode texinfo-mode) +(ConTeXt-mode context-mode) +(AmSTeX-mode ams-tex-mode) +(japanese-plain-TeX-mode japanese-plain-tex-mode plain-tex-mode) +(japanese-LaTeX-mode japanese-latex-mode latex-mode)) + "Alist of major modes and list of pseudo-parent modes. +For example, `LaTeX-mode' is regarded as a child of `latex-mode'. +Similarly, `japanese-LaTeX-mode' is regarded as a child of +both `japanese-latex-mode' and `latex-mode'.") + +(advice-add 'derived-mode-p :after-until #'TeX--compat-derived-mode-p) +(defun TeX--compat-derived-mode-p (&rest modes) + (let ((extra-parents (assq major-mode TeX--extra-mode-parents))) +(and extra-parents + (cl-loop for parent in extra-parents + thereis (memq parent modes) + ;;; Hilighting ;; FIXME: It's likely that `hilit-patterns-alist' is much obsolete. -- 2.42.0 Best regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes: > How 'bout a hack more like: I tried to localize the range which my advice affects, within the phase of application of directory local variables. Now that you proposed this approach, I think I don't have to worry about bad side effects due to having `derived-mode-p' advised always. > (defvar auctex--extra-mode-parent > '((LaTeX-mode . latex-mode) > ...)) > (advice-add 'derived-mode-p :after-until #'auctex--compat-derived-mode-p) > (defun auctex--compat-derived-mode-p (&rest modes) > (let ((extra-parent (assq major-mode auctex--extra-mode-parent))) > (and extra-parent (memq (cdr extra-parent) modes OK, it doesn't pick up an entry of latex-mode for japanese-LaTeX-mode yet, I expect I can arrange it to cover such cases as well. Thank you. Best regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes:
> Indeed which symbol is used as *the* file-type is somewhat arbitrary.
> In the case of ConTeXt, it makes sense to use `ConTeXt-mode`.
> And I'd agree that there's also a good case to be made for `LaTeX-mode`,
> but history (and general Emacs practice of using lowercase symbols) is
> arguing fairly strongly in favor of `latex-mode`.
In addition to "%%% mode: ConTeXt" and "%%% mode: latex", I feel uneasy
to have
%%% mode: japanese-LaTeX
and
%%% mode: latex
due to their incoherency as well 😇
Moreover, the whole story began with complaint that the common mode
name is confusing. ("It isn't intuitive that latex-mode-hook is
ineffective in AUCTeX latex-mode.") Thus the primary aim of all these
efforts is to make clear distinction between latex-mode and LaTeX-mode.
The principle that the "mode:" cookie should describe the file-type
rather than specify the "mode" to use contradicts to this aim, if it
imposes priority for
%%% mode: latex(describing the file type)
over
%%% mode: LaTeX(specifying the mode name)
; it would leave the original problem unresolved and lose the core
objective of the whole attempt of this feature branch.
Maybe it isn't a good idea to load such two-fold roles on "mode:"
tag and Emacs should have something different (e.g. some kind of "sub"
tag?) to achieve the fine distinction between `describing the file type'
and `specifying the mode name`.
Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
>> Hmm... this does look awful 🙁 > Exactly. 💀 How 'bout a hack more like: (defvar auctex--extra-mode-parent '((LaTeX-mode . latex-mode) ...)) (advice-add 'derived-mode-p :after-until #'auctex--compat-derived-mode-p) (defun auctex--compat-derived-mode-p (&rest modes) (let ((extra-parent (assq major-mode auctex--extra-mode-parent))) (and extra-parent (memq (cdr extra-parent) modes ? Stefan
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes: > So, IIUC, you're counting on Someone™ to do the work on the Emacs side 🙂 Yes. 😉 Actually, I only looked at very limited portion of the related codes in emacs core and don't have reasonable ideas how to do that in emacs side. > I hope we can arrange the code in Emacs-30 so that no changes are needed > in `.dir-locals.el`, in which case the advice should be activated by > default and we likely shouldn't plead with our users to rewrite their > `.dir-locals.el`. I see. > Hmm... this does look awful 🙁 Exactly. 💀 > Some questions/comments about the above comment: > - Indeed, I see that (derived-mode-p 'aaa-mode) returns nil in that > case, which is a bug. Do we have a bug-number for that? No, I took it as a designed feature. (Under usual circumstances, there isn't a case that major-mode is aaa-mode when aaa-mode is an alias of bbb-mode.) > Amusingly, it returns `aaa-mode` if `aaa-mode` is undefined :-) 😵 > - Is the problem new in Emacs-28 (if so, I guess it came about > in the rewrite which introduced `provided-mode-derived-p`). I think so. The following code returns non-nil on emacs 27.1: -- (defun bbb-mode () 1) (defalias 'aaa-mode #'bbb-mode) (let ((major-mode 'aaa-mode)) (derived-mode-p 'aaa-mode)) -- (I didn't test it on emacs 27.x where x>1.) > - How exactly is it related to the issue of activating `latex-mode` > dir-local settings in `LaTeX-mode`? Not related to `latex-mode' v.s. `LaTeX-mode'. This ugly hack is necessary for modes handled by aliases such as `context-mode' v.s. `ConTeXt-mode'. Note that redirections for some modes in this feature branch are handled by defalias rather than major-mode-remap-alist/advice. For example we have (defalias 'context-mode #'ConTeXt-mode) in context.el. Suppose that a ConTeXt document has file local variables section %%% Local Variables: %%% mode: context %%% End: and there is a .dir-locals.el with a entry (context-mode (foo . 1)) in it. Then emacs 28 and later won't pick up this entry for variable `foo' without the "ugly hack", i.e. (setq orig-former (symbol-function former)) (fset former former) . Similar modes handled by defalias are: context-mode v.s. ConTeXt-mode ams-tex-mode v.s. AmSTeX-mode japanese-plain-tex-mode v.s. japanese-plain-TeX-mode japanese-latex-mode v.s. japanese-LaTeX-mode > I really should look at how best to solve the problem in Emacs-30, it > might give me some ideas about how to write a better workaround for > Emacs<30. I hope there is such better workaround. > Do you think it would be OK for AUCTeX to declare that `latex-mode` is > *another* parent of `LaTeX-mode`? The idea is not to allow multiple > inheritance in `define-derived-mode`, but to allow it in `derived-mode-p`. Yes, I'll welcome that idea. Best regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
>>> (a-2) Now `TeX-add-local-master' adds entry of new mode names such as >>> %%% Local Variables: >>> %%% mode: LaTeX <-- not `latex' >>> %%% End: > >> I don't like this very much: IMO the `mode:` cookie should really not specify >> the "mode" to use but rather describe the file-type (Emacs could/should >> aim to support "mime types" kind of names), and then which mode to use >> for each file-type is decided based on the user's configuration. > > I understand your preferance, but I think such discrimination can't be > much rigorous in practical situations. For example, ConTeXt mode doesn't > have overlapped mode, so it's most natural to have Indeed which symbol is used as *the* file-type is somewhat arbitrary. In the case of ConTeXt, it makes sense to use `ConTeXt-mode`. And I'd agree that there's also a good case to be made for `LaTeX-mode`, but history (and general Emacs practice of using lowercase symbols) is arguing fairly strongly in favor of `latex-mode`. Stefan
Re: AUCTeX and "builtin latex mode" integration
>> We should fix this for Emacs-30. >> [ And then add some backward compatibility hack (presumably using >> an advice for when AUCTeX is used on Emacs<30). ] > I attach my tentative proposal for Emacs<30, using an advice. So, IIUC, you're counting on Someone™ to do the work on the Emacs side 🙂 > +(defcustom TeX-hack-former-dir-local-variables nil > + "If non-nil, apply dir local vars under former mode names. > +For example, directory local variables prepared for `latex-mode' > +will be available in `LaTeX-mode' buffers. > +It is highly discouraged to enable this option. Instead, please > +rewrite mode names in .dir-locals.el whenever possible." I hope we can arrange the code in Emacs-30 so that no changes are needed in `.dir-locals.el`, in which case the advice should be activated by default and we likely shouldn't plead with our users to rewrite their `.dir-locals.el`. > + (setq orig-former-parent (get former 'derived-mode-parent)) > + (put former 'derived-mode-parent former-parent) > + ;; Very ugly hack to deceive `derived-mode-p'. Suppose > + ;; - aaa-mode is an alias of bbb-mode > + ;; - major-mode value is aaa-mode > + ;; Then (derived-mode-p 'aaa-mode) returns nil on Emacs 28 and > + ;; later, which makes `dir-locals-collect-variables' ignore a > + ;; directory local variable entry for aaa-mode and look for an > + ;; entry for bbb-mode instead. Hence we temporally make > + ;; aaa-mode an alias of aaa-mode itself. :-( > + (setq orig-former (symbol-function former)) > + (fset former former) Hmm... this does look awful 🙁 Some questions/comments about the above comment: - Indeed, I see that (derived-mode-p 'aaa-mode) returns nil in that case, which is a bug. Do we have a bug-number for that? Amusingly, it returns `aaa-mode` if `aaa-mode` is undefined :-) - Is the problem new in Emacs-28 (if so, I guess it came about in the rewrite which introduced `provided-mode-derived-p`). - How exactly is it related to the issue of activating `latex-mode` dir-local settings in `LaTeX-mode`? I really should look at how best to solve the problem in Emacs-30, it might give me some ideas about how to write a better workaround for Emacs<30. Do you think it would be OK for AUCTeX to declare that `latex-mode` is *another* parent of `LaTeX-mode`? The idea is not to allow multiple inheritance in `define-derived-mode`, but to allow it in `derived-mode-p`. Stefan
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes:
>> [Incompatibility]
>> 1. directory local variables
>> Currently, directory local variables are prepared in a entry like
>> (latex-mode (reftex-label-alist . (("equation" ?e "eq:%f-" "\\eqref{%s}")
>> ("align" ?e "eq:%f-" "\\eqref{%s}")
>> ("gather" ?e "eq:%f-" "\\eqref{%s}")
>> in .dir-locals.el. In this feature branch, mode name is `LaTeX-mode',
>> thus this entry is ignored.
>>
>> The facility of major-mode-remap-list still does not handle this
>> situation.
>>
>> We can announce this fact and ask users to rewrite their
>> .dir-locals.el, but that can't be done if the user doesn't have write
>> access for that particular .dir-locals.el. (Maybe we can ignore such
>> corner cases?)
> We should fix this for Emacs-30.
> [ And then add some backward compatibility hack (presumably using
> an advice for when AUCTeX is used on Emacs<30). ]
I attach my tentative proposal for Emacs<30, using an advice.
>From 5447814da30ffe9e9e06095fd567e8169df5fb64 Mon Sep 17 00:00:00 2001
From: Ikumi Keita
Date: Sat, 21 Oct 2023 21:16:36 +0900
Subject: [PATCH] Add ugly hack to accept dir local vars with former mode names
* tex.el (TeX-hack-former-dir-local-variables): New customize option.
(TeX--hack-dir-locals-collect-variables): New function to advice
`dir-locals-collect-variables'. When `major-mode' is one of major
modes which have former name, pull in directory local variables
declared under former name. Take into account the parent mode of the
former mode as well.
---
tex.el | 61 ++
1 file changed, 61 insertions(+)
diff --git a/tex.el b/tex.el
index d4fded73..72b39e9b 100644
--- a/tex.el
+++ b/tex.el
@@ -3875,6 +3875,67 @@ Run after mode hooks and file local variables application."
;;;###autoload
(put 'TeX-mode 'auctex-function-definition (symbol-function 'TeX-mode))
+;; COMPATIBILITY for Emacs<30
+;; hack for directory local variables
+(defcustom TeX-hack-former-dir-local-variables nil
+ "If non-nil, apply dir local vars under former mode names.
+For example, directory local variables prepared for `latex-mode'
+will be available in `LaTeX-mode' buffers.
+It is highly discouraged to enable this option. Instead, please
+rewrite mode names in .dir-locals.el whenever possible."
+ :group 'TeX-misc
+ :type 'boolean)
+
+(advice-add 'dir-locals-collect-variables :around
+#'TeX--hack-dir-locals-collect-variables)
+(defun TeX--hack-dir-locals-collect-variables (f &rest args)
+ ;; Call `dir-locals-collect-variables' once.
+ (let ((result (apply f args))
+entry former former-parent orig-former orig-former-parent)
+(when (and TeX-hack-former-dir-local-variables
+ (setq entry
+ (cdr
+ (assq major-mode
+;; MAJOR-MODE FORMER FORMER-PARENT
+'((plain-TeX-mode plain-tex-mode nil)
+ (LaTeX-mode latex-mode nil)
+ (docTeX-modedoctex-modelatex-mode)
+ (Texinfo-mode texinfo-mode nil)
+ (ConTeXt-mode context-mode nil)
+ (AmSTeX-modeams-tex-mode nil)
+ (japanese-plain-TeX-mode japanese-plain-tex-mode plain-tex-mode)
+ (japanese-LaTeX-mode japanese-latex-mode latex-mode))
+ (setq former (pop entry) ; former AUCTeX mode name, e.g. latex-mode
+former-parent (pop entry)) ; former parent mode name
+ (setq orig-former-parent (get former 'derived-mode-parent))
+ (put former 'derived-mode-parent former-parent)
+ ;; Very ugly hack to deceive `derived-mode-p'. Suppose
+ ;; - aaa-mode is an alias of bbb-mode
+ ;; - major-mode value is aaa-mode
+ ;; Then (derived-mode-p 'aaa-mode) returns nil on Emacs 28 and
+ ;; later, which makes `dir-locals-collect-variables' ignore a
+ ;; directory local variable entry for aaa-mode and look for an
+ ;; entry for bbb-mode instead. Hence we temporally make
+ ;; aaa-mode an alias of aaa-mode itself. :-(
+ (setq orig-former (symbol-function former))
+ (fset former former)
+ (unwind-protect
+ (let ((major-mode former))
+;; Append dir local vars with former mode names to return value.
+;; We need the next `setq' because `result' can be nil.
+(setq result (nconc result (apply f args
+;; Restore original state.
+(put former 'derived-mode-parent orig-former-parent)
+(fset former orig-former)))
+result))
+;; The above treatment fails to pick the "correct" value when
+;; .dir-locals.el assigns different value for the same variable
+;; between latex-mode and japanese-latex-mode. In that case, the
+;; value for latex-mode is picked up even in japanese-latex-mode
+;; buffer, but I cou
Re: AUCTeX and "builtin latex mode" integration
> (a) The mode names change as follows:
> plain-tex-mode -> plain-TeX-mode
> latex-mode -> LaTeX-mode
> doctex-mode-> docTeX-mode
> context-mode -> ConTeXt-mode
> texinfo-mode -> Texinfo-mode
> ams-tex-mode -> AmSTeX-mode
> japanese-plain-tex-mode -> japanese-plain-TeX-mode
> japanese-latex-mode -> japanese-LaTeX-mode
> context-en-mode DELETED
> context-nl-mode DELETED
> TeX-tex-mode UNCHANGED
> TeX-mode NEW
LGTM.
> (a-2) Now `TeX-add-local-master' adds entry of new mode names such as
> %%% Local Variables:
> %%% mode: LaTeX <-- not `latex'
> %%% End:
I don't like this very much: IMO the `mode:` cookie should really not specify
the "mode" to use but rather describe the file-type (Emacs could/should
aim to support "mime types" kind of names), and then which mode to use
for each file-type is decided based on the user's configuration.
> (b) All new modes (except TeX-tex-mode) are defined by
> `define-derived-mode'. The inheritance relations are:
[...]
> (c) The compatibility with the former mode names with respect to
> function call are retained by redirections or aliases.
No objection here.
> [Incompatibility]
> 1. directory local variables
> Currently, directory local variables are prepared in a entry like
> (latex-mode (reftex-label-alist . (("equation" ?e "eq:%f-" "\\eqref{%s}")
> ("align" ?e "eq:%f-" "\\eqref{%s}")
> ("gather" ?e "eq:%f-" "\\eqref{%s}")
> in .dir-locals.el. In this feature branch, mode name is `LaTeX-mode',
> thus this entry is ignored.
>
> The facility of major-mode-remap-list still does not handle this
> situation.
>
> We can announce this fact and ask users to rewrite their
> .dir-locals.el, but that can't be done if the user doesn't have write
> access for that particular .dir-locals.el. (Maybe we can ignore such
> corner cases?)
We should fix this for Emacs-30.
[ And then add some backward compatibility hack (presumably using
an advice for when AUCTeX is used on Emacs<30). ]
Maybe using `major-mode-remap-list` is not the right answer, tho (some
settings may be specific to a particular major mode and may cause
problems for other major modes used for the same file-type; I'm
thinking here of remapping between things like doc-view-mode and
pdf-view-mode, or image-mode and postscript-mode, or
image-mode and C-mode (for XPM files), ...).
We should make the directory-local code pay attention to:
- `derived-mode-p`.
- some additional "pseudo-derived-p" thingy for cases like `LaTeX-mode`
where there isn't a true `derived-mode-p` relation, but the other mode
can be treated as a sort of parent nevertheless. Maybe we should change
`derived-mode-p` so it handles that directly (i.e. offer some way for
a major mode to declare itself as being a descendant of other
modeS in addition to its "real" parent. We could (re)user
`define-child-mode` for that).
Maybe in addition to that, we need to be able to say in `dir-locals.el`
that a setting applies only for exactly this major mode, and not
its derivatives, maybe with a syntax like:
((= latex-mode) (reftex-label-alist
. (("equation" ?e "eq:%f-" "\\eqref{%s}")
("align" ?e "eq:%f-" "\\eqref{%s}")
("gather" ?e "eq:%f-" "\\eqref{%s}"
> 2. simple-minded reference to auto-mode-alist in emacs core
> As discussed in [2], when elisp codes look at auto-mode-alist
> directly and compare its content with `major-mode', new mode names
> such as `LaTeX-mode' get no hits and lead to failure.
> I added workaround for cedet/semantic/symref/grep.el, but similar
> problematic code still exists at least in cedet/semantic/idle.el:
> --
> (defun semantic-idle-scheduler-work-parse-neighboring-files ()
> ...(snip)...
> ;; Collect all patterns matching files of the same mode we edit.
> (mapc (lambda (pat) (and (eq (cdr pat) major-mode)
>(push (car pat) matching-auto-mode-patterns)))
> auto-mode-alist)
> --
IME, references to the `major-mode` variable in a package is a code
smell :-)
CEDET's code should obey `derived-mode-p` (and its own
`define-child-mode`), indeed. It shouldn't be hard to do.
Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi all,
I think that most coding task is done with
feature/fix-mode-names-overlap branch. The remaining major problems I'm
aware of are the following two, the detail of which are explained below
in this message.
1. incompatibility of directory local variables
2. simple-minded reference to auto-mode-alist in emacs core
Though there are still additional minor issues[1], I hope they don't
count as practical problems.
I'd like to hear what others think about the current status, especially
whether we need major change in principle/philosophy in the branch or
not. If not, I think I can start revising the documentations in the
branch.
[Detail]
(a) The mode names change as follows:
plain-tex-mode -> plain-TeX-mode
latex-mode -> LaTeX-mode
doctex-mode-> docTeX-mode
context-mode -> ConTeXt-mode
texinfo-mode -> Texinfo-mode
ams-tex-mode -> AmSTeX-mode
japanese-plain-tex-mode -> japanese-plain-TeX-mode
japanese-latex-mode -> japanese-LaTeX-mode
context-en-mode DELETED
context-nl-mode DELETED
TeX-tex-mode UNCHANGED
TeX-mode NEW
(a-1) New mode names are chosen to match the existing variables, so most
user codes would continue to work without modification. For
example, names of keymaps and hooks don't change.
(`AmS-TeX-mode-hook' is renamed to `AmSTeX-mode-hook', but
compatibility alias is provided by `define-obsolete-variable-alias'.)
(a-2) Now `TeX-add-local-master' adds entry of new mode names such as
%%% Local Variables:
%%% mode: LaTeX <-- not `latex'
%%% End:
(a-3) The mode aliases with `TeX-' prefix, e.g. `TeX-latex-mode', are
deleted except `TeX-tex-mode'.
(a-4) TeX-mode is meant for the base mode for other major modes. Its
role is to provide base keymap, hook and syntax table under the
same name with the current AUCTeX and run the initialization code
previously provided as `VirTeX-common-initialization'.
VirTeX-common-initialization no longer exists. It was absorbed
into major mode function `TeX-mode'.
(b) All new modes (except TeX-tex-mode) are defined by
`define-derived-mode'. The inheritance relations are:
text-mode --+-- TeX-mode
+-- Texinfo-mode
TeX-mode --+-- plain-TeX-mode
+-- LaTeX-mode
+-- ConTeXt-mode
plain-TeX-mode --+-- AmSTeX-mode
+-- japanese-plain-TeX-mode
LaTeX-mode --+-- docTeX-mode
+-- japanese-LaTeX-mode
This change introduces the following differences:
(b-1) Now that all modes (except TeX-tex-mode) has `text-mode' as their
ancestor, they inherit keymap and syntax table of `text-mode'.
(I added a piece of code to suppress "Text" entry in the menu bar,
defined in `text-mode-map'.)
(However, Texinfo-mode is exceptional in the following aspects:
(b-1-1) It doesn't inherit text-mode-syntax-table because it
simply uses built-in mode's texinfo-mode-syntax-table,
which is independent of text-mode-syntax-table. This
situation is the same with the current Texinfo mode.
(b-1-2) Texinfo-mode-map has TeX-mode-map as its direct parent.
This is the same with the current Texinfo mode. Now it
inherits text-mode-map indirectly through TeX-mode-map.
In addition, AmSTeX-mode-map still has TeX-mode-map as its parent
and doesn't inherit plain-TeX-mode-map; this is necessary not to
mess up the menu bar in AmSTeX mode. See the relevant codes in
plain-tex.el for detail.)
(b-2) AmSTeX-mode runs plain-TeX-mode-hook.
(b-3) There are new keymaps, hooks and abbrev tables:
Texinfo-mode-abbrev-table
japanese-plain-TeX-mode-map, japanese-LaTeX-mode-map
japanese-plain-TeX-mode-hook, japanese-LaTeX-mode-hook
japanese-plain-TeX-mode-abbrev-table,
japanese-LaTeX-mode-hook-abbrev-table
At last we have abbrev table in Texinfo mode.
(c) The compatibility with the former mode names with respect to
function call are retained by redirections or aliases.
(c-1) Former names which overlap with built-in modes, namely
plain-tex-mode, latex-mode, doctex-mode, texinfo-mode and tex-mode
are handled by redirections; the same override advices as before
are continued to used for emacs<29 while `major-mode-remap-alist'
is used for emacs 29 (and later).
(Therefore, if there are user code which call `latex-mode'
directly, built-in latex-mode runs instead of AUCTeX LaTeX-mode
in emacs 29.)
(c-2) Other former names, e.g. context-mode and japanese-latex-mode, are
handled by aliases such as `(defalias 'context-mode
#'ConTeXt-mode)'.
[Incompatibility]
1. directory local variables
Currently, directory local variables are prepared in a entry like
(latex-mode . ((reftex-label-alist . (("equation" ?e "eq:%f-" "\\eqref{%s}")
Re: AUCTeX and "builtin latex mode" integration
> (I infer that `xref-find-references' doesn't work in cperl-mode if it is > redirected from perl-mode by `major-mode-remap-alist', not altering > `auto-mode-alist'.) First, this inference of mine wasn't right because `semantic-symref-filepattern-alist' has the following entry: (cperl-mode "*.pl" "*.PL") > Stefan Monnier writes: >> I suppose that we can work around this issue if >> `semantic-symref-derive-find-filepatterns' is modified to look into >> `major-mode-remap-alist' in emacs 29 and later. However, I don't see >> clean solution for emacs<29. > Advise `semantic-symref-derive-find-filepatterns` so that if major mode > is `LaTeX-mode` is looks for both `LaTeX-mode` and `latex-mode`? I had the same idea, but most practical solution would be to add an entry like this to `semantic-symref-filepattern-alist' in feature/fix-mode-names-overlap branch: (LaTeX-mode "*.ltx" "*.sty" "*.cls" "*.clo" "*.bbl") Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> (defun semantic-symref-derive-find-filepatterns (&optional mode) > ...(snip)... > (let* ((mode (or mode major-mode)) <-- mode = LaTeX-mode > ...(snip)... > ;; No hit, try auto-mode-alist. > (dolist (X auto-mode-alist) <-- Looking at `auto-mode-alist' > (when (and (eq (cdr X) mode) >;; Only take in simple patterns, so try to convert this > one. >(string-match "\\.\\([^\\'>]+\\)'" (car X))) > (push (concat "*." (match-string 1 (car X))) pat Eww. Right, this code clearly needs to be beefed up if we want it to work more reliably. E.g. it needs to check not just (eq (cdr X) mode) but maybe something like (provided-mode-derived-p (cdr X) mode), so as to account for derived modes of `mode`, and it needs to use `major-mode-remap-alist` "in reverse" as well. And maybe pay attention to function aliases while at it. IOW it's an ugly heuristic function. > I suppose that we can work around this issue if > `semantic-symref-derive-find-filepatterns' is modified to look into > `major-mode-remap-alist' in emacs 29 and later. However, I don't see > clean solution for emacs<29. Advise `semantic-symref-derive-find-filepatterns` so that if major mode is `LaTeX-mode` is looks for both `LaTeX-mode` and `latex-mode`? Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan and all, In this message, I talk about topics of the following two categories: [A] Topics discussed so far [B] Incompatibility found anew [A] Topics discussed so far > Stefan Monnier writes: >> 2. ConTeXt modes > If at all possible, I recommend to use different names for the parent > mode and the dispatch function :-) I took the way to remove language-specific modes. Now `ConTeXt-en-mode' and `ConTeXt-nl-mode' became helper functions of `ConTeXt-mode' under the name `ConTeXt--mode-xx' and don't exist as major modes. This simplified the code much. If that choice turns out to be problematic, I try to find other way. >> 3. Additional menu item >> I chose `text-mode' as the parent of the base mode >> `TeX--VirTeX-mode' and `Texinfo-mode'. This is reasonable because >> those modes called `text-mode-hook' so far. On the other hand, there >> is a side effect that "Text" menu appears in the menu bar in all >> AUCTeX major modes, which may be distracting for some users. > Maybe `nil` (a.k.a. `fundamental-mode`) is a better parent, which more > closely matches the historical behavior of AUCTeX? I suppressed "Text" menu in AUCTeX major modes. Maybe AUCTeX should have a new user option to determine whether to hide the item or not. [B] Incompatibility found anew David Fussner's effort reported in another thread[1] unveiled another incompatibility in having `LaTeX-mode' as mode name rather than `latex-mode'. When I try the example given in the first message of the above thread in feature/fix-mode-names-overlap branch, it results in user errors No references found for: fontspec and No references found for: __hook_debug:n I tracked down the origin; it is in `semantic-symref-derive-find-filepatterns' in cedet/semantic/symref/grep.el: -- (defun semantic-symref-derive-find-filepatterns (&optional mode) ...(snip)... (let* ((mode (or mode major-mode)) <-- mode = LaTeX-mode ...(snip)... ;; No hit, try auto-mode-alist. (dolist (X auto-mode-alist) <-- Looking at `auto-mode-alist' (when (and (eq (cdr X) mode) ;; Only take in simple patterns, so try to convert this one. (string-match "\\.\\([^\\'>]+\\)'" (car X))) (push (concat "*." (match-string 1 (car X))) pat -- This function is called without optional argument MODE in `(cl-defmethod semantic-symref-perform-search ...)' in the same file, thus `mode' is let-bound to `LaTeX-mode' (the value of `major-mode'). The `dolist' loop searches for this `LaTeX-mode' in `auto-mode-alist' and gets no hits. Hence no files were searched for "fontspec" and "__hook_debug:n" in the above examples. In other words, `xref-find-references' doesn't work when `major-mode' is `LaTeX-mode'. (I infer that `xref-find-references' doesn't work in cperl-mode if it is redirected from perl-mode by `major-mode-remap-alist', not altering `auto-mode-alist'.) I suppose that we can work around this issue if `semantic-symref-derive-find-filepatterns' is modified to look into `major-mode-remap-alist' in emacs 29 and later. However, I don't see clean solution for emacs<29. I'm afraid that there are other similar inconsistencies in emacs core where elisp codes refer to the value of `auto-mode-alist'. Best regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65912
Re: AUCTeX and "builtin latex mode" integration
>>> 2. ConTeXt modes >> In the case of `ConTeXt-mode`, maybe the better option is to make the >> submodes be minor modes? > Hmm. Some difficulties for that idea come up to my mind: Well, I did say "maybe" :-) > 2. As they are minor mode, en-mode and nl-mode can be turned on at the >same time. Not necessarily. E.g. they can share the same (buffer-local) variable, like `overwrite-mode-binary` and `overwrite-mode-textual`. > 3. An entry of the form > mode: ConTeXt-en >in file local variable no longer works. Yeah, you can't name the minor mode `ConTeXt-en-mode` because that needs to be a function which enables `ConTeXt-mode` as well as the "en" minor mode. Tho maybe you can have a hack whereby the `ConTeXt-en-mode` minor mode calls `ConTeXt-mode` if the buffer is not yet using that mode [ And there's that "maybe" again. ] >> In `tex-mode` we've tried various approaches over the years, none of >> which are elegant :-( > Now I arrived at another approach without advice which makes use of > `major-mode-remap-alist'. How about this idea? That is indeed part of the motivation behind `major-mode-remap-alist`, tho I haven't yet tried to push that use to Emacs's `master`. Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan and all, > Stefan Monnier writes: > Looks good to me (I mean: it doesn't literally look good, but given what > we have, this seems about as clean as it gets). Thanks for your comments. Then I'll take this approach. > Only detail, I'd move the > (if (eq (symbol-function 'plain-TeX-mode) #'plain-tex-mode) > (defalias 'plain-TeX-mode nil)) > (if (eq (symbol-function 'LaTeX-mode) #'latex-mode) > (defalias 'LaTeX-mode nil)) > (if (eq (symbol-function 'TeX-mode) #'tex-mode) > (defalias 'TeX-mode nil)) > into a function and merge it with the similar code which uses > `auctex-function-definition`. All right. >> 2. ConTeXt modes > In the case of `ConTeXt-mode`, maybe the better option is to make the > submodes be minor modes? Hmm. Some difficulties for that idea come up to my mind: 1. It isn't clear what should be done when the mode is turned off. 2. As they are minor mode, en-mode and nl-mode can be turned on at the same time. 3. An entry of the form mode: ConTeXt-en in file local variable no longer works. Summing these up, I think it would be better to just turn them into ordinary functions. (patch 1) Actually, I don't think that the item 3 is a fundamental problem because context-nl-mode didn't work with error until my very recent commit[1] :-(. This means that there are practically no ConTeXt users who specify sub modes explicitly, I think. [1] https://git.savannah.gnu.org/cgit/auctex.git/commit/?id=f69211af6239da6d96864733c5b86e2ee3a5b6eb > That's not very pretty, indeed. The fundamental problem you're trying > to solve is the same as the one we have with `tex-mode` since that > function is used both as "parent mode" and as "dispatch to the > appropriate child-mode". Yes, my initial attempt was just an adaptation of the framework of `tex-mode' and its child modes. :-) It did use :around advice. > In `tex-mode` we've tried various approaches over the years, none of > which are elegant :-( Now I arrived at another approach without advice which makes use of `major-mode-remap-alist'. How about this idea? 1. Separete the role of "parent mode" and "dispatch function". 2. Add an entry (tex-mode . DISPATCH-FUNCTION) to `major-mode-remap-alist'. In other words, this is the basic idea: --- tex-mode.el -- (defun tex--dispatch () (funcall (tex--guess-mode))) ;;;###autoload (add-to-list 'major-mode-remap-alist '(tex-mode . tex--dispatch)) -- This is parallel to what "feature/fix-mode-names-overlap" branch does for `TeX-tex-mode' now. I expect `tex--redirect-to-submode' is no longer necessary. This approach is incompatible with the current AUCTeX redirection facility relying on (advice-add 'tex-mode :override 'TeX-tex-mode '((depth . -10))) . However, we can incorporate mimimal modification in the master branch of AUCTeX so that tex-site.el uses `major-mode-remap-alist' instead of advice for Emacs 29 or higher. Then the above treatment to tex-mode.el will become compatible with AUCTeX even before "feature/fix-mode-names-overlap" branch is merged into master branch. And we can use the same approach for ConTeXt modes for Emacs 29 or higher. If we redirect context mode to a suitable dispatch function by `major-mode-remap-alist', we can have ConTeXt-xx-mode as derived major mode of ConTeXt-mode in a clean way. (patch 2) (If we actually take this approach, we need to have codes for Emacs<29 and Emacs>28 separately.) >> 3. Additional menu item > Maybe `nil` (a.k.a. `fundamental-mode`) is a better parent, which more > closely matches the historical behavior of AUCTeX? > TeX is one of those formats that sits halfway between `text-mode` and > `prog-mode` (like (SG|X)ML, as well). That's a possible option, of course. Hmm, I realized that (define-key TeX-mode-map [menu-bar text] #'undefined) hides the "Text" menu. This would be another option. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine >From 07b0b7b428139a712650beee5050bbb76d826f69 Mon Sep 17 00:00:00 2001 From: Ikumi Keita Date: Mon, 28 Aug 2023 18:22:45 +0900 Subject: [PATCH] Simplify ConTeXt modes This branch no longer offers language-specific major modes for ConTeXt. * context-en.el (ConTeXt-en-mode): Rename to ConTeXt--mode-en and stop being major mode. (context-en-mode): Delete alias. * context-nl.el (ConTeXt-nl-mode): Rename to ConTeXt--mode-nl and stop being major mode. (context-nl-mode): Delete alias. * context.el (ConTeXt-mode): Revert to a form similar to the one before introducing `define-derived-mode'. Call ConTeXt--mode-xx instead of ConTeXt-xx-mode. (ConTeXt--auto-mode): Delete. --- context-en.el | 21 + context-nl.el | 21 + context.el| 23 --- 3 files changed, 14 insertions(+), 51 deletions(-) diff --git a/context-en.el b/context-en.el index 26f84564..c63a4fd1 100644 --- a/context-en
Re: AUCTeX and "builtin latex mode" integration
>This is much unsatisfactory. I'm currently thinking to apply the >attached patch to sort out the disorders of mode names. It works as >follows: >(a) It uses the names without `TeX-' prefix for LaTeX-mode, >plain-TeX-mode and TeX-mode. >(b) Those mode definitions are overwritten, prior to emacs 29, when >tex-mode.el is loaded. So the patch saves the function >definitions of AUCTeX major modes in the symbol property >`auctex-function-definition', and restores them after tex-mode.el >is loaded via `with-eval-after-load'. Looks good to me (I mean: it doesn't literally look good, but given what we have, this seems about as clean as it gets). Only detail, I'd move the (if (eq (symbol-function 'plain-TeX-mode) #'plain-tex-mode) (defalias 'plain-TeX-mode nil)) (if (eq (symbol-function 'LaTeX-mode) #'latex-mode) (defalias 'LaTeX-mode nil)) (if (eq (symbol-function 'TeX-mode) #'tex-mode) (defalias 'TeX-mode nil)) into a function and merge it with the similar code which uses `auctex-function-definition`. > 2. ConTeXt modes >The design of ConTeXt modes doesn't match well with >`define-derived-mode' as explained below. >ConTeXt modes consist of "primary" mode `ConTeXt-mode' and "sub" >modes such as `ConTeXt-en-mode' and `ConTeXt-nl-mode'. Sub modes are >expected to work when they are called explicitly as well. >At first sight, it seems natural to implement the sub modes as >derived modes of the primary mode. However, simple implementation >doesn't work because the primary `ConTeXt-mode' is supposed to >detect the document's language (english, dutch...) and call the sub >mode according to the detected language. Thus simple implementation >leads to loop of the primary mode and duplication of hook calls. >I chose to implement the sub modes as derived modes of the primary >mode and move the "detecting the language and calling the sub mode" >phase of the primary mode into `change-major-mode-after-body-hook'. >In addition, the phase now bypasses call to the sub mode and calls >the "body" part of the sub mode independently. Hence the sub mode's >keymap and hook are ignored in that case. This might be considered as >a bad behavior. >In addition, I'm not sure whether such usage is suitable for >`change-major-mode-after-body-hook' or not. That's not very pretty, indeed. The fundamental problem you're trying to solve is the same as the one we have with `tex-mode` since that function is used both as "parent mode" and as "dispatch to the appropriate child-mode". In `tex-mode` we've tried various approaches over the years, none of which are elegant :-( What have now is: (define-derived-mode tex-mode text-mode "generic-TeX" [...] (tex-common-initialization)) (advice-add 'tex-mode :around #'tex--redirect-to-submode ;; Give it lower precedence than normal advice, so ;; AUCTeX's advice takes precedence over it. '((depth . 50))) (defvar tex-mode--recursing nil) (defun tex--redirect-to-submode (orig-fun) [...] (if (or delay-mode-hooks tex-mode--recursing) [...])) In the case of `ConTeXt-mode`, maybe the better option is to make the submodes be minor modes? If at all possible, I recommend to use different names for the parent mode and the dispatch function :-) > 3. Additional menu item >I chose `text-mode' as the parent of the base mode >`TeX--VirTeX-mode' and `Texinfo-mode'. This is reasonable because >those modes called `text-mode-hook' so far. On the other hand, there >is a side effect that "Text" menu appears in the menu bar in all >AUCTeX major modes, which may be distracting for some users. Maybe `nil` (a.k.a. `fundamental-mode`) is a better parent, which more closely matches the historical behavior of AUCTeX? TeX is one of those formats that sits halfway between `text-mode` and `prog-mode` (like (SG|X)ML, as well). > 4. Directory local variables >(a) I simplified the way to have `LaTeX-mode' as the value of >`major-mode' of `japanese-LaTeX-mode' while it can read directory >local variables prepared for japanese-LaTeX-mode. Now there is a >line > :after-hook (setq major-mode 'LaTeX-mode) >in the definition of `(define-derived-mode japanese-LaTeX-mode...' >and cumbersome interaction with `hack-local-variables' is >discarded. >This solution works for most cases, but would break if the mode >hooks contain user codes which assume mode name without >`japanese-' prefix. >If it turns out that such breakage does exist and no workaround >is found, we'd have to go back to the former approach. FWIW, that's a cleaner solution than what I had come up when I looked at it. Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi all, I pushed a commit, to the feature branch, that uses `define-derived-mode' for major modes such as LaTeX-mode. I chose `TeX--VirTeX-mode' as the name of base modes except Texinfo mode. Here are some related issues I'd like to hear thoughts of those interested in this topic. 1. Ugly defvaralias'es Contrary to my expectation, `define-derived-mode' doesn't allow to configure the names for the keymap and hook. Thus I have to include very ugly defvaralias'es like (defvaralias 'TeX-LaTeX-mode-map 'LaTeX-mode-map) and (defvaralias 'TeX-LaTeX-mode-hook 'LaTeX-mode-hook) in order to keep compatibility. Similar aliases are injected for TeX-plain-TeX-mode and TeX--VirTeX-mode as well. This is much unsatisfactory. I'm currently thinking to apply the attached patch to sort out the disorders of mode names. It works as follows: (a) It uses the names without `TeX-' prefix for LaTeX-mode, plain-TeX-mode and TeX-mode. (b) Those mode definitions are overwritten, prior to emacs 29, when tex-mode.el is loaded. So the patch saves the function definitions of AUCTeX major modes in the symbol property `auctex-function-definition', and restores them after tex-mode.el is loaded via `with-eval-after-load'. I confirmed that this idea works as expected, although it's rather tricky. 2. ConTeXt modes The design of ConTeXt modes doesn't match well with `define-derived-mode' as explained below. ConTeXt modes consist of "primary" mode `ConTeXt-mode' and "sub" modes such as `ConTeXt-en-mode' and `ConTeXt-nl-mode'. Sub modes are expected to work when they are called explicitly as well. At first sight, it seems natural to implement the sub modes as derived modes of the primary mode. However, simple implementation doesn't work because the primary `ConTeXt-mode' is supposed to detect the document's language (english, dutch...) and call the sub mode according to the detected language. Thus simple implementation leads to loop of the primary mode and duplication of hook calls. I chose to implement the sub modes as derived modes of the primary mode and move the "detecting the language and calling the sub mode" phase of the primary mode into `change-major-mode-after-body-hook'. In addition, the phase now bypasses call to the sub mode and calls the "body" part of the sub mode independently. Hence the sub mode's keymap and hook are ignored in that case. This might be considered as a bad behavior. In addition, I'm not sure whether such usage is suitable for `change-major-mode-after-body-hook' or not. 3. Additional menu item I chose `text-mode' as the parent of the base mode `TeX--VirTeX-mode' and `Texinfo-mode'. This is reasonable because those modes called `text-mode-hook' so far. On the other hand, there is a side effect that "Text" menu appears in the menu bar in all AUCTeX major modes, which may be distracting for some users. 4. Directory local variables (a) I simplified the way to have `LaTeX-mode' as the value of `major-mode' of `japanese-LaTeX-mode' while it can read directory local variables prepared for japanese-LaTeX-mode. Now there is a line :after-hook (setq major-mode 'LaTeX-mode) in the definition of `(define-derived-mode japanese-LaTeX-mode...' and cumbersome interaction with `hack-local-variables' is discarded. This solution works for most cases, but would break if the mode hooks contain user codes which assume mode name without `japanese-' prefix. If it turns out that such breakage does exist and no workaround is found, we'd have to go back to the former approach. (b) The discrepancy between directory local variable and `major-mode-remap-alist' (bug#61210) still remains. Best regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine 0001-canonicalize-mode-name.gz Description: Avoid defvaralias
Re: AUCTeX and "builtin latex mode" integration
Hi Arash, > Arash Esbati writes: > Yes, it was about "Unfriendly take-over of AUCTeX once installed", but I > think somewhere in the discussion, there was also sort of > "latex-mode-hook vs. LaTeX-mode-hook is confusing". I haven't arrived at such claims yet. > I was thinking about the mode names only; and not the namespace for > functions/variables and the file names. Suppose the major mode is > called AUCLaTeX-mode, then we have `AUCLaTeX-mode-hook' and we then > define an alias `LaTeX-mode-hook' for a certain period of time. Does > this make sense? Do you mean that new prefix is used for only mode/hook/keymap/syntax table/abbrev table names and `LaTeX-mode-hook' etc. will be removed in future? Hmm. That might be a possible option, but it doesn't seem clean to me. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> d. Directory local variables >> Maybe the simplest option is to get used to the idea of setting >> `derived-mode-parent` manually for those modes which are "morally" >> a child mode, even though the implementation (and behavior) does not >> inherit much if anything? > > Do you mean > (put 'LaTeX-mode 'derived-mode-parent 'latex-mode) > ? In that case, `LaTeX-mode' can't have AUCTeX common TeX mode (in my > personal plan, `TeX-VirTeX-mode') as its parent. Ah, right, that won't work. > Is there any way to assign multiple parent modes to `LaTeX-mode'? Not currently, no. Allowing `define-derived-mode` to inherit from multiple modes is technically difficult, but extending `provided-mode-derived-p` to support multiple parents should be fairly easy, so maybe we should do that. > [From your post to bug#61211] >> I'm also thinking that maybe `set-auto-mode` should remember the name >> of the "mode function" it called so we could consult this (in addition >> to the value of `major-mode`) when applying directory-local vars? > If that is possible, it will be a good solution. I already save some "old mode" info in `set-auto-mode--last` (for the purpose of `major-mode-remap-alist`), so maybe all it takes is to use it in the code handling directory-local variables? It does run the risk of setting vars for an unrelated mode, but maybe it's OK (or maybe it needs to use the "old mode" only when the real mode has no directory-local vars set or something like that)? Stefan
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes: > I think the problem lies elsewhere: when the desktop file says "use > `latex-mode`", how can we distinguish the two cases: > - it's an "old" desktop file, so we should probably redirect it to > `LaTeX-mode`). > - it's a "new" desktop file but the user really decided to use > `latex-mode` for that buffer so we should probably not redirect. > Then again, in both cases it's not 100% sure what is the right choice, > so maybe it doesn't matter that much what we do. Understood. d. Directory local variables > Maybe the simplest option is to get used to the idea of setting > `derived-mode-parent` manually for those modes which are "morally" > a child mode, even though the implementation (and behavior) does not > inherit much if anything? Do you mean (put 'LaTeX-mode 'derived-mode-parent 'latex-mode) ? In that case, `LaTeX-mode' can't have AUCTeX common TeX mode (in my personal plan, `TeX-VirTeX-mode') as its parent. Is there any way to assign multiple parent modes to `LaTeX-mode'? [From your post to bug#61211] > I'm also thinking that maybe `set-auto-mode` should remember the name > of the "mode function" it called so we could consult this (in addition > to the value of `major-mode`) when applying directory-local vars? If that is possible, it will be a good solution. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
Hi Keita, Ikumi Keita writes: >> Arash Esbati writes: >> I have to re-read the thread, but wasn't a point also that latex-mode >> and LaTeX-mode are also confusing to some users? > > According to my (unreliable) memory :-), ;-) > the thread began with a complaint that "I customized latex-mode-hook > because the mode name is latex-mode, but that customization is > ignored. Why?" So the similarity between latex-mode and LaTeX-mode > doesn't relate directly in this particular case. Yes, it was about "Unfriendly take-over of AUCTeX once installed", but I think somewhere in the discussion, there was also sort of "latex-mode-hook vs. LaTeX-mode-hook is confusing". At any rate, we should also have a look at this issue while we're at it. >> If so, can we think about coming up with mode names instead of >> camel-case'ing the built-in ones? > > Maybe the similarity can be a source of future trouble. However, there > is already a huge amount of codes with "LaTeX-" prefix in the current > AUCTeX and I'm afraid that it isn't realistic to rewrite all of them. I was thinking about the mode names only; and not the namespace for functions/variables and the file names. Suppose the major mode is called AUCLaTeX-mode, then we have `AUCLaTeX-mode-hook' and we then define an alias `LaTeX-mode-hook' for a certain period of time. Does this make sense? > Thanks, as you can see, it worked well. 👍 Best, Arash
Re: AUCTeX and "builtin latex mode" integration
>> Not sure either, but we can arrange to re-instate the aliases (they're >> not autoloads) upon unload, if so desired (actually, I think all it >> takes (in Emacs-29) is to use `(defalias 'LaTeX-mode nil)` instead of >> `(fset 'LaTeX-mode nil)`. Also, while I'm here, I think we should check >> that they are aliases before removing them). > Thanks, I didn't know that `defalias' allows an argument which isn't a > function. I'll check later. `defalias` is just like `fset` except that it records the operation as a "definition" (i.e. for `load-history`, `unload-feature`, ...). A bit like the difference between `setq` and `defconst/defvar`. >>> b. Abbrev table User abbrevs in, say, latex-mode-abbrev-table aren't >>> inherited to AUCTeX LaTeX mode. >> Is there a particular reason why `LaTeX-mode-abbrev-table` isn't made to >> inherit from `latex-mode-abbrev-table`? > No, I think we can manipulate the abbrev table property by > `abbrev-table-get' and `abbrev-table-put'. Indeed, you can use those to set the `:parent` property. > (Or maybe we should add an optional argument to the elisp macro > `TeX-abbrev-mode-setup' for such an additional parent table.) Right. In any case, it's a "small matter of coding". >>> c. desktop.el records the major mode name in the saved sessions. When >>> users have saved sessions with the name, say, latex-mode and >>> install this patch before the next session, desktop.el restores >>> them in wrong mode in the next session if `major-mode-remap-alist' >>> is available. > >> Indeed, I hadn't thought about that use case. I can't think of a good >> way to "fix" it since it seems hard/impossible to reliably detect if >> that desktop was saved with an Emacs using the "old AUCTeX names" or the >> "new AUCTeX names". > >> The best might be to accept the breakage and add a clear "release note" >> about it? > > Doesn't it help to modify `desktop-restore-file-buffer' to look up > `major-mode-map-alist' around here?: > -- > (defun desktop-restore-file-buffer (buffer-filename > [...] > (and (not (eq major-mode desktop-buffer-major-mode)) > (functionp desktop-buffer-major-mode) > (funcall desktop-buffer-major-mode)) > -- I think the problem lies elsewhere: when the desktop file says "use `latex-mode`", how can we distinguish the two cases: - it's an "old" desktop file, so we should probably redirect it to `LaTeX-mode`). - it's a "new" desktop file but the user really decided to use `latex-mode` for that buffer so we should probably not redirect. Then again, in both cases it's not 100% sure what is the right choice, so maybe it doesn't matter that much what we do. >>> d. Directory local variables >>> d-1 >>> Directory local variables prepared for, say, `latex-mode' aren't >>> picked up by AUCTeX LaTeX-mode when `major-mode-remap-alist' is >>> available. >>> The reason is that `hack-local-variables' doesn't understand >>> that `LaTeX-mode' is redirected from `latex-mode'. > >> This is something that we need to fix before this can make it into >> a release, I think. IIRC there's an open bug report on Debbugs >> about it. > > I think you mean bug#61211[1], but it's for type d-2. For type d-1, I > briefly mentioned in bug#61210[2] as just a subsidary topic. > > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61211 > [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61210 Maybe the simplest option is to get used to the idea of setting `derived-mode-parent` manually for those modes which are "morally" a child mode, even though the implementation (and behavior) does not inherit much if anything? Usually we have the convention that a child mode will call the parent mode, run the parent mode's hook, that its keymap inherits from the parent mode's keymap, ... but that's not always practical. >> Agreed (luckily: making it use `define-derived-mode` would be painful, >> as you can see in `tex-mode`). > > How about separating the two role of `tex-mode'? > -- > (define-derived-mode tex-base-mode text-mode "generic-TeX" > [...] > (tex-common-initialization)) [...] > (defun tex-mode () > (funcall (tex--guess-mode))) This would have as a consequence of changing the parent mode's var names for the hook, mode map, ... We could do that, but I think the end result (user-facing names) of the current solution is fairly "elegant" even though the implementation isn't. IOW, I think it's fairly natural to define an "abstract parent mode" and then arrange for calls to this abstract parent mode to auto-dispatch to one of the child modes. But yes, the implementation sucks :-( Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi Arash, > Arash Esbati writes: > I have to re-read the thread, but wasn't a point also that latex-mode > and LaTeX-mode are also confusing to some users? According to my (unreliable) memory :-), the thread began with a complaint that "I customized latex-mode-hook because the mode name is latex-mode, but that customization is ignored. Why?" So the similarity between latex-mode and LaTeX-mode doesn't relate directly in this particular case. > If so, can we think about coming up with mode names instead of > camel-case'ing the built-in ones? Maybe the similarity can be a source of future trouble. However, there is already a huge amount of codes with "LaTeX-" prefix in the current AUCTeX and I'm afraid that it isn't realistic to rewrite all of them. > I don't use magit, but you should be ok on command line doing: > $ git switch feature-branch-name > $ git commit > $ git push -u origin feature-branch-name > where -u is a shortcut for --set-upstream as described by Stefan. Thanks, as you can see, it worked well. >> (By the way, I have come up with only a poor name >> "feature/distinct-mode-name". Please tell me another name if you find >> a better one.) > I think we can live with that :-) I incorporated Stefan's idea. Thanks, Stefan. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan and all,
> Stefan Monnier writes:
> FWIW, here's how I'd do it (using the command line):
> git push --set-upstream origin HEAD:feature/fix-mode-names-overlap
Thanks, it worked well.
>> a. Invoked mode
>> a-1
>> Suppose that Alice prefers built-in plain-tex-mode over AUCTeX and
>> customized `TeX-modes' to remove `plain-tex-mode' from it. She
>> also want AUCTeX-style auto-detection for files with .tex
>> extension so leave `tex-mode' in `TeX-modes'. After my patch is
>> applied, when she openes a plain tex file without mode: tag in the
>> File Local Variables section, it's opened in AUCTeX plain TeX mode
>> against her expectation.
>> The reason is that `TeX-tex-mode' calls AUCTeX mode names
>> according to the change in `TeX-format-list'.
> Maybe `TeX-format-list` should stay as it is, and `TeX-tex-mode` should
> instead rely on `TeX-modes` or `major-mode-remap-alist` to decide which
> function to call?
It's a possible way, indeed. I'll ponder further.
>> a-2
>> Suppose that a site admin sets up AUCTeX as the default TeX modes
>> in site-start.el but Bob disabled them by (unload-feature
>> 'tex-site) in his init.el because he prefers built-in modes. In
>> addition, Bob has some latex files annotated with -*- LaTeX -*-,
>> which he recieved from someone else. After my patch is applied,
>> when he opens such a file, it results in File mode specification
>> error.
>> The reason is that tex-site.el is changed to delete the aliases
>> plain-TeX-mode -> plain-tex-mode, LaTeX-mode -> latex-mode.
>>
>> I think these are corner cases and am not sure whether we should
>> keep compatibility.
> Not sure either, but we can arrange to re-instate the aliases (they're
> not autoloads) upon unload, if so desired (actually, I think all it
> takes (in Emacs-29) is to use `(defalias 'LaTeX-mode nil)` instead of
> `(fset 'LaTeX-mode nil)`. Also, while I'm here, I think we should check
> that they are aliases before removing them).
Thanks, I didn't know that `defalias' allows an argument which isn't a
function. I'll check later.
>> b. Abbrev table
>> User abbrevs in, say, latex-mode-abbrev-table aren't inherited to
>> AUCTeX LaTeX mode.
> Is there a particular reason why `LaTeX-mode-abbrev-table` isn't made to
> inherit from `latex-mode-abbrev-table`?
No, I think we can manipulate the abbrev table property by
`abbrev-table-get' and `abbrev-table-put'.
(Or maybe we should add an optional argument to the elisp macro
`TeX-abbrev-mode-setup' for such an additional parent table.)
>> c. desktop.el records the major mode name in the saved sessions. When
>> users have saved sessions with the name, say, latex-mode and
>> install this patch before the next session, desktop.el restores
>> them in wrong mode in the next session if `major-mode-remap-alist'
>> is available.
> Indeed, I hadn't thought about that use case. I can't think of a good
> way to "fix" it since it seems hard/impossible to reliably detect if
> that desktop was saved with an Emacs using the "old AUCTeX names" or the
> "new AUCTeX names".
> The best might be to accept the breakage and add a clear "release note"
> about it?
Doesn't it help to modify `desktop-restore-file-buffer' to look up
`major-mode-map-alist' around here?:
--
(defun desktop-restore-file-buffer (buffer-filename
[...]
(and (not (eq major-mode desktop-buffer-major-mode))
(functionp desktop-buffer-major-mode)
(funcall desktop-buffer-major-mode))
--
>> d. Directory local variables
>> d-1
>> Directory local variables prepared for, say, `latex-mode' aren't
>> picked up by AUCTeX LaTeX-mode when `major-mode-remap-alist' is
>> available.
>> The reason is that `hack-local-variables' doesn't understand
>> that `LaTeX-mode' is redirected from `latex-mode'.
> This is something that we need to fix before this can make it into
> a release, I think. IIRC there's an open bug report on Debbugs
> about it.
I think you mean bug#61211[1], but it's for type d-2. For type d-1, I
briefly mentioned in bug#61210[2] as just a subsidary topic.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61211
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61210
> But it's not even clear what should be a good solution (from
> Emacs's point of view).
Indeed.
> Maybe in the mean time AUCTeX can "fix" it on its side by adding some
> clever piece of advice on the directory-local-vars code or by setting
> `derived-mode-parent`?
I'll try.
>> d-2
>> Similar issue related to "superficial major modes" such as
>> japanese-LaTeX-mode still persists for directory local
>> variables[1] regardless whether `major-mode-remap-alist' is
>> available or not.
>> I'm still relying on ugly hack currently used for
>> japanese-{plain-tex,latex}-mode[2].
>>
>> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61211
>> [2] The following code
Re: AUCTeX and "builtin latex mode" integration
On Mon, May 8, 2023 at 6:45 PM Arash Esbati wrote: > > Ikumi Keita writes: > > > I attach a tentative patch to make AUCTeX major mode names not overwrap > > built-in TeX modes. In this patch, the new mode names (value of > > `major-mode') are > > - plain-TeX-mode > > - LaTeX-mode > > - docTeX-mode > > - Texinfo-mode > > - ConTeXt-mode > > - AmSTeX-mode > > (There are additional renamed modes > >+ japanese-plain-TeX-mode > >+ japanese-LaTeX-mode > >+ ConTeXt-en-mode > >+ ConTeXt-nl-mode > > but they don't have their own `major-mode' value. > > The name and role of `TeX-tex-mode' doesn't change.) > > Thanks for working on this, Keita. I have to re-read the thread, but > wasn't a point also that latex-mode and LaTeX-mode are also confusing to > some users? If so, can we think about coming up with mode names instead > of camel-case'ing the built-in ones? In fact, the latex-mode and LaTeX-mode are both the valid modes names referred in the Emacs reftex manual: (add-hook 'LaTeX-mode-hook 'turn-on-reftex) ; with AUCTeX LaTeX mode (add-hook 'latex-mode-hook 'turn-on-reftex) ; with Emacs latex mode [1] https://www.gnu.org/software/emacs/manual/html_node/reftex/Installation.html Best, Zhao > > I think that its core functionality works as > > expected. If you are interested in this feature, please give it a try. > > > > 1. I'd like to push it to savannah server as a feature branch of AUCTeX > >repository (it isn't ready to merge into master branch yet.) Do you > >think it's OK? > > Yes, please do so. > > > If so, I'm not sure how to do that so I'd like to confirm. > > I don't use magit, but you should be ok on command line doing: > > $ git switch feature-branch-name > $ git commit > $ git push -u origin feature-branch-name > > where -u is a shortcut for --set-upstream as described by Stefan. > > > (By the way, I have come up with only a poor name > > "feature/distinct-mode-name". Please tell me another name if you find > > a better one.) > > I think we can live with that :-) > > Best, Arash >
Re: AUCTeX and "builtin latex mode" integration
Ikumi Keita writes: > I attach a tentative patch to make AUCTeX major mode names not overwrap > built-in TeX modes. In this patch, the new mode names (value of > `major-mode') are > - plain-TeX-mode > - LaTeX-mode > - docTeX-mode > - Texinfo-mode > - ConTeXt-mode > - AmSTeX-mode > (There are additional renamed modes >+ japanese-plain-TeX-mode >+ japanese-LaTeX-mode >+ ConTeXt-en-mode >+ ConTeXt-nl-mode > but they don't have their own `major-mode' value. > The name and role of `TeX-tex-mode' doesn't change.) Thanks for working on this, Keita. I have to re-read the thread, but wasn't a point also that latex-mode and LaTeX-mode are also confusing to some users? If so, can we think about coming up with mode names instead of camel-case'ing the built-in ones? > I think that its core functionality works as > expected. If you are interested in this feature, please give it a try. > > 1. I'd like to push it to savannah server as a feature branch of AUCTeX >repository (it isn't ready to merge into master branch yet.) Do you >think it's OK? Yes, please do so. > If so, I'm not sure how to do that so I'd like to confirm. I don't use magit, but you should be ok on command line doing: $ git switch feature-branch-name $ git commit $ git push -u origin feature-branch-name where -u is a shortcut for --set-upstream as described by Stefan. > (By the way, I have come up with only a poor name > "feature/distinct-mode-name". Please tell me another name if you find > a better one.) I think we can live with that :-) Best, Arash
Re: AUCTeX and "builtin latex mode" integration
Hi, and thanks, it's great to see concrete movement towards trying to
fix this longstanding issue.
> 1. I'd like to push it to savannah server as a feature branch of AUCTeX
>repository (it isn't ready to merge into master branch yet.) Do you
>think it's OK?
Can't of any reason why not, but I'll leave it to the AUCTeX guys to
give a definitive answer.
>If so, I'm not sure how to do that so I'd like to confirm.
FWIW, here's how I'd do it (using the command line):
git push --set-upstream origin HEAD:feature/fix-mode-names-overlap
>a. Invoked mode
> a-1
> Suppose that Alice prefers built-in plain-tex-mode over AUCTeX and
> customized `TeX-modes' to remove `plain-tex-mode' from it. She
> also want AUCTeX-style auto-detection for files with .tex
> extension so leave `tex-mode' in `TeX-modes'. After my patch is
> applied, when she openes a plain tex file without mode: tag in the
> File Local Variables section, it's opened in AUCTeX plain TeX mode
> against her expectation.
> The reason is that `TeX-tex-mode' calls AUCTeX mode names
> according to the change in `TeX-format-list'.
Maybe `TeX-format-list` should stay as it is, and `TeX-tex-mode` should
instead rely on `TeX-modes` or `major-mode-remap-alist` to decide which
function to call?
> a-2
> Suppose that a site admin sets up AUCTeX as the default TeX modes
> in site-start.el but Bob disabled them by (unload-feature
> 'tex-site) in his init.el because he prefers built-in modes. In
> addition, Bob has some latex files annotated with -*- LaTeX -*-,
> which he recieved from someone else. After my patch is applied,
> when he opens such a file, it results in File mode specification
> error.
> The reason is that tex-site.el is changed to delete the aliases
> plain-TeX-mode -> plain-tex-mode, LaTeX-mode -> latex-mode.
>
> I think these are corner cases and am not sure whether we should
> keep compatibility.
Not sure either, but we can arrange to re-instate the aliases (they're
not autoloads) upon unload, if so desired (actually, I think all it
takes (in Emacs-29) is to use `(defalias 'LaTeX-mode nil)` instead of
`(fset 'LaTeX-mode nil)`. Also, while I'm here, I think we should check
that they are aliases before removing them).
>b. Abbrev table
> User abbrevs in, say, latex-mode-abbrev-table aren't inherited to
> AUCTeX LaTeX mode.
Is there a particular reason why `LaTeX-mode-abbrev-table` isn't made to
inherit from `latex-mode-abbrev-table`?
>c. desktop.el records the major mode name in the saved sessions. When
> users have saved sessions with the name, say, latex-mode and
> install this patch before the next session, desktop.el restores
> them in wrong mode in the next session if `major-mode-remap-alist'
> is available.
Indeed, I hadn't thought about that use case. I can't think of a good
way to "fix" it since it seems hard/impossible to reliably detect if
that desktop was saved with an Emacs using the "old AUCTeX names" or the
"new AUCTeX names".
The best might be to accept the breakage and add a clear "release note"
about it?
>d. Directory local variables
> d-1
> Directory local variables prepared for, say, `latex-mode' aren't
> picked up by AUCTeX LaTeX-mode when `major-mode-remap-alist' is
> available.
> The reason is that `hack-local-variables' doesn't understand
> that `LaTeX-mode' is redirected from `latex-mode'.
This is something that we need to fix before this can make it into
a release, I think. IIRC there's an open bug report on Debbugs
about it. But it's not even clear what should be a good solution (from
Emacs's point of view).
Maybe in the mean time AUCTeX can "fix" it on its side by adding some
clever piece of advice on the directory-local-vars code or by setting
`derived-mode-parent`?
> d-2
> Similar issue related to "superficial major modes" such as
> japanese-LaTeX-mode still persists for directory local
> variables[1] regardless whether `major-mode-remap-alist' is
> available or not.
> I'm still relying on ugly hack currently used for
> japanese-{plain-tex,latex}-mode[2].
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61211
> [2] The following code in tex-jp.el.
I hope whichever fix we use for `d-1` will be applicable for `d-2`.
>- TeX-tex-mode is an exception. It doesn't need
> `define-derived-mode' in my opinion.
Agreed (luckily: making it use `define-derived-mode` would be painful,
as you can see in `tex-mode`).
Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi all,
I attach a tentative patch to make AUCTeX major mode names not overwrap
built-in TeX modes. In this patch, the new mode names (value of
`major-mode') are
- plain-TeX-mode
- LaTeX-mode
- docTeX-mode
- Texinfo-mode
- ConTeXt-mode
- AmSTeX-mode
(There are additional renamed modes
+ japanese-plain-TeX-mode
+ japanese-LaTeX-mode
+ ConTeXt-en-mode
+ ConTeXt-nl-mode
but they don't have their own `major-mode' value.
The name and role of `TeX-tex-mode' doesn't change.)
I think that its core functionality works as
expected. If you are interested in this feature, please give it a try.
1. I'd like to push it to savannah server as a feature branch of AUCTeX
repository (it isn't ready to merge into master branch yet.) Do you
think it's OK? If so, I'm not sure how to do that so I'd like to
confirm.
Now I have the following entries in .git/config. The name of my local
branch is "feature/distinct-mode-name".
--
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
...
[branch "feature/distinct-mode-name"]
remote = .
merge = refs/heads/master
--
Probably, I should, in Magit, type b p on the local feature branch
and set "origin" as the value of pushRemote. Then is it ready to push
by typing "P"? Or should I do something else/different?
(By the way, I have come up with only a poor name
"feature/distinct-mode-name". Please tell me another name if you find
a better one.)
2. Incompatibility
I'm currently aware of the following incompatibilities:
a. Invoked mode
b. Abbrev table
c. desktop.el
d. Directory local variables
There may be other issues I don't realize.
a. Invoked mode
a-1
Suppose that Alice prefers built-in plain-tex-mode over AUCTeX and
customized `TeX-modes' to remove `plain-tex-mode' from it. She
also want AUCTeX-style auto-detection for files with .tex
extension so leave `tex-mode' in `TeX-modes'. After my patch is
applied, when she openes a plain tex file without mode: tag in the
File Local Variables section, it's opened in AUCTeX plain TeX mode
against her expectation.
The reason is that `TeX-tex-mode' calls AUCTeX mode names
according to the change in `TeX-format-list'.
a-2
Suppose that a site admin sets up AUCTeX as the default TeX modes
in site-start.el but Bob disabled them by (unload-feature
'tex-site) in his init.el because he prefers built-in modes. In
addition, Bob has some latex files annotated with -*- LaTeX -*-,
which he recieved from someone else. After my patch is applied,
when he opens such a file, it results in File mode specification
error.
The reason is that tex-site.el is changed to delete the aliases
plain-TeX-mode -> plain-tex-mode, LaTeX-mode -> latex-mode.
I think these are corner cases and am not sure whether we should
keep compatibility.
b. Abbrev table
User abbrevs in, say, latex-mode-abbrev-table aren't inherited to
AUCTeX LaTeX mode.
c. desktop.el records the major mode name in the saved sessions. When
users have saved sessions with the name, say, latex-mode and
install this patch before the next session, desktop.el restores
them in wrong mode in the next session if `major-mode-remap-alist'
is available.
d. Directory local variables
d-1
Directory local variables prepared for, say, `latex-mode' aren't
picked up by AUCTeX LaTeX-mode when `major-mode-remap-alist' is
available.
The reason is that `hack-local-variables' doesn't understand
that `LaTeX-mode' is redirected from `latex-mode'.
d-2
Similar issue related to "superficial major modes" such as
japanese-LaTeX-mode still persists for directory local
variables[1] regardless whether `major-mode-remap-alist' is
available or not.
I'm still relying on ugly hack currently used for
japanese-{plain-tex,latex}-mode[2].
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61211
[2] The following code in tex-jp.el.
--
(when enable-local-variables
(setq major-mode 'japanese-LaTeX-mode)
(add-hook 'hack-local-variables-hook #'japanese-TeX-reset-mode-name
nil t
...
(defun japanese-TeX-reset-mode-name ()
(cond ((eq major-mode 'japanese-LaTeX-mode)
(setq major-mode 'LaTeX-mode))
((eq major-mode 'japanese-plain-TeX-mode)
(setq major-mode 'plain-TeX-mode)))
(remove-hook 'hack-local-variables-hook #'japanese-TeX-reset-mode-name t))
;; Hack for directory local variable entry of the form (LaTeX-mode (...)) .
(put 'japanese-LaTeX-mode 'derived-mode-parent 'LaT
Re: AUCTeX and "builtin latex mode" integration
>>> "IK" == Ikumi Keita writes: > Hi Uwe, >> Uwe Brauer writes: >>> AFAIK the only clean way is to actually change those bindings. >>> Yes, users will complain, and it may even break some 3rd party code, so >>> it'll be somewhat painful. >> Given that, and I am using for example cdlatex I must ask: >> is this drastic change really needed? > At least I don't want (and will not do myself) such heavy change in the > key binding. Good I am relived. I still have the feeling, there was a short peak in complains, but it is not that users are continuously complaining, besides who is still use the default LaTeX mode offered by Emacs? -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ smime.p7s Description: S/MIME cryptographic signature
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes: >>> OTOH you should be able to completely hide the "base" menus (by >>> overriding their bindings with something silly like the `ignore` >>> command). >> Do you mean menus provided by built-in tex mode by "base" menus? > Yes. I see. Then ability to hide the base menus isn't so important unless AUCTeX (or someone else) tries to activate it in AUCTeX mode. >> Or "File Edit Options Buffers..."? > No, not these. This said, those also can be hidden/replaced in the same > way (tho I doubt AUCTeX would want to do that). Of course not. (At least I think so.) Bye, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
Hi Uwe, > Uwe Brauer writes: >> AFAIK the only clean way is to actually change those bindings. >> Yes, users will complain, and it may even break some 3rd party code, so >> it'll be somewhat painful. > Given that, and I am using for example cdlatex I must ask: > is this drastic change really needed? At least I don't want (and will not do myself) such heavy change in the key binding. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
>> [ And in Emacs-30, you can use `major-mode-remap-alist` so that >> `mode: latex` will not call `latex-mode` but some other function, >> such as `LaTeX-mode`. ] > Yes, `major-mode-remap-alist` provides a clean way. However AUCTeX still > need to keep the current code for a certain period for Emacs<30 if we > take approach [B]. It would take at least several years until AUCTeX > raises the least supported version to emacs 30. I think all the possible solutions require such long term planning, yes :-( >>> - hard-coded mode names in their personal customized codes. >> I don't know what problem you're thinking of here. > > For example, users can have conditionals like > (if (eq major-mode 'latex-mode) ...) > in their personal customized codes assuming that `latex-mode' is > actually AUCTeX mode. Ah, right. Hopefully these are sufficiently uncommon and their users sufficiently savvy. >> OTOH you should be able to completely hide the "base" menus (by >> overriding their bindings with something silly like the `ignore` >> command). > Do you mean menus provided by built-in tex mode by "base" menus? Yes. > Or "File Edit Options Buffers..."? No, not these. This said, those also can be hidden/replaced in the same way (tho I doubt AUCTeX would want to do that). > [1] Currently, AUCTeX adds :around advice to `latex-mode' etc. Indeed, I think this will have to stay at least until Emacs-30 is old enough that we can rely on `major-mode-remap-alist` (unless we try to go the minor-mode route). Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan, > Stefan Monnier writes: >> 1. I first tried [A] because [B] wouldn't be easy to retain >> compatibility for users who have >> - a lot of files with "mode: latex" tag in the file local variables >> section. > The `mode:` specifies which function is called to enable the mode, > rather than which value of `major-mode` will be used in the resulting > buffer. > `mode: latex` means that we'll call `latex-mode` and that function can > activate AUCTeX's `LaTeX-mode` (which sets `major-mode` to > `LaTeX-mode`) without any trouble. With respect to "mode:" tag, what I want to express is that "[B] wouldn't lead to immediate removal of the trickery codes[1] in tex-site.el." (On the other hand, we can replace them with clearer codes if we can take approach [A].) > [ And in Emacs-30, you can use `major-mode-remap-alist` so that > `mode: latex` will not call `latex-mode` but some other function, > such as `LaTeX-mode`. ] Yes, `major-mode-remap-alist` provides a clean way. However AUCTeX still need to keep the current code for a certain period for emacs<30 if we take approach [B]. It would take at least several years until AUCTeX raises the least supported version to emacs 30. >> - hard-coded mode names in their personal customized codes. > I don't know what problem you're thinking of here. For example, users can have conditionals like (if (eq major-mode 'latex-mode) ...) in their personal customized codes assuming that `latex-mode' is actually AUCTeX mode. > AFAIK the only clean way is to actually change those bindings. > Yes, users will complain, and it may even break some 3rd party code, so > it'll be somewhat painful. Too bad. Then available appraoch is [B] only. > OTOH you should be able to completely hide the "base" menus (by > overriding their bindings with something silly like the `ignore` > command). Do you mean menus provided by built-in tex mode by "base" menus? Or "File Edit Options Buffers..."? >> Hence I'd like to request to modify the built-in tex-modes.el to delete >> those lines, or at least to do fboundp test like >> (unless (fboundp 'LaTeX-mode) >> (defalias 'LaTeX-mode #'latex-mode)) >> in, say, emacs-30. > Agreed. Could you open a bug report for that? > (with me in `X-Debbugs-Cc:`) I see. I'll do it later. > Hmm... this seems directly relevant to Emacs-30's new > `major-mode-remap-alist`. Can you open another bug report (with me in > `X-Debbugs-Cc:`) to discuss this. I'll do that, too. >> In addition, they don't need their own keymaps and syntax >> tables created by define-derived-mode. (Own hooks and abbrev tables may >> be useful, though.) > You can use `:keymap` and `:syntax-table` args to `define-derived-mode` > to avoid creating their own. Yes. It doesn't matter much anyway. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine [1] Currently, AUCTeX adds :around advice to `latex-mode' etc. -- (defconst TeX-mode-alist '((tex-mode . tex-mode) (plain-tex-mode . tex-mode) (texinfo-mode . texinfo) (latex-mode . tex-mode) (doctex-mode . tex-mode)) "Alist of built-in TeX modes and their load files.") [...] (add-hook 'tex-site-unload-hook (lambda () (TeX-modes-set 'TeX-modes nil) (setq load-path (delq TeX-lisp-directory load-path (defun TeX-modes-set (var value &optional _ignored) "Set VAR (which should be `TeX-modes') to VALUE. This places either the standard or the AUCTeX versions of functions into the respective function cell of the mode." (custom-set-default var value) (let ((list TeX-mode-alist) elt) (while list (setq elt (car (pop list))) (let ((dst (intern (concat "TeX-" (symbol-name elt) (if (memq elt value) (advice-add elt :override dst ;; COMPATIBILITY for Emacs 28.[12] ;; Give it higher precedence than the :around ;; advice given to `tex-mode' in tex-mode.el. ;; https://lists.gnu.org/r/auctex-devel/2022-09/msg00050.html> '((depth . -10))) (advice-remove elt dst)) (defcustom TeX-modes (mapcar #'car TeX-mode-alist) "List of modes provided by AUCTeX. This variable can't be set normally; use customize for that, or set it with `TeX-modes-set'." :type (cons 'set (mapcar (lambda(x) (list 'const (car x))) TeX-mode-alist)) :set #'TeX-modes-set :initialize #'custom-initialize-reset) --
Re: AUCTeX and "builtin latex mode" integration
>>> "SM" == Stefan Monnier writes: [Snip]... >> (define-key map "\C-c\C-i" #'tex-bibtex-file) >> (define-key map "\C-c\C-o" #'latex-insert-block) >> >> ;; Redundant keybindings, for consistency with SGML mode. >> (define-key map "\C-c\C-t" #'latex-insert-block) >> [...] >> (define-key map "\C-c/" #'latex-close-block) >> >> (define-key map "\C-c\C-e" #'latex-close-block) >> [...] >> (define-key map "\C-c\C-m" #'tex-feed-input) >> [...] >> (defvar latex-mode-map >> (let ((map (make-sparse-keymap))) >> [...] >> (define-key map "\C-c\C-s" #'latex-split-block) >> -- >> All these key sequences have different binding in AUCTeX (+RefTeX). >> Thus I don't see a clean way to meet the assumption "if we can arrange >> for latex-mode and auctex-mode not to collide in their keymaps". > [ Side note: RefTeX is also used with plan `latex-mode`. ] > AFAIK the only clean way is to actually change those bindings. > Yes, users will complain, and it may even break some 3rd party code, so > it'll be somewhat painful. Given that, and I am using for example cdlatex I must ask: is this drastic change really needed? I have not seen lately complains about having AucTeX and LaTeX-mode.[1] regards Uwe Brauer Footnotes: [1] frankly I can see much use of this old LaTeX-mode anyway, but that is a different topic smime.p7s Description: S/MIME cryptographic signature
Re: AUCTeX and "builtin latex mode" integration
> 1. I first tried [A] because [B] wouldn't be easy to retain
> compatibility for users who have
>- a lot of files with "mode: latex" tag in the file local variables
> section.
The `mode:` specifies which function is called to enable the mode,
rather than which value of `major-mode` will be used in the resulting buffer.
`mode: latex` means that we'll call `latex-mode` and that function can
activate AUCTeX's `LaTeX-mode` (which sets `major-mode` to `LaTeX-mode`)
without any trouble.
[ And in Emacs-30, you can use `major-mode-remap-alist` so that
`mode: latex` will not call `latex-mode` but some other function,
such as `LaTeX-mode`. ]
>- hard-coded mode names in their personal customized codes.
I don't know what problem you're thinking of here.
> The keymaps of AUCTeX LaTeX mode and built-in latex mode have a lot of
> overlaps.
And conflicts, yes :-(
> It seems difficult to me to separate all of them. In
> tex-mode.el, we see:
> --
> (defun tex-define-common-keys (keymap)
> "Define the keys that we want defined both in TeX mode and in the TeX
> shell."
> (define-key keymap "\C-c\C-k" #'tex-kill-job)
> (define-key keymap "\C-c\C-l" #'tex-recenter-output-buffer)
> (define-key keymap "\C-c\C-q" #'tex-show-print-queue)
> [...]
> (define-key keymap "\C-c\C-v" #'tex-view)
> [...]
> (defvar tex-mode-map
> (let ((map (make-sparse-keymap)))
> [...]
> (define-key map "\"" #'tex-insert-quote)
> (define-key map "\n" #'tex-handle-newline)
> (define-key map "\M-\r" #'latex-insert-item)
> [...]
> (define-key map "\C-c{" #'tex-insert-braces)
> [...]
> (define-key map "\C-c\C-c" #'tex-compile)
> (define-key map "\C-c\C-i" #'tex-bibtex-file)
> (define-key map "\C-c\C-o" #'latex-insert-block)
>
> ;; Redundant keybindings, for consistency with SGML mode.
> (define-key map "\C-c\C-t" #'latex-insert-block)
> [...]
> (define-key map "\C-c/" #'latex-close-block)
>
> (define-key map "\C-c\C-e" #'latex-close-block)
> [...]
> (define-key map "\C-c\C-m" #'tex-feed-input)
> [...]
> (defvar latex-mode-map
> (let ((map (make-sparse-keymap)))
> [...]
> (define-key map "\C-c\C-s" #'latex-split-block)
> --
> All these key sequences have different binding in AUCTeX (+RefTeX).
> Thus I don't see a clean way to meet the assumption "if we can arrange
> for latex-mode and auctex-mode not to collide in their keymaps".
[ Side note: RefTeX is also used with plan `latex-mode`. ]
AFAIK the only clean way is to actually change those bindings.
Yes, users will complain, and it may even break some 3rd party code, so
it'll be somewhat painful.
> In addition, I'm afraid that menus and tool bars are intermixed if we
> use `make-composed-keymap' for these two keymaps.
Indeed. OTOH you should be able to completely hide the "base" menus (by
overriding their bindings with something silly like the `ignore`
command).
> 2. Thus I tried [B] next, in the hope that we can circumvent the above
> mentioned difficulties by similar workarounds employed in the current
> startup codes and announcement to the users.
>
> If we are to take this approach, I think that the new mode name should
> be, e.g., "LaTeX-mode" because the user-exposed functions and variables
> have that prefix now.
Agreed.
> because tex-mode.el has these lines:
> --
> ;;;###autoload
> (defalias 'TeX-mode #'tex-mode)
> ;;;###autoload
> (defalias 'plain-TeX-mode #'plain-tex-mode)
> ;;;###autoload
> (defalias 'LaTeX-mode #'latex-mode)
> --
Yuck! These need to go!
> Hence I'd like to request to modify the built-in tex-modes.el to delete
> those lines, or at least to do fboundp test like
> (unless (fboundp 'LaTeX-mode)
> (defalias 'LaTeX-mode #'latex-mode))
> in, say, emacs-30.
Agreed. Could you open a bug report for that?
(with me in `X-Debbugs-Cc:`)
[ I wouldn't be surprised if there's a bit of reluctance to do that. ]
> I'd like to discuss dispatch functions context-**-mode and
> japanese-**-mode here. They only do language-specific set-ups and turn
> into context-mode, latex-mode and plain-tex-mode eventually. In some
> aspects, they are similar with guess functions `tex--guess-mode' and
> `TeX-tex-mode':
> - They can be specified as `mode' tag of file local variable and entry
> of `auto-mode-alist'.
> - They never hold their own `major-mode' value.
> - When called, they eventually turn into another proper major mode.
> Note that it isn't enough to do as
> (define-derived-mode japanese-latex-mode latex-mode "LaTeX"
> ...
> (setq major-mode 'latex-mode)
> ...)
> because it doesn't respond to directory local variable entry of the form
> ((japanese-latex-mode
> ...))
> in that case.
Hmm... this seems directly relevant to
Re: AUCTeX and "builtin latex mode" integration
Hi all, I at last began to work on this issue and would like to share
thoughts.
There are three topics 1.-3. below.
Two approaches were proposed before:
[A] Turn AUCTeX modes into minor mode.
[B] AUCTeX modes stay major modes but use `major-mode' values dictinct
from those of emacs built-in modes.
1. I first tried [A] because [B] wouldn't be easy to retain
compatibility for users who have
- a lot of files with "mode: latex" tag in the file local variables
section.
- hard-coded mode names in their personal customized codes.
However, I hit upon an obstacle explained below:
> Stefan Monnier writes:
>> Ikumi Keita writes:
>> Then the idea of turning AUCTeX into minor mode itself does not help.
> Not necessarily, but it could if we can arrange for latex-mode and
> auctex-mode not to collide in their keymaps (and syntax table, ...), so
> that entries added to `latex-mode-map` wouldn't be hidden by the
> auctex-mode-map (e.g. if that map was added with lower priority than
> latex-mode-map).
The keymaps of AUCTeX LaTeX mode and built-in latex mode have a lot of
overlaps. It seems difficult to me to separate all of them. In
tex-mode.el, we see:
--
(defun tex-define-common-keys (keymap)
"Define the keys that we want defined both in TeX mode and in the TeX shell."
(define-key keymap "\C-c\C-k" #'tex-kill-job)
(define-key keymap "\C-c\C-l" #'tex-recenter-output-buffer)
(define-key keymap "\C-c\C-q" #'tex-show-print-queue)
[...]
(define-key keymap "\C-c\C-v" #'tex-view)
[...]
(defvar tex-mode-map
(let ((map (make-sparse-keymap)))
[...]
(define-key map "\"" #'tex-insert-quote)
(define-key map "\n" #'tex-handle-newline)
(define-key map "\M-\r" #'latex-insert-item)
[...]
(define-key map "\C-c{" #'tex-insert-braces)
[...]
(define-key map "\C-c\C-c" #'tex-compile)
(define-key map "\C-c\C-i" #'tex-bibtex-file)
(define-key map "\C-c\C-o" #'latex-insert-block)
;; Redundant keybindings, for consistency with SGML mode.
(define-key map "\C-c\C-t" #'latex-insert-block)
[...]
(define-key map "\C-c/" #'latex-close-block)
(define-key map "\C-c\C-e" #'latex-close-block)
[...]
(define-key map "\C-c\C-m" #'tex-feed-input)
[...]
(defvar latex-mode-map
(let ((map (make-sparse-keymap)))
[...]
(define-key map "\C-c\C-s" #'latex-split-block)
--
All these key sequences have different binding in AUCTeX (+RefTeX).
Thus I don't see a clean way to meet the assumption "if we can arrange
for latex-mode and auctex-mode not to collide in their keymaps".
In addition, I'm afraid that menus and tool bars are intermixed if we
use `make-composed-keymap' for these two keymaps.
Of course it is still possible to proceed if AUCTeX mode uses
independent keymap such as LaTeX-mode-map, but it wouldn't help the case
that some AUCTeX user is tempted to customize latex-mode-map because of
the mode name being lower case `latex-mode'.
2. Thus I tried [B] next, in the hope that we can circumvent the above
mentioned difficulties by similar workarounds employed in the current
startup codes and announcement to the users.
If we are to take this approach, I think that the new mode name should
be, e.g., "LaTeX-mode" because the user-exposed functions and variables
have that prefix now. In my opinion, it doesn't make sense to choose
another name and rename all such occurences in AUCTeX source.
However, we can't do that in natural ways like
(define-derived-mode LaTeX-mode text-mode "LaTeX" ...
nor
(defun LaTeX-mode () ...)
because tex-mode.el has these lines:
--
;;;###autoload
(defalias 'TeX-mode #'tex-mode)
;;;###autoload
(defalias 'plain-TeX-mode #'plain-tex-mode)
;;;###autoload
(defalias 'LaTeX-mode #'latex-mode)
--
These defalias'es overwrite the AUCTeX definition unconditionally if
tex-mode.el are loaded after AUCTeX. So AUCTeX has to do workarounds
like
--
(define-derived-mode TeX-latex-mode text-mode "LaTeX"
...
(setq major-mode 'LaTeX-mode)
...)
(defalias 'LaTeX-mode #'TeX-latex-mode)
--
and advertise `LaTeX-mode' as its official name. (Additionally, we need
some gotchas so that directory local variable entry like
((LaTeX-mode
(...)))
should work.)
Hence I'd like to request to modify the built-in tex-modes.el to delete
those lines, or at least to do fboundp test like
(unless (fboundp 'LaTeX-mode)
(defalias 'LaTeX-mode #'latex-mode))
in, say, emacs-30.
If that is accepted, we can clean up the above workarounds in the
future, when the least supported emacsen becomes emacs 30.
3. This topic is independent of [A] and [B]. Here is a correspondence
table of major
Re: AUCTeX and "builtin latex mode" integration
Stefan Monnier writes:
> You may have seen an on-going discussion about the annoyance of the
> mixups between latex-mode and LaTeX-mode and such.
Yes, it was time for it again. Some time before that there was a
discussion on emacs-devel if AUCTeX should replace the stock tex/latex
mode :-)
> I do think it would be good to try and "integrate" the two modes, for
> some definition of "integrate". The question being indeed what
> "integration" is the best way forward.
I think if we want to touch this area, then we should go all the way and
find answer to these (and possibly other) questions:
1. Should we integrate AUCTeX into Emacs core?
It makes sense if we want to bring the modes more together. I really do
like what we have with ELPA, so I'd like to keep the ELPA releases (user
reports bug, someone hopefully fixes it fast, drop Tassilo a line, new
release, happy customer). So something like what Org is doing would be
nice for AUCTeX as well. And once we have it, we can drop the AUCTeX
tarball releases.
2. Should AUCTeX replace the stock tex/latex mode?
No, for technical/administrative/historical reasons.
3. Should we integrate the modes?
My suggestion is actually to decouple the modes totally. Behind the
scene, AUCTeX can load tex-mode.el, but this is then triggered by the
user through a to-be-defined function in the init-file or addition to
auto-mode-alist etc. The way AUCTeX currently takes over once installed
isn't optimal.
4. How do we advertise 2 modes?
I think we should describe the "product positioning" better for the
users. For example, we could say: If you plan to use standard LaTeX
classes and macros/environments, use LaTeX only for one or two projects,
don't want to configure a lot, then use the stock tex/latex mode. If
you plan to use external LaTeX packages and/or use personal packages,
plan to use LaTeX for a longer period and need more features like
key=val queries, want more IDE features, tighter integration to RefTeX,
then use AUCTeX.
This implies that tex-mode.el gets a manual and we agree on the "product
positioning" above.
5. Who is the team?
This question is related to point 1. If we put AUCTeX into core, then I
suggest that there is a TeX team tries to look after both modes, and the
way I see it, Stefan, you're the only major contributor the tex-mode.el.
Over time, we can then see how both modes can use a shared code base.
For example, tex-mode.el can use tex-ispell.el from AUCTeX. I'm also
thinking about features to come, like tree-sitter.
Just to make a start, here a suggestion for tex-mode.el:
--8<---cut here---start->8---
diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
index b43537265f..c46c32e03e 100644
--- a/lisp/textmodes/tex-mode.el
+++ b/lisp/textmodes/tex-mode.el
@@ -1560,7 +1560,7 @@ latex-block-body-alist
'(if (and (boundp 'reftex-mode) reftex-mode) (reftex-label "table"))
\n _)
("figure" nil > _ \n "\\caption{" > (skeleton-read "Caption: ") "}" > \n
- '(if (and (boundp 'reftex-mode) reftex-mode) (reftex-label "table"
+ '(if (and (boundp 'reftex-mode) reftex-mode) (reftex-label "figure"
"Skeleton element to use for the body of particular environments.
Every element of the list has the form (NAME . SKEL-ELEM) where NAME is
the name of the environment and SKEL-ELEM is an element to use in
--8<---cut here---end--->8---
Looking forward to your (and others) comments.
Best, Arash
Re: AUCTeX and "builtin latex mode" integration
> Stefan Monnier writes: >> Oh, I see where that happens (and why it doesn't happen if we redirect >> with `defalias`). Sorry, I was talking based on my memory when I hacked `japanese-latex-mode' in tex-jp.el to deal with double loading issue. I forgot that `hack-one-local-variable' uses `indirect-function'. Yes, it wouldn't happen when we use `defalias'. > Hmm... no I still can't reproduce it, even with something else than > a defalias. Hmm. The double loading caused by mismatch between `major-mode' and %%% mode: line did occur for `japanese-latex-mode' IIRC, but that might not apply for `LaTeX-mode' case by some reason I'm looking over. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> Oh, I see where that happens (and why it doesn't happen if we redirect > with `defalias`). Hmm... no I still can't reproduce it, even with something else than a defalias. Stefan
Re: AUCTeX and "builtin latex mode" integration
Stefan Monnier [2022-09-25 10:01:40] wrote: >> 1. Suppose that the file has %%% mode:latex as file variable. When emacs >> opens this file, it runs `latex-mode' accordingly, which in turn runs >> AUCTeX `LaTeX-mode' by redirectiton. Then it sets `major-mode' to >> `LaTeX-mode'. After that, `hack-local-variables' runs; it sees that >> `major mode' doesn't match the %%% mode:latex line and runs `latex-mode' >> again. > Why would `hack-local-variables` do that ? > AFAIK vanilla Emacs doesn't do such a thing (I just tried it in > Emacs-29 to confirm). Oh, I see where that happens (and why it doesn't happen if we redirect with `defalias`). Stefan
Re: AUCTeX and "builtin latex mode" integration
> be a derived mode of `latex-mode'. However, defining `LaTeX-mode' by > (define-derived-mode LaTeX-mode latex-mode ...) would cause infinite > loop when redirection is enabled. Yes, it's ugly. That's part of the reason for the weird way we define `tex-mode` in `tex-mode.el` (and that was preceded by other weird ways to do it). I have an idea for how we should solve this in general in Emacs, but in the mean time a hack like the (or delay-mode-hooks tex-mode--recursing) I used in `tex--redirect-to-submode` is about as good as I could make it :-( > I expect that we can circumvent the difficulty by putting > `derived-mode-parent' property on `LaTeX-mode', without > `define-derived-mode'. That's another option, indeed. Stefan
Re: AUCTeX and "builtin latex mode" integration
> 1. Suppose that the file has %%% mode:latex as file variable. When emacs > opens this file, it runs `latex-mode' accordingly, which in turn runs > AUCTeX `LaTeX-mode' by redirectiton. Then it sets `major-mode' to > `LaTeX-mode'. After that, `hack-local-variables' runs; it sees that > `major mode' doesn't match the %%% mode:latex line and runs `latex-mode' > again. Why would `hack-local-variables` do that ? AFAIK vanilla Emacs doesn't do such a thing (I just tried it in Emacs-29 to confirm). Stefan
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan and all, > Stefan Monnier writes: >> Then the idea of turning AUCTeX into minor mode itself does not help. > Not necessarily, but it could if we can arrange for latex-mode and > auctex-mode not to collide in their keymaps (and syntax table, ...), so > that entries added to `latex-mode-map` wouldn't be hidden by the > auctex-mode-map (e.g. if that map was added with lower priority than > latex-mode-map). Ah, indeed. It would be possible that `LaTeX-mode-map' has a parent keymap composed of both `latex-mode-map' and `TeX-mode-map'. Similar treatment would go for syntax table. >> (a) In addition to being minor mode, AUCTeX uses lower case >> `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table'. >> In this case, variable aliases `LaTeX-mode-hook' -> >> `latex-mode-hook' etc. would also be necessary for compatibility. > It could also just run `latex-mode-hook` in addition to what it already > runs, without setting up any alias between that and `LaTeX-mode-hook`. Indeed. >> (b) AUCTeX abandons the relationship between `LaTeX-mode' and >> `latex-mode'. I.e. `LaTeX-mode' no longer pretends to be >> `latex-mode'. > I think whether it pretends to be is a separate question from whether it > redirects `latex-mode` to its own implementation. > E.g. we could start by setting `major-mode` to `LaTeX-mode` rather than > `latex-mode`. Hmm, that approach didn't came to my mind. After reconsideration, it seems faily reasonable than I first saw it. Possible/potential caveats: 1. Suppose that the file has %%% mode:latex as file variable. When emacs opens this file, it runs `latex-mode' accordingly, which in turn runs AUCTeX `LaTeX-mode' by redirectiton. Then it sets `major-mode' to `LaTeX-mode'. After that, `hack-local-variables' runs; it sees that `major mode' doesn't match the %%% mode:latex line and runs `latex-mode' again. In this way, a file with %%% mode:latex or -*- latex -*- always runs `latex-mode' twice. I hope that we can find a way to avoid such overheads. 2. In order to keep backward compatibility of an entry of the form (latex (XXX . t) (YYY . 15) ...) in .dir-locals.el, `LaTeX-mode' should be a derived mode of `latex-mode'. However, defining `LaTeX-mode' by (define-derived-mode LaTeX-mode latex-mode ...) would cause infinite loop when redirection is enabled. I expect that we can circumvent the difficulty by putting `derived-mode-parent' property on `LaTeX-mode', without `define-derived-mode'. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> Indeed. I learned people are often tempted to use `latex-' prefix to > customize the behavior of AUCTeX. It means that, in addition to > `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table' (and > their counterparts of plain-tex-mode, texinfo-mode and doctex-mode) are > potential sources of similar confusion. :-( > > Then the idea of turning AUCTeX into minor mode itself does not help. Not necessarily, but it could if we can arrange for latex-mode and auctex-mode not to collide in their keymaps (and syntax table, ...), so that entries added to `latex-mode-map` wouldn't be hidden by the auctex-mode-map (e.g. if that map was added with lower priority than latex-mode-map). > (a) In addition to being minor mode, AUCTeX uses lower case > `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table'. > In this case, variable aliases `LaTeX-mode-hook' -> > `latex-mode-hook' etc. would also be necessary for compatibility. It could also just run `latex-mode-hook` in addition to what it already runs, without setting up any alias between that and `LaTeX-mode-hook`. > (b) AUCTeX abandons the relationship between `LaTeX-mode' and > `latex-mode'. I.e. `LaTeX-mode' no longer pretends to be > `latex-mode'. I think whether it pretends to be is a separate question from whether it redirects `latex-mode` to its own implementation. E.g. we could start by setting `major-mode` to `LaTeX-mode` rather than `latex-mode`. Stefan
Re: AUCTeX and "builtin latex mode" integration
> Ikumi Keita writes: > (b) AUCTeX abandons the relationship between `LaTeX-mode' and > `latex-mode'. I.e. `LaTeX-mode' no longer pretends to be > `latex-mode'. > In this case, > 1. Users who have files with -*- latex -*- or > %%% mode: latex > should explicitly add (defalias 'latex-mode 'LaTeX-mode) in > their init files. Following up myself, this is fragile because when tex-mode.el is loaded afterward, `latex-mode' is overwritten by `defun'. We need something robust if we take approach (b). Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> Sent: Thursday, September 22, 2022 at 9:33 PM > From: "Ikumi Keita" > To: "Stefan Monnier" > Cc: "Tassilo Horn" , "David Kastrup" , > auctex-devel@gnu.org > Subject: Re: AUCTeX and "builtin latex mode" integration > > Hi Stefan and all, > > > I think it's on gnu.emacs.help, aka help-gnu-emacs. > > I read the thread. > > > It started with someone complaining that rainbow-delimiters doesn't work > > with LaTeX's braces, derived into AUCTeX-vs-plain because IIUC the > > problem was that they enabled the mode via `latex-mode-hook` which their > > AUCTeX doesn't run even though the mode describes itself as `latex-mode`. > > Indeed. I learned people are often tempted to use `latex-' prefix to > customize the behavior of AUCTeX. It means that, in addition to > `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table' (and > their counterparts of plain-tex-mode, texinfo-mode and doctex-mode) are > potential sources of similar confusion. :-( > > Then the idea of turning AUCTeX into minor mode itself does not help. > Taking into account the discussion between Stefan and Tassilo, possible > candidates are either: > (a) In addition to being minor mode, AUCTeX uses lower case > `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table'. > In this case, variable aliases `LaTeX-mode-hook' -> > `latex-mode-hook' etc. would also be necessary for compatibility. The subsequent debate was that Auctex should start using the package name "auctex-" as a mode prefix as is today supposed to be done. > (b) AUCTeX abandons the relationship between `LaTeX-mode' and > `latex-mode'. I.e. `LaTeX-mode' no longer pretends to be > `latex-mode'. And that indeed, AUCTeX should abandon the use of the original built-in names for what it is trying to do. So auctex should be in the names so everyone can follow the design as is necessary for comprehension, interpretation, and execution. Done clearly, rather than continuing with the current almost impossible way to understand Auctex functionality rapidly by the average user and developer. At least the long term plan should be as described and made to happen. > In this case, > 1. Users who have files with -*- latex -*- or > %%% mode: latex > should explicitly add (defalias 'latex-mode 'LaTeX-mode) in > their init files. > 2. AUCTeX installation process should create tex-site.el which > modifies `auto-mode-alist' to associate ".tex" to > `TeX-tex-mode'. > 3. If the site admin sets up site-start.el to load tex-site.el and > an individual user of that site wants emacs built-in modes, > that user should undo the modification to `auto-mode-alist' by > the personal init file. > > Regards, > Ikumi Keita > #StandWithUkraine #StopWarInUkraine > >
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan and all, > I think it's on gnu.emacs.help, aka help-gnu-emacs. I read the thread. > It started with someone complaining that rainbow-delimiters doesn't work > with LaTeX's braces, derived into AUCTeX-vs-plain because IIUC the > problem was that they enabled the mode via `latex-mode-hook` which their > AUCTeX doesn't run even though the mode describes itself as `latex-mode`. Indeed. I learned people are often tempted to use `latex-' prefix to customize the behavior of AUCTeX. It means that, in addition to `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table' (and their counterparts of plain-tex-mode, texinfo-mode and doctex-mode) are potential sources of similar confusion. :-( Then the idea of turning AUCTeX into minor mode itself does not help. Taking into account the discussion between Stefan and Tassilo, possible candidates are either: (a) In addition to being minor mode, AUCTeX uses lower case `latex-mode-hook', `latex-mode-map' and `latex-mode-syntax-table'. In this case, variable aliases `LaTeX-mode-hook' -> `latex-mode-hook' etc. would also be necessary for compatibility. (b) AUCTeX abandons the relationship between `LaTeX-mode' and `latex-mode'. I.e. `LaTeX-mode' no longer pretends to be `latex-mode'. In this case, 1. Users who have files with -*- latex -*- or %%% mode: latex should explicitly add (defalias 'latex-mode 'LaTeX-mode) in their init files. 2. AUCTeX installation process should create tex-site.el which modifies `auto-mode-alist' to associate ".tex" to `TeX-tex-mode'. 3. If the site admin sets up site-start.el to load tex-site.el and an individual user of that site wants emacs built-in modes, that user should undo the modification to `auto-mode-alist' by the personal init file. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
> Sent: Wednesday, September 21, 2022 at 1:43 AM > From: "Stefan Monnier" > To: "Tassilo Horn" > Cc: "David Kastrup" , auctex-devel@gnu.org > Subject: Re: AUCTeX and "builtin latex mode" integration > > Tassilo Horn [2022-09-20 08:38:27] wrote: > > Stefan Monnier writes: > >> What I'm really asking here is if there's a willingness to introduce > >> the inevitable bit of breakage in exchange for a supposed longer term > >> benefit, and/or if someone can think of a better way to move towards a > >> better long-term arrangement than the status quo. > > I wonder why/if it's important that the AUCTeX modes identify as the > > builtin modes, i.e., what would be the issue with having (La)TeX-mode > > major-modes which have no relationship to (la)tex-mode at all plus a > > setup command users would call in their init file in order to modify > > `auto-mode-alist' so that the AUCTeX modes are added? > > It might cause problems for people with `-*- latex -*-` in their files. > But other than that, it's also an option, indeed. > > Personally, I like the idea that `auto-mode-alist` (and mode cookies) > should describe the type of a file, rather than the specific mode to use > for it, but that's just me (and Emacs doesn't make that convenient > since it doesn't offer the needed indirection). I am inclined to the idea, with a simpler mechanism to impose specific modes if one wants to go beyond the built-in one.
Re: AUCTeX and "builtin latex mode" integration
> Sent: Wednesday, September 21, 2022 at 3:58 AM > From: "Stefan Monnier" > To: "Tassilo Horn" > Cc: "David Kastrup" , auctex-devel@gnu.org > Subject: Re: AUCTeX and "builtin latex mode" integration > > >>> I wonder why/if it's important that the AUCTeX modes identify as the > >>> builtin modes, i.e., what would be the issue with having (La)TeX-mode > >>> major-modes which have no relationship to (la)tex-mode at all plus a > >>> setup command users would call in their init file in order to modify > >>> `auto-mode-alist' so that the AUCTeX modes are added? > >> > >> It might cause problems for people with `-*- latex -*-` in their > >> files. But other than that, it's also an option, indeed. > >> > >> Personally, I like the idea that `auto-mode-alist` (and mode cookies) > >> should describe the type of a file, rather than the specific mode to > >> use for it, but that's just me > > > > Could you elaborate a bit here? I can't quite follow. > > What I mean is that the entries in mode cookies and auto-mode-alist > (and magic-mode-alist, ...) should not say "use this specific mode" but > "use the mode which the user chose for files of this specific type". > > Emacs doesn't have the corresponding concept, so instead we use > `latex-mode` resp. `perl-mode` as "the name of the mode to use for LaTeX > resp. Perl files" and then we rely on hacks based on `defalias` or > `advice-add` to make that symbol point to the user's favorite mode for > that file type. > > > Anyway: where the actual complaints not more or less like "I want to > > use the stock tex/latex modes but also with cdlatex which requires the > > auctex package which then hijacks my editing"? > > No (BTW, `cdlatex` doesn't require AUCTeX any more). There was discussion with Carsten of incorporating the cdlatex functianality into both built-in tex-mode & latex-mode; and Auctex. Could this be made to happen since we're at it. > > I think that wouldn't be a bad idea anyway (except for compatibility > > reasons) because nowadays we all agree that merely installing and > > loading a package should not have side-effects. > > Agreed. Maybe `AUCTeX-mode` should be a global minor mode which causes > `AUCTeX-minor-mode` to be enabled in the appropriate major modes.
Re: AUCTeX and "builtin latex mode" integration
> Sent: Wednesday, September 21, 2022 at 6:53 PM > From: "Tassilo Horn" > To: "Christopher Dimech" > Cc: "Stefan Monnier" , "David Kastrup" > , auctex-devel@gnu.org > Subject: Re: AUCTeX and "builtin latex mode" integration > > Christopher Dimech writes: > > > Have seen that the built-in tex-mode and latex-mode have two powerful > > features: 1) the prettify-symbols-mode where things such as \alpha are > > displayed with the corresponding greek glyph symbol; and 2) the > > ability to reposition the height of superscripts and subscripts. > > > > For the two features, I seem to remember than the rendering proves to > > be superior in Auctex. > > AUCTeX basically uses the prettify-symbols setup from the builtin latex > mode. I don't know what you mean with repositioning the height of > sub/superscripts. AUCTeX (font-latex.el) allows to fontify them as such > even on multiple levels, e.g., x^y^z. Superscipted entries are positioned at a higher height level and the font size is decreased. Correspondingly, subscripted entries are positioned at a lower height with font size decreased. But the Superscipted "^" and Subscripted "_" signs remain showing in the text Thus "x^a" and "y_b", will show "a" positioned higher relative to "x", whilst "b" is positioned lower relative to "y". But the "^" and "_" will still show up. > > Could you see whether using the functionality from the Auctex > > implementation be used. > > AUCTeX font-lock implementation heavily relies on the information > gathered by AUCTeX's parsing abilities and its style files, so I guess, > no. If so, it would be pleasant to have the functionalities in tex-mode and-latex built-in that are similar to Auctex in a separate file. That would include tex--prettify-symbols-alist and the tex-suscript part. And let the user decide what features to activate - whether the basic prettify engine or the Auctex one.
Re: AUCTeX and "builtin latex mode" integration
Christopher Dimech writes: > Have seen that the built-in tex-mode and latex-mode have two powerful > features: 1) the prettify-symbols-mode where things such as \alpha are > displayed with the corresponding greek glyph symbol; and 2) the > ability to reposition the height of superscripts and subscripts. > > For the two features, I seem to remember than the rendering proves to > be superior in Auctex. AUCTeX basically uses the prettify-symbols setup from the builtin latex mode. I don't know what you mean with repositioning the height of sub/superscripts. AUCTeX (font-latex.el) allows to fontify them as such even on multiple levels, e.g., x^y^z. > Could you see whether using the functionality from the Auctex > implementation be used. AUCTeX font-lock implementation heavily relies on the information gathered by AUCTeX's parsing abilities and its style files, so I guess, no. Bye, Tassilo
Re: AUCTeX and "builtin latex mode" integration
> Sent: Wednesday, September 21, 2022 at 10:10 AM > From: "Stefan Monnier" > To: "Tassilo Horn" > Cc: "David Kastrup" , auctex-devel@gnu.org > Subject: Re: AUCTeX and "builtin latex mode" integration > > > Maybe we could start by stating some goals: > > > > - AUCTeX should not set the `major-mode` to point to > > non-AUCTeX functions (even if/when it overrides those functions). > > > > - Cleanup the mode function names. Currently, AUCTeX's LaTeX mode is > > variously called: > > > > latex-mode > > TeX-latex-mode > > LaTeX-mode > > > > AUCTeX should pick one and stick to it as much as possible (e.g. fix > > all the docs and have the auxiliary user-exposed variables be named > > accordingly to the base major mode name). > > Maybe other goals could be to reduce user-confusion by having only "one" > mode, tho it's not clear what that would mean. But I think we should > come up with a long-term plan (which can include changes in Emacs's > built-in `tex-mode.el`: co-evolution is more difficult, but if we can > agree on a long term plan, we can then figure out how to get there > incrementally). I like the incremental long term plan on a topic that was initially thought too convoluted to change. Have seen that the built-in tex-mode and latex-mode have two powerful features: 1) the prettify-symbols-mode where things such as \alpha are displayed with the corresponding greek glyph symbol; and 2) the ability to reposition the height of superscripts and subscripts. For the two features, I seem to remember than the rendering proves to be superior in Auctex. Could you see whether using the functionality from the Auctex implementation be used. This might then simplify things somehow, in that Auctex could then focus on the other aspects not present in the built-in tex-mode and latex-mode. > PS: For the record, I'm one of the those Emacs users who doesn't use > AUCTeX: I stopped using AUCTeX many years ago when I decided > that since AUCTeX couldn't be part of Emacs, I should "dogfeed". > Now that it's in GNU ELPA that reason doesn't really apply any more, > but I keep using that mode out of habit. I'd be just as happy with AUCTeX > which I was using quite happily before.
Re: AUCTeX and "builtin latex mode" integration
> Maybe we could start by stating some goals: > > - AUCTeX should not set the `major-mode` to point to > non-AUCTeX functions (even if/when it overrides those functions). > > - Cleanup the mode function names. Currently, AUCTeX's LaTeX mode is > variously called: > > latex-mode > TeX-latex-mode > LaTeX-mode > > AUCTeX should pick one and stick to it as much as possible (e.g. fix > all the docs and have the auxiliary user-exposed variables be named > accordingly to the base major mode name). Maybe other goals could be to reduce user-confusion by having only "one" mode, tho it's not clear what that would mean. But I think we should come up with a long-term plan (which can include changes in Emacs's built-in `tex-mode.el`: co-evolution is more difficult, but if we can agree on a long term plan, we can then figure out how to get there incrementally). Stefan PS: For the record, I'm one of the those Emacs users who doesn't use AUCTeX: I stopped using AUCTeX many years ago when I decided that since AUCTeX couldn't be part of Emacs, I should "dogfeed". Now that it's in GNU ELPA that reason doesn't really apply any more, but I keep using that mode out of habit. I'd be just as happy with AUCTeX which I was using quite happily before.
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan, > Stefan Monnier writes: >>> You may have seen an on-going discussion about the annoyance of the >>> mixups between latex-mode and LaTeX-mode and such. >> Could you tell us where that discussion takes place? > I think it's on gnu.emacs.help, aka help-gnu-emacs. Thank you, I'll take a look. > Oh, I wasn't aware of regression. We can workaround the problem > using the `depth` property on `advice-add`, to make sure AUCTeX's advice > takes precedence over that of `tex-mode.el` even if it's > installed before. > E.g. if you add the patch below to Emacs, can you confirm that it fixes > the problem on your end? Confirmed, it works as expected. > diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el > index f624b604aac..77c0d234206 100644 > --- a/lisp/textmodes/tex-mode.el > +++ b/lisp/textmodes/tex-mode.el > @@ -1014,7 +1014,10 @@ tex-mode > says which mode to use." >(tex-common-initialization)) > -(advice-add 'tex-mode :around #'tex--redirect-to-submode) > +(advice-add 'tex-mode :around #'tex--redirect-to-submode > +;; Give it lower precedence than normal advice, so > +;; AUCTeX's advice takes precedence over it. > +'((depth . 50))) > (defvar tex-mode--recursing nil) > (defun tex--redirect-to-submode (orig-fun) >"Redirect to one of the submodes when called directly." > I pushed this to `emacs-28` so it will be fixed in the next Emacs > release (but that may be Emacs-29.1). In the mean time, you can use > a `((depth . -10))` in AUCTeX to make it work with Emacs-28.1. I'll do. >> 3. Currently, there is defect in handling doc strings of AUCTeX LaTeX >> mode, plain TeX mode and docTeX mode; C-h m and C-h f show doc string >> of built-in modes, not AUCTeX modes. > Maybe the help facility should be more careful in how it builds the > docstring when a function has an `:override` advice, indeed. > Could you `M-x report-emacs-bug` for that? I'll do this, too, probably. >> `AUCTeX-mode' should put suitable `function-documentation' property >> for the respective major mode symbol. > I think that would be exactly the kind of messing around I'd like to > move away from. Hmm. Then C-h m and C-h f will continue to show the doc string of the built-in modes if `AUCTeX-mode' minor mode is implemented in the suggested manner, even if the help facility is modified to take care of :override advice. Is there any good alternative approach to display doc strings of AUCTeX? (But it may be too early to discuss the implementation detail of this level.) >> From the users' point of view, I don't think it matters much. They just >> specify >> %%% mode: latex >> as the file local variable and think that they are using `latex-mode'. >> I think that it would be only Elisp programmers that care about the >> "lies". > There's regularly discussion (among (AUC)TeX Emacs users) about which > major mode runs which hook. I think it's an important issue not just > for ELisp programmers. I see. The hook name inconsistency must be indeed cause of trouble for emacs users new to AUCTeX. Regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
Maybe we could start by stating some goals:
- AUCTeX should not set the `major-mode` to point to
non-AUCTeX functions (even if/when it overrides those functions).
- Cleanup the mode function names. Currently, AUCTeX's LaTeX mode is
variously called:
latex-mode
TeX-latex-mode
LaTeX-mode
AUCTeX should pick one and stick to it as much as possible (e.g. fix
all the docs and have the auxiliary user-exposed variables be named
accordingly to the base major mode name).
WIP patch below.
Stefan
diff --git a/font-latex.el b/font-latex.el
index 4406dea610..577a9834a0 100644
--- a/font-latex.el
+++ b/font-latex.el
@@ -36,6 +36,7 @@
(require 'font-lock)
(require 'tex)
+(require 'latex)
(eval-when-compile
(require 'cl-lib))
@@ -1285,7 +1286,7 @@ triggers Font Lock to recognize the change."
(defun font-latex--make-syntax-propertize-function ()
"Return a `syntax-propertize-function' for (La|Doc)TeX documents."
- (let ((kws ;; (if (derived-mode-p 'doctex-mode)
+ (let ((kws ;; (if (LaTeX--doctex-p)
;; font-latex-doctex-syntactic-keywords
font-latex-syntactic-keywords)) ;; )
(syntax-propertize-via-font-lock kws)))
@@ -1324,7 +1325,7 @@ triggers Font Lock to recognize the change."
syntax-propertize-wholelines
font-latex-sp-extend-region-backwards-verb-env
;; Add the mode-dependent stuff to the basic variables defined above.
-(if (eq major-mode 'doctex-mode)
+(if (LaTeX--doctex-p)
(progn
(setcar defaults (append (car defaults)
'(font-latex-doctex-keywords)))
@@ -1429,7 +1430,8 @@ OPENCHAR is the opening character and CLOSECHAR is the
closing
character. Character pairs are usually { } or [ ]. Comments are
ignored during the search."
(let ((parse-sexp-ignore-comments
- (not (eq major-mode 'doctex-mode))) ; scan-sexps ignores comments
+ ;; `scan-sexps' ignores comments.
+ (not (LaTeX--doctex-p)))
(init-point (point))
(mycount 1)
(esc-char (or (and (boundp 'TeX-esc) TeX-esc) "\\"))
@@ -1482,13 +1484,14 @@ ignored during the search."
(forward-line 0)
(if (and (eq (char-after) ?\%)
(not (font-latex-faces-present-p 'font-latex-verbatim-face)))
- (not (eq major-mode 'doctex-mode))
+ (not (LaTeX--doctex-p))
(catch 'found
(while (progn (skip-chars-forward "^%" limit)
(< (point) limit))
(when (and (save-excursion
(zerop (mod (skip-chars-backward
- (regexp-quote esc-char)) 2)))
+ (regexp-quote esc-char))
+ 2)))
(not (font-latex-faces-present-p
'font-latex-verbatim-face)))
(throw 'found t))
@@ -1510,7 +1513,7 @@ If POS is omitted, the current position of point is used."
(defun font-latex-forward-comment ()
"Like `forward-comment' but with special provisions for docTeX mode.
In docTeX mode \"%\" at the start of a line will be treated as whitespace."
- (if (eq major-mode 'doctex-mode)
+ (if (LaTeX--doctex-p)
;; XXX: We should probably cater for ^^A as well.
(progn
(while (progn (if (bolp) (skip-chars-forward "%"))
@@ -1767,7 +1770,7 @@ cases.")
(pos (funcall search)))
(while (and pos
(member (match-string 1)
-(if (eq major-mode 'doctex-mode)
+(if (LaTeX--doctex-p)
(remove "_" font-latex-match-simple-exclude-list)
font-latex-match-simple-exclude-list)))
(setq pos (funcall search)))
diff --git a/latex.el b/latex.el
index 59ba9cbfc6..02d23803ca 100644
--- a/latex.el
+++ b/latex.el
@@ -894,6 +894,11 @@ position just before \\begin and the position just before
(defvar LaTeX-syntactic-comments) ;; Defined further below.
+(defsubst LaTeX--doctex-p ()
+ ;; FIXME: What's the difference between this test and testing
+ ;; `LaTeX-syntactic-comments'?
+ (derived-mode-p 'docTeX-mode))
+
(defun LaTeX-current-environment (&optional arg)
"Return the name (a string) of the enclosing LaTeX environment.
With optional ARG>=1, find that outer level.
@@ -925,7 +930,7 @@ work analogously."
;; comment-prefix. Hence, the next check just looks
;; if we're inside such a group and returns t to
;; recognize such a situation.
- (and (eq major-mode 'doctex-mode)
+ (and (LaTeX--doctex-p)
(member (match-string-no-properties 2)
'("macrocode" "macrocode*"
(setq arg (if (string= (match-string 1) "end") (1+ arg) (1- arg)
@@ -939,7 +944,8 @@ work analogously."
(save-excursio
Re: AUCTeX and "builtin latex mode" integration
>>> I wonder why/if it's important that the AUCTeX modes identify as the >>> builtin modes, i.e., what would be the issue with having (La)TeX-mode >>> major-modes which have no relationship to (la)tex-mode at all plus a >>> setup command users would call in their init file in order to modify >>> `auto-mode-alist' so that the AUCTeX modes are added? >> >> It might cause problems for people with `-*- latex -*-` in their >> files. But other than that, it's also an option, indeed. >> >> Personally, I like the idea that `auto-mode-alist` (and mode cookies) >> should describe the type of a file, rather than the specific mode to >> use for it, but that's just me > > Could you elaborate a bit here? I can't quite follow. What I mean is that the entries in mode cookies and auto-mode-alist (and magic-mode-alist, ...) should not say "use this specific mode" but "use the mode which the user chose for files of this specific type". Emacs doesn't have the corresponding concept, so instead we use `latex-mode` resp. `perl-mode` as "the name of the mode to use for LaTeX resp. Perl files" and then we rely on hacks based on `defalias` or `advice-add` to make that symbol point to the user's favorite mode for that file type. > Anyway: where the actual complaints not more or less like "I want to > use the stock tex/latex modes but also with cdlatex which requires the > auctex package which then hijacks my editing"? No (BTW, `cdlatex` doesn't require AUCTeX any more). > I think that wouldn't be a bad idea anyway (except for compatibility > reasons) because nowadays we all agree that merely installing and > loading a package should not have side-effects. Agreed. Maybe `AUCTeX-mode` should be a global minor mode which causes `AUCTeX-minor-mode` to be enabled in the appropriate major modes. Stefan
Re: AUCTeX and "builtin latex mode" integration
Stefan Monnier writes: >> I wonder why/if it's important that the AUCTeX modes identify as the >> builtin modes, i.e., what would be the issue with having (La)TeX-mode >> major-modes which have no relationship to (la)tex-mode at all plus a >> setup command users would call in their init file in order to modify >> `auto-mode-alist' so that the AUCTeX modes are added? > > It might cause problems for people with `-*- latex -*-` in their > files. But other than that, it's also an option, indeed. > > Personally, I like the idea that `auto-mode-alist` (and mode cookies) > should describe the type of a file, rather than the specific mode to > use for it, but that's just me Could you elaborate a bit here? I can't quite follow. Anyway: where the actual complaints not more or less like "I want to use the stock tex/latex modes but also with cdlatex which requires the auctex package which then hijacks my editing"? If that was the case, then maybe the only thing to be done was to make the "hijacking" explicit. I think that wouldn't be a bad idea anyway (except for compatibility reasons) because nowadays we all agree that merely installing and loading a package should not have side-effects. Bye, Tassilo
Re: AUCTeX and "builtin latex mode" integration
>>> "SM" == Stefan Monnier writes: >> 1. Why can't latex-mode not be removed/substituted by auctex? > For technical/administrative/historical reasons. >> 2. What's about reftex? Right now, since auctex provides a mayor >> mode, you can put it in a hook to startup reftex when you open a >> latex file with auctex installed. Would that be a problem, if >> auctex is no longer a «real» mayor mode? > The change would/will introduce breakage. The intention is to minimize > (and fix) as much of it as possible. I suspect that if you provide > a test for AUCTeX's test suite verifying this behavior, then we'll make > sure it keeps working :-) I see, I don't have much of a say here, I don't have write access to the repository, I just test and occasionally send some patches. However I have been using AucTeX at least since 1992 maybe longer, knowing it as a very useful and stable platform and always as a mayor mode. I have seen these discussion (there were another one about cdlatex by the same author) by someone who in my opinion did not really bother much to read the documentation or search the internet (googling)[1] but I feel that the change you propose it is a bit too much! It might causes problems, headaches etc and to shake a program that is so stable [2], just because of this discussion, well... So I would recommend not to try to please that specific complain and to leave things as they are. Regards Uwe Brauer Footnotes: [1] not that I have done sometimes a bit the same...😇 [2] and is so essential for my everyday work smime.p7s Description: S/MIME cryptographic signature
Re: AUCTeX and "builtin latex mode" integration
> 1. Why can't latex-mode not be removed/substituted by auctex? For technical/administrative/historical reasons. > 2. What's about reftex? Right now, since auctex provides a mayor >mode, you can put it in a hook to startup reftex when you open a >latex file with auctex installed. Would that be a problem, if >auctex is no longer a «real» mayor mode? The change would/will introduce breakage. The intention is to minimize (and fix) as much of it as possible. I suspect that if you provide a test for AUCTeX's test suite verifying this behavior, then we'll make sure it keeps working :-) Stefan
Re: AUCTeX and "builtin latex mode" integration
>> You may have seen an on-going discussion about the annoyance of the >> mixups between latex-mode and LaTeX-mode and such. > Could you tell us where that discussion takes place? I think it's on gnu.emacs.help, aka help-gnu-emacs. It started with someone complaining that rainbow-delimiters doesn't work with LaTeX's braces, derived into AUCTeX-vs-plain because IIUC the problem was that they enabled the mode via `latex-mode-hook` which their AUCTeX doesn't run even though the mode describes itself as `latex-mode`. >> I do think it would be good to try and "integrate" the two modes, for >> some definition of "integrate". The question being indeed what >> "integration" is the best way forward. > > I also want some improvements with regard to the "integration" because I > recently realized that emacs built-in `tex-mode' (accidentally?) shadows > AUCTeX `TeX-tex-mode' since emacs 28.1, to fail to enter LaTeX mode for > some cases[1][2]. (I'm not sure that the above discussion involves this > issue.) > > [1] thread beginning with > https://lists.gnu.org/r/auctex/2022-08/msg1.html Oh, I wasn't aware of regression. We can workaround the problem using the `depth` property on `advice-add`, to make sure AUCTeX's advice takes precedence over that of `tex-mode.el` even if it's installed before. E.g. if you add the patch below to Emacs, can you confirm that it fixes the problem on your end? diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el index f624b604aac..77c0d234206 100644 --- a/lisp/textmodes/tex-mode.el +++ b/lisp/textmodes/tex-mode.el @@ -1014,7 +1014,10 @@ tex-mode says which mode to use." (tex-common-initialization)) -(advice-add 'tex-mode :around #'tex--redirect-to-submode) +(advice-add 'tex-mode :around #'tex--redirect-to-submode +;; Give it lower precedence than normal advice, so +;; AUCTeX's advice takes precedence over it. +'((depth . 50))) (defvar tex-mode--recursing nil) (defun tex--redirect-to-submode (orig-fun) "Redirect to one of the submodes when called directly." I pushed this to `emacs-28` so it will be fixed in the next Emacs release (but that may be Emacs-29.1). In the mean time, you can use a `((depth . -10))` in AUCTeX to make it work with Emacs-28.1. The dual use of `tex-mode` (as both a major mode and a dispatch function) is very messy :-( >> I'm wondering if it would be possible to turn AUCTeX into a minor mode. >> E.g. `LaTeX-mode` would then be redefined as > >> (define-derived-mode TeX-latex-mode latex-mode ... >> (AUCTeX-mode 1)) > >> and `TeX-modes-set` would add/remove `AUCTeX-mode` from the hooks like >> `latex-mode-hook`. > > It basically looks reasonable. I assume that you are thinking that > `AUCTeX-mode' actually chooses suitable behavior according to the value > of `major-mode' between `latex-mode', `plain-tex-mode', `doctex-mode' > and `texinfo-mode'. That'd be the idea, yes. > 1. There will be some overheads because it first runs initialization > codes of emacs built-in mode and then runs AUCTeX minor mode; I expect > that the associated cost is cheap enough. I'm assuming it would be cheap, yes. > 2. AUCTeX still must retain some major modes, i.e., ConTeXt mode, > AmS-TeX mode, Japanese LaTeX mode and Japanese plain TeX mode because > there are no counterparts in emacs built-in modes. In the short term at least it will also keep `(TeX-)LaTeX-mode` and friends, I think. And maybe even in the long term. > 3. Currently, there is defect in handling doc strings of AUCTeX LaTeX > mode, plain TeX mode and docTeX mode; C-h m and C-h f show doc string > of built-in modes, not AUCTeX modes. Maybe the help facility should be more careful in how it builds the docstring when a function has an `:override` advice, indeed. Could you `M-x report-emacs-bug` for that? Maybe the `latex-mode` docstring would need some tweaking, but `C-h m` would show the docstring of `AUCTeX-mode` as well. > `AUCTeX-mode' should put suitable `function-documentation' property > for the respective major mode symbol. I think that would be exactly the kind of messing around I'd like to move away from. > 4. `TeX-tex-mode' and `tex-mode' would need some special treatment. Special care, that's for sure, yes. >> To be honest, I haven't looked very much at the code to see how >> realistic this is, but I think this could help clarify the situation >> for users. E.g. it would eliminate "lies" such as (setq major-mode >> 'latex-mode) in `latex.el`. > > From the users' point of view, I don't think it matters much. They just > specify > %%% mode: latex > as the file local variable and think that they are using `latex-mode'. > I think that it would be only Elisp programmers that care about the > "lies". There's regularly discussion (among (AUC)TeX Emacs users) about which major mode runs which hook. I think it's an important issue not just for ELisp programmers
Re: AUCTeX and "builtin latex mode" integration
Tassilo Horn [2022-09-20 08:38:27] wrote: > Stefan Monnier writes: >> What I'm really asking here is if there's a willingness to introduce >> the inevitable bit of breakage in exchange for a supposed longer term >> benefit, and/or if someone can think of a better way to move towards a >> better long-term arrangement than the status quo. > I wonder why/if it's important that the AUCTeX modes identify as the > builtin modes, i.e., what would be the issue with having (La)TeX-mode > major-modes which have no relationship to (la)tex-mode at all plus a > setup command users would call in their init file in order to modify > `auto-mode-alist' so that the AUCTeX modes are added? It might cause problems for people with `-*- latex -*-` in their files. But other than that, it's also an option, indeed. Personally, I like the idea that `auto-mode-alist` (and mode cookies) should describe the type of a file, rather than the specific mode to use for it, but that's just me (and Emacs doesn't make that convenient since it doesn't offer the needed indirection). Stefan
Re: AUCTeX and "builtin latex mode" integration
>>> "SM" == Stefan Monnier writes: > You may have seen an on-going discussion about the annoyance of the > mixups between latex-mode and LaTeX-mode and such. > I do think it would be good to try and "integrate" the two modes, for > some definition of "integrate". The question being indeed what > "integration" is the best way forward. > I'm wondering if it would be possible to turn AUCTeX into a minor mode. > E.g. `LaTeX-mode` would then be redefined as > (define-derived-mode TeX-latex-mode latex-mode ... > (AUCTeX-mode 1)) Two remarks 1. Why can't latex-mode not be removed/substituted by auctex? 2. What's about reftex? Right now, since auctex provides a mayor mode, you can put it in a hook to startup reftex when you open a latex file with auctex installed. Would that be a problem, if auctex is no longer a «real» mayor mode? Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
Re: AUCTeX and "builtin latex mode" integration
Hi Stefan, > Stefan Monnier writes: > You may have seen an on-going discussion about the annoyance of the > mixups between latex-mode and LaTeX-mode and such. Could you tell us where that discussion takes place? > I do think it would be good to try and "integrate" the two modes, for > some definition of "integrate". The question being indeed what > "integration" is the best way forward. I also want some improvements with regard to the "integration" because I recently realized that emacs built-in `tex-mode' (accidentally?) shadows AUCTeX `TeX-tex-mode' since emacs 28.1, to fail to enter LaTeX mode for some cases[1][2]. (I'm not sure that the above discussion involves this issue.) [1] thread beginning with https://lists.gnu.org/r/auctex/2022-08/msg1.html [2] https://tex.stackexchange.com/questions/648955/auctex-inconsistent-behavior-tex-vs-latex > I'm wondering if it would be possible to turn AUCTeX into a minor mode. > E.g. `LaTeX-mode` would then be redefined as > (define-derived-mode TeX-latex-mode latex-mode ... > (AUCTeX-mode 1)) > and `TeX-modes-set` would add/remove `AUCTeX-mode` from the hooks like > `latex-mode-hook`. It basically looks reasonable. I assume that you are thinking that `AUCTeX-mode' actually chooses suitable behavior according to the value of `major-mode' between `latex-mode', `plain-tex-mode', `doctex-mode' and `texinfo-mode'. > There's no doubt that it would introduce some (presumably minor or > easy to fix) breakage in some corner cases for some exotic configs, of > course, but I feel like in the long run it might be worth it. +1 Here are some random thoughts. 1. There will be some overheads because it first runs initialization codes of emacs built-in mode and then runs AUCTeX minor mode; I expect that the associated cost is cheap enough. 2. AUCTeX still must retain some major modes, i.e., ConTeXt mode, AmS-TeX mode, Japanese LaTeX mode and Japanese plain TeX mode because there are no counterparts in emacs built-in modes. 3. Currently, there is defect in handling doc strings of AUCTeX LaTeX mode, plain TeX mode and docTeX mode; C-h m and C-h f show doc string of built-in modes, not AUCTeX modes. `AUCTeX-mode' should put suitable `function-documentation' property for the respective major mode symbol. 4. `TeX-tex-mode' and `tex-mode' would need some special treatment. > To be honest, I haven't looked very much at the code to see how > realistic this is, but I think this could help clarify the situation > for users. E.g. it would eliminate "lies" such as (setq major-mode > 'latex-mode) in `latex.el`. From the users' point of view, I don't think it matters much. They just specify %%% mode: latex as the file local variable and think that they are using `latex-mode'. I think that it would be only Elisp programmers that care about the "lies". Best regards, Ikumi Keita #StandWithUkraine #StopWarInUkraine
Re: AUCTeX and "builtin latex mode" integration
Stefan Monnier writes: > What I'm really asking here is if there's a willingness to introduce > the inevitable bit of breakage in exchange for a supposed longer term > benefit, and/or if someone can think of a better way to move towards a > better long-term arrangement than the status quo. I wonder why/if it's important that the AUCTeX modes identify as the builtin modes, i.e., what would be the issue with having (La)TeX-mode major-modes which have no relationship to (la)tex-mode at all plus a setup command users would call in their init file in order to modify `auto-mode-alist' so that the AUCTeX modes are added? Bye, Tassilo
Re: AUCTeX and "builtin latex mode" integration
David Kastrup [2022-09-19 23:20:27] wrote: > Stefan Monnier writes: >> I'm wondering if it would be possible to turn AUCTeX into a minor mode. ]... > Doesn't really seem to fit the conventions for major and minor mode > keybindings. Not sure what you mean by that. Are you presuming that the `AUCTeX-mode` would place its bindings in the `minor-mode-map-alist`? If so, no, that's not what I'm suggesting. We would clearly want to preserve the current behavior as much as possible, so the `AUCTeX-mode` minor mode would put its keybindings on the "major mode map". Maybe with something like (use-local-map (make-composed-keymap auctex-mode-map (current-local-map))) Most minor modes use `minor-mode-map-alist` for their key-bindings, but there's no rule that imposes this choice. That are also several minor modes which either have no key-bindings, or put theirs in `emulation-mode-map-alists`, or in the global keymap, ... [ I suspect there are also minor modes which do something like what I suggest, tho I must admit that none comes to mind right now. ] Depending on the hurdles we encounter when implementing my suggestion, we might also want to start with a first-cut which only supports *enabling* the minor mode and burps when someone tries to disable it since it doesn't seem like it would be the most important functionality: I'd first and foremost focus on trying to preserve existing behavior instead. What I'm really asking here is if there's a willingness to introduce the inevitable bit of breakage in exchange for a supposed longer term benefit, and/or if someone can think of a better way to move towards a better long-term arrangement than the status quo. Stefan
Re: AUCTeX and "builtin latex mode" integration
Stefan Monnier writes: > You may have seen an on-going discussion about the annoyance of the > mixups between latex-mode and LaTeX-mode and such. > > I do think it would be good to try and "integrate" the two modes, for > some definition of "integrate". The question being indeed what > "integration" is the best way forward. > > I'm wondering if it would be possible to turn AUCTeX into a minor mode. > E.g. `LaTeX-mode` would then be redefined as > > (define-derived-mode TeX-latex-mode latex-mode ... > (AUCTeX-mode 1)) > > and `TeX-modes-set` would add/remove `AUCTeX-mode` from the hooks like > `latex-mode-hook`. > > To be honest, I haven't looked very much at the code to see how > realistic this is, but I think this could help clarify the situation > for users. E.g. it would eliminate "lies" such as (setq major-mode > 'latex-mode) in `latex.el`. It would also mean that `TeX-latex-mode` > runs `latex-mode-hook`. There's no doubt that it would introduce some > (presumably minor or easy to fix) breakage in some corner cases for > some exotic configs, of course, but I feel like in the long run it > might be worth it. > > WDYT? Doesn't really seem to fit the conventions for major and minor mode keybindings. -- David Kastrup
AUCTeX and "builtin latex mode" integration
You may have seen an on-going discussion about the annoyance of the mixups between latex-mode and LaTeX-mode and such. I do think it would be good to try and "integrate" the two modes, for some definition of "integrate". The question being indeed what "integration" is the best way forward. I'm wondering if it would be possible to turn AUCTeX into a minor mode. E.g. `LaTeX-mode` would then be redefined as (define-derived-mode TeX-latex-mode latex-mode ... (AUCTeX-mode 1)) and `TeX-modes-set` would add/remove `AUCTeX-mode` from the hooks like `latex-mode-hook`. To be honest, I haven't looked very much at the code to see how realistic this is, but I think this could help clarify the situation for users. E.g. it would eliminate "lies" such as (setq major-mode 'latex-mode) in `latex.el`. It would also mean that `TeX-latex-mode` runs `latex-mode-hook`. There's no doubt that it would introduce some (presumably minor or easy to fix) breakage in some corner cases for some exotic configs, of course, but I feel like in the long run it might be worth it. WDYT? Stefan
