Hi Philip (CC: Arash, in case you have further thoughts),


>   Perhaps it should be renamed to something like "latex-numbering"?
>

Thanks for this suggestion, agreed.


>
> > tex-continuous provides a minor mode in which a tex document is compiled
> > continuously using latexmk, the error log is parsed using AUCTeX, and
> > errors are reported via flymake.
>
> That sounds interesting.  Here again, tex- implies one thing but latexmk
> another.


How about "latexmk-continuous"?  (The names latex-flymake and
auctex-latexmk are both taken, and those packages do different things.  The
new feature is that the compilation takes place continuously rather than on
demand, with the errors reported in the buffer.)


> Is the dependency on latexmk hard, or could you re-use AUCTeX's facilities?
>

AUCTeX provides TeX-command-run-all, which does something similar to
latexmk (and also runs "View" at the end, displaying the PDF, which I
suppose could be disabled somehow).  I considered swapping latexmk for
TeX-command-run-all + after-save-hook, but this seemed troublesome for a
few reasons.  One was that the timer for preview-auto (my other package,
mentioned below) doesn't fire when AUCTeX's processes are active, so if we
use AUCTeX to regularly recompile the document, then there will be
stretches of time in which the previews don't update.  The use of a
separate (latexmk) process adds something like a secondary compilation
thread, keeping the primary thread free for preview-auto.

I don't view the dependency on latexmk as serious, since I believe it is
included nowadays in all tex distributions (and I have colleagues who have
been using my package on each of the major OS's, so it seems portable in
practice).  My package does re-use AUCTeX's error parsing facilities, which
in some sense provide the heavy lifting, and also respects some AUCTeX
configuration variables, such as TeX-output-dir.  I'd be happy to update
the package to use more of AUCTeX's facilities if someone spotted a way to
do so without the issues that I encountered.



>
> > preview-auto provides a minor mode in which AUCTeX previews generate
> > automatically in the visible part of the buffer.
>
> This makes me think, have you communicated any of these features to the
> AUCTeX developers?  Perhaps it would make more sense to upstream these
> as patches instead of having too many little packages?
>
>
They've been communicated, and the first two have been discussed:

https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00043.html
https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00066.html
https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00086.html

They rely on recent AUCTeX patches:

https://lists.gnu.org/archive/html/bug-auctex/2024-04/threads.html

The question of upstreaming one of them was raised:

https://lists.gnu.org/archive/html/auctex-devel/2024-04/msg00173.html

I'd be happy with whatever makes the most sense, but figured submitting to
ELPA would make them readily available without introducing additional
burden on the AUCTeX maintainers.

On the topic of "too many little packages", I'll confess that I have a few
more in the queue, e.g.:

https://github.com/ultronozm/tex-parens.el
https://github.com/ultronozm/tex-item.el
https://github.com/ultronozm/preview-auto.el

(plus a few more, listed at https://github.com/ultronozm/emacsd, that I'd
like to think about more before "formally" publishing)

I've been trying to split the functionality accumulated in my config into
the smallest coherent packages that I can, but would welcome feedback or
other suggestions, especially if there are trade-offs with having too many
little packages.

Thanks, best,

Paul