Hi Al, Thanks for your continued work on this. I've been using for a few days now and it's looking good.
> - When a preview fails or is modified (and thus disabled), it remains > open, showing the source, and its visibility follows > `preview-visibility-style` as expected. The exception is when > `preview-visibility-style` is `always` or `off-point` and > `preview-at-point-placement` is `buframe`. In this setup, the preview > is not shown away from point, because only one buframe can be visible > at a time, and it always displays the preview under point. This seems > inherent to the design; it likely just needs to be documented, though > I'm not sure my current wording is adequate. I understand the constraint about not having multiple buframes visible at the same time, but consider the following experiment. Take preview-visibility-style = 'always, preview-keep-stale-images = t preview-at-point-placement = 'buframe Render a preview, modify the underlying tex source, move point away, and render it again. There's a brief moment, before it shows the new preview, where it shows the old preview instead of the TeX source. Question: in the above scenario, should the old preview appear (covering the TeX source, like it did before we modified) as soon as point moves away, rather than just for a brief moment while the preview generates? Besides that such behavior makes sense to me intuitively, it also seems consistent with how preview-keep-stale-images is documented, and does not violate the "multiple buframe" constraint. A related point: the docs suggest that that 'always and 'off-point should yield the same behavior for previews away from point, but this is not the case after modifying a preview and moving point away. I think it would be the case if, after modifying the TeX source of a preview and moving point away, - preview-keep-stale-images=t meant that the old preview covers the modified source, and - preview-keep-stale-images=nil meant that the TeX icon appears to the left of the modified source, like it does by default in AUCTex. > - Another point is that, while I like splitting > `preview-leave-open-previews-visible` into `preview-keep-stale-images` > and `preview-visibility-style = 'off-point` (in particular, it allows > always showing non-stale images), there's one issue. If > `preview-keep-stale-images` is t, while `preview-visibility-style` is > 'off-point, then modifying the source disables the preview, but > reusing the image is nonsensical since the preview is replaced by an > icon when opened. Currently stale images are not kept in either of > those case. I feel this is OK, but I am open to suggestions. I would have thought that "reusing the image" here would refer to what happens when point moves away from the modified TeX source, like in my response above. In fact, with preview-visibility-style = 'off-point, does preview-keep-stale-images make any difference at all? I'm not at all sure about this, but would it make sense to fold preview-keep-stale-images into preview-visibility-style, effectively taking the value nil precisely when preview-visibility-style='off-point? I might have guessed that most people who learn about these settings will want to use either 'always or 'at-point as well as automatic previewing, which work best with preview-keep-stale-images = t. One downside is that it would further complicate the docstring for preview-visibility-style. > As part of a small refactor I removed two old functions: > preview-disabled-string and preview-inactive-string, and used the new > macro preview--string directly instead. I think these are internal > functions, but let me know if I should retain them or mark them as > obsolete. I did a quick search through my package repos for these functions, and they turned up only in https://github.com/ultronozm/czm-preview.el. That package has been deprecated for a bit over a year (it's superceded by patches to AUCTeX + preview-auto), but I suspect a couple colleagues are still using it, so maybe marking as obsolete would be the gentler approach. Thanks again and best, Paul _______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
