Hello all, I've now implemented everything over 6 commits (including the mentioned refactoring) in my fork of auctex:
https://github.com/haji-ali/auctex/tree/preview-point The configuration is similar to before, but is more incremental. --8<---------------cut here---------------start------------->8--- ;; The minimum is to set `preview-point` (setq preview-point 'buframe) ;; Using dvi source leads to higher quality images (setq preview-image-type 'dvipng preview-LaTeX-command-replacements '(preview-LaTeX-disable-pdfoutput)) ;; using dvisvgm is even better (see note below): (setq preview-dvipng-command #'preview-dvisvgm-command preview-dvipng-image-type 'svg) ;; Other additional configuration that enhance the experience: (setq preview-leave-open-previews-visible t preview-auto-cache-preamble t preview-locating-previews-message nil) ;; For instant frame display: (setq buframe-update-debounce-delay 0)) ;; If auto-previewing is desired, then set (setq preview-point-auto-p 'texmathp) ;; and call `preview-point-toggle-auto-refresh` interactively ;; or in a hook. --8<---------------cut here---------------end--------------->8--- Let me know if you have any suggestions on improving code/interface or if I made any mistakes in my implementation/documentations. NOTE on dvisvgm: dvisvgm is my preferred way to view previews since, unlike dvipng, it removes white-space around the preview, does not suffer from pixelation and the face of the previews can be modified. However, one problem with it is that it stops if one preview fails, see here: https://github.com/mgieseki/dvisvgm/issues/293 preview then uses dvips as backup which produces png images which is quite jarring. The developer of dvisvgm seems open to "fixing" this behaviour upstream. In the meantime, I wrote a small shell script that simply re-invokes dvisvgm, skipping failed pages, which has the desired effect (see issue above). On 05/09/2025, Arash Esbati wrote: > Until now, AUCTeX doesn't have any Emacs external dependencies; my gut > feeling is to keep it that way, i.e., bundle buframe.el with AUCTeX and > not as an ELPA package. It is probably easier for distros to offer > AUCTeX as a package. I agree with you regarding external dependencies. We can either: - include it in auctex, as I do in my current fork. That would be completely fine with me. - Have it as an ELPA package, and have code in auctex that makes use of it if the package is available (the two preview-point modes: after-string and before-string, would still work without it) - Or I can write extensible code that is buframe agnostic and leave it to the user to make the necessary customization (I would make sure it's minimal). My slight preference is to have buframe in a separate package in ELPA since I plan to use it in other places, and it is not tex-specific. However, I am happy with all three options. Best regards, -- Al
