This has something to do with org-indent or the org-element-cache. So this may be a “revealed bug” in that code, which was perhaps relying on some flaw in movement around larger images. I don’t think there’s an urgent need to revert; I’ll bring this to the org folk’s attention. > On Dec 3, 2023, at 4:25 PM, JD Smith wrote: > > I’m sorry to report that this fix seems to have introduced a hard lockup in org-display-inline-images, when displaying images in an org file with larger images. > > I just confirmed by reverting to the state just before your patch was applied to master. It may have something to do with the final large image fix. > >> On Dec 3, 2023, at 11:31 AM, Eli Zaretskii wrote: >> >>> Cc: 67533@debbugs.gnu.org >>> Date: Sun, 03 Dec 2023 17:52:12 +0200 >>> From: Eli Zaretskii >>> >>>> From: JD Smith >>>> Date: Sun, 3 Dec 2023 10:48:20 -0500 >>>> Cc: 67533@debbugs.gnu.org >>>> >>>>> The cumulative patch below should fix all the problems you threw on me >>>>> till now. >>>> >>>> Most excellent, thank you for the sleuthing Eli! Your roll-up patch applies cleanly and fixes all the pixel size related issues in my large complex org-with-latex-preview file. I can induce the same behavior in my original svg-generating code by bumping the default width up to: >>>> >>>> (w (+ 142 (* 2 (round (expt (1+ r) 1.25))))) >>>> >>>> and it solves it there too. (I’ve updated the gist to do this, and included the final function below, for posterity). >>> >>> Thanks, I will install the changes (on master) soon. >> >> Now done. >> >> Is there anything else to do here, or can we close this bug? >> >> Thanks. >