Hi Paul, First of all, thank you for taking the time to check the package and for your work on preview-auto. I would also be happy to work together on this to make it relevant for a larger part of the community. I just had an itch to see previews in a frame which resulted in this package.
On 28/08/2025, Paul D. Nelson wrote: > 1. Any feedback on failure cases for preview-auto would be very welcome. I unfortunately haven't kept track of the failure cases. What I remember happening are endless loops of attempting to preview a region that has failed to be previewed. In my code, I changed the auto preview logic to fire a timer only once on every change, regardless of the preview result which seemed to reduce the chance of this happening. > 2. I noticed that most of the "automatic previewing" code in > preview-point is derived or copied verbatim from preview-auto (see the > excerpts below). That code is FSF copyrighted and GPLv3 licensed, so if > I understand correctly, you're free to modify and use it, but must > preserve copyright and license notices in the source. I understand that > your package is new and you may have just not had the chance to do this. Indeed, and I apologize for the lack in acknowledgement. To give some history, I wanted to integrate my code with preview-auto but ran into some issues which I tried to trace and copied some code to test fixes. However, I eventually gave up and just wrote a bare-bones version of it (since I don't have large documents as you do). To be clear, when I wrote the parts of my code for auto previewing, I indeed adopted the preview-auto code for silencing the write-region and for testing when an existing TeX process is running. I now see that I added the GPL licence text to preview-dvi but failed to include it in the other files. I fixed this now. > I see that you've stripped out the preview-auto code that finds new > regions to preview, which is useful for those of us who prefer previews > to generate automatically, and replaced it with a simple loop through > existing overlays, which suffices for those who prefer keeping the LaTeX > visible by default. A common approach would be to leave how to > determine which regions to preview automatically as a user knob. Indeed, the auto preview code I have is tailored to the case where the LaTeX code is visible. I mainly wanted something simple, which updates existing overlays and creates new ones when `preview-point-auto-p` returns non-nil. > In any event, as Uwe brings up in his responses, the stripped down > approach means that new LaTeX code (created via ordinary typing, > abbrevs, LaTeX-environment, copy/pasting from other files, ...) will not > be previewed until the user runs one of the ordinary commands. In my setup, since `preview-point-auto-p` is set to `texmathp`, the previews are generated automatically for math environments without additional key presses, when the point is placed in a math environment. Best regards, -- Al
