Hello Paul,
On 22/11/2025, Paul D. Nelson wrote:
> I wonder whether the default should instead be a new setting "nil",
> meaning that previews at point are not be displayed at all (the current
> default behavior in AUCTeX).
I agree that the current situation is not ideal, in the sense that the
combination/naming of customization variables are not 100% coherent.
However, one use case for `preview-leave-open-previews-visible` (V) is
controlling if an icon is displayed in certain cases, e.g., when the
preview is disabled after editing or when it is being re-generated,
instead of the (outdated) preview. This use case is always relevant for
all values of `preview-point-where` and `preview-always-show`.
The other point is that, currently, the placement of the icon itself is
also determined by the value of `preview-point-where`. If we use a nil
value to denote icons, then we would fix the placement of the icon which
seems unnecessarily inconsistent with the new increased customization.
> I noticed the following issues (A), (B), (C):
What emacs version you are using and what value of `preview-auto-reveal`
(I mainly have my tests with it being set to `t`)?
>
> (A) With
>
> (setq preview-always-show t)
> (setq preview-point-where 'buframe)
>
I've seen this issue once, but I thought I already addressed it and I no
longer see it. I also don't recognize the behaviour you describe since
with these settings, calling `preview-at-point` updates the preview,
yeets the cursor out of the source and the preview is shown inline until
one enters it again whereupon it is shown in a buframe. Can you confirm
and/or provide more details?
> (B) With
>
> (setq preview-leave-open-previews-visible t)
> (setq preview-always-show nil)
> (setq preview-point-where 'buframe)
>
> Enter a generated preview, edit it, regenerate it in place (e.g., with
> 'preview-at-point'), and then exit it. Both the tex source and the
> preview remain visible (until the preview is regenerated, so let's
> suppose automatic previewing is disabled).
>
I don't see this behaviour either, definitely not with buframe. Can you
confirm again and provide more details (source)? The post-command-hook
`preview-move-point` calls `preview--update-buframe` which should hide
the buframe when the overlay at point does not have the buframe
property, so exiting the source should hide the buframe unless there's a
case I am not considering.
> (C) With
>
> (setq preview-point-where 'buframe)
>
> The buframe feature doesn't work correctly with a multi-monitor setup.
> On my main monitor, it works fine, but on my other two monitors, it
> either doesn't display at all or displays very far from the original
> preview graphic. I haven't dug in to debug this.
This is possible and is probably a bug in buframe. I will do some tests
to confirm and fix it there.
> The defcustom signature for the final option does not match the
> documentation (and if we adopt the final option via the customize
> interface, then it won't work correctly). Either put 'buframe in the
> first entry of the list, or test for the final option via 'listp'.
Apologies, I noticed this mistake after sending the patch. I had already
corrected it to the following, which I will send in an updated patch:
```
(choice
(const :tag "Before string" before-string)
(const :tag "After string (default)" after-string)
(const :tag "On frame" buframe)
(list :tag "On frame with explicit parameters"
(const buframe)
(choice
(const :tag "Default" nil)
(function :tag "Position function"))
(alist :tag "Frame parameters")
(alist :tag "Buffer parameters")))
```
>> +(defface preview-disabled-face
>> + '((t (:inherit shadow)))
>> + "Face used when preview is disabled."
>> + :group 'preview)
>
> It's not clear to me what the purpose of this new face is. I see that
> it affects the text stored in the before/after-string and strings
> properties of the overlay, but not the actual TeX code.
This face is for the preview itself rather than the source. I believe
the face's background colour will affect all previews, while the
size/foreground colour only has an effect if the preview is an svg
image. I could add this explanation to the docstring.
>> +
>> +(defvar preview--frame nil
>> + "The last active preview popup frame.")
>
> (Maybe consider something like 'preview--buframe' or 'preview--last-buframe'
> to hint at the domain scope of this variable.)
I prefer frame since that's the type of value, but I will update the
docstring to mention buframe.
> (This looks to be just a whitespace change; my understanding was that we
> usually avoid pure whitespace changes unless we're touching the code
> anyway, but others may know better.)
Indeed, I thought the spacing is wrong and could be fixed in this patch
since the function is being modified, but I can remove this change.
Best regards,
-- Al
_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex
