Ping! Gentlemen, may I kindly ask you to try to bring this to an end? I'd like to push 14.2.0 out the door soon. I'd really appreciate if we could finish this.
TIA. Best, Arash Al Haji-Ali <[email protected]> writes: > Hi both, > > preview-automatic frequent updating of the preview (while fast-typing) > surfaced some stability issues in the preview code that were difficult > to come across in normal non-automatic use. So to address these first, I > am attaching a patch to preview.el which should be applied independently > of preview-automatic. These are the issues and fixes: > > - LaTeX can report a tiny positive bounding box for a visually empty > snippet (e.g. \( \)), which Emacs's image loader would reject and > display "Invalid image size" messages. Fixed by testing for > degeneracy (preview--degenerate-box-p) and showing the error icon > instead of the image at both display paths. > - When an overlay borrowed a still-rendering placeholder from a prior > overlay, ownership was transferred via a single assoc-list > splice. Under fast re-triggering, two overlays could end up sharing > (and double-deleting) a file. Fixed by using the reference counting > machinery (preview--filenames-refcounted-p/-entry-string). > - preview-parse-messages locates snippet boundaries by searching for > text captured at compile time; if the buffer was edited mid-compile, > the search could land in the wrong place with no way to detect it, > silently installing a preview for the wrong text. Fixed by tracking > failure explicitly (reloc-failed) and falling back to an existing > overlay's own bounds (preview--fallback-bounds), or skipping placement > if there's nothing to anchor to. > - When buframe showed a preview, it compared overlays by identity > instead of content, rebuilding on every re-preview even when nothing > visible changed. Fixed by comparing the image by value. > > Following Paul's reports, I also modified preview-automatic to be more > stable, especially with regards to silent updates, and prioritizing the > user's processes. This is in the attached file. > >> I suspect we can converge on the mechanism quickly. Al's >> preview-silent-errors is close. The additional primitive I'd like is a >> function that behaves like preview-automatic-update, but accepts a >> region rather than a point and specifies no policy. > > I am happy to factor this out, but wouldn't setting policy function be > able to supply the region? > >> For the built-in policy, I'd be happy for preview-at-point to select the >> region by default, as Al suggests. My immediate issues are related to >> regions getting previewed without first checking that they are complete. >> texmathp identifies whether point is in math, but not whether the math >> is complete. preview-auto searches for matching closing delimiters (and >> I'd be happy to try to adapt some of that code here, if we can't think >> of a simpler way). > > I knew of this issue, but I wasn't sure it's worth fixing > out-of-the-box. We can definitely use texmathp to test if the region is > closed or not, which would work for environments and latex's \[ \] or \( > \). For example, see that attached function. > > This does not check if $ or $$ are properly closed which is much more > annoying, and might make auto-previewing significantly slower, so it > depends on how much we want to protect against this. > > Best regards, > -- Al _______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
