Re: AUCTeX and "builtin latex mode" integration

[Arash Esbati]

Stefan Monnier <monnier@iro.umontreal.ca> 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