Hi Al,
>> Another related point: when preview-keep-still-images is t and
>> preview-visibility-style is 'off-point, as the preview starts
>> regenerating, the construction icon flashes. I feel like setting
>> preview-keep-still-images to t should universally suppress the
>> construction icon. It does when preview-visibility-style is 'always, so
>> why not also when it is 'off-point? (If it did, then
>> preview-keep-still-images would retain some relevance in the 'off-point
>> case.)
>
> Yes. As noted, when `preview-visibility-style` is `off-point`,
> `preview-keep-still-images` is ignored; so what you describe is intended
> behaviour.
>
> I take your point about suppressing the construction icon. That said,
> the behaviour follows from the earlier discussion about keeping the
> preview open when modified.
The earlier discussion (as I understood it) was about how the preview
looked immediately after editing, not while it regenerates. I don't see
any reason the two behaviors should be the same. For instance, they
currently differ when preview-visibility-style is 'always (in a good
way, in my opinion, as discussed below).
> Showing an icon immediately before generation, then briefly flashing
> the old preview on regeneration, risks suggesting the preview failed
> to update, before it is replaced by the correct one.
OK, I see what you mean here -- I don't experience preview failures
often enough to have a sense for how useful this is, but can imagine.
> On the other hand, I am not sure what the benefit of such behaviour
> would be.
The motivation for that behavior (preview-leave-open-previews-visible)
was to eliminate flickering with automatic and/or live previewing
enabled. Seeing as most users of automatic previewing will probably
take visibility-style to be either 'always or 'at-point, there's perhaps
less benefit in the 'off-point case under discussion, so if you feel
strongly and/or if it would complicate the implementation, then I'm
happy to leave it as is until someone else complains. So maybe all
that's left on this point is to sync the docs with the behavior.
> This behaviour would be even stranger once the preview correctly remains
> open during regeneration (which I haven't fixed yet).
Do you mean keeping the old image visible (no flicker), or keeping TeX
source visible? For my workflow ('always with automatic previewing),
keeping the TeX source visible during regeneration would feel jarring.
The contract is that the TeX code is visible only while I'm editing it.
Otherwise, I just see previews everywhere, which update as soon as they
can (a fraction of a second).
>> If I recall correctly, I did get the chance to test the latest buframe
>> code on a multi-monitor setup earlier this week and that it continued to
>> misbehave, but I didn't get the chance to look closely at this.
> OK. I just had a chance to test on a multi-monitor setup (on macOS
> FWIW). The new "fix" is indeed wrong. However, after undoing the fix
> (i.e., using the old way of getting window coordinates), the previews
> with buframes work flawlessly on my setup with either monitor. So we're
> gonna have to dig deeper into this issue on your system.
>
> One way to proceed is if you can tell me what your OS/windowing-system
> are and what does `window-inside-pixel-edges` and `frame-position`
> return when called on a new frame in different monitors (the first
> return value should be the same while the latter should be different).
I'm on macOS. You can probably see my detailed specs in the debug
attachments from a couple messages ago.
Here are the stats for the main, secondary and tertiary monitors in my
current setup.
With fullscreen frames:
window-inside-pixel-edges:
(10 18 1711 1030)
(10 18 1270 1390)
(10 18 955 1030)
frame-position:
(1 . -1432)
(0 . -2512)
(3 . 45)
With a non-fullscreen window, dragged to the upper-left corner of each
monitor:
window-inside-pixel-edges:
(10 18 388 544)
(10 18 388 544)
(10 18 388 544)
frame-position:
(1 . 38)
(2 . -1415)
(0 . -2495)
Hope that helps!
Thanks, best,
Paul
_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex
