>> 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
