Hi Al,
>> 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.
> My 'off-point special treatment does not simplify the implementation,
> but I simply don't know what's the best thing to do (given that we
> agreed to keep the previews open when the source is modified).
>
> For reference and your testing, I attach a patch which removes the
> off-point special treatment (in `preview-disable`). I am happy to leave
> it like this and document that `'off-point` works best with
> `preview-keep-stale-images` being nil as I do in this patch in
> `preview-visibility-style`.
>
> However, you will see that the behaviour with
> `preview-keep-stale-images` being non-nil is highly non-intuitive:
> - Editing the source replaces the icon with a stale image (when using
> 'always, the stale image is simply kept).
> - Moving away from source does not collapse the preview (as we discussed
> since the preview does not match the source).
>
> I don't see a good way to design this, which is why I was suggesting
> ignoring when `preview-keep-stale-images` is non-nil. As you mentioned,
> this might be an unnecessary discussion since this combination of
> settings is likely to be rare and we can leave it as is until someone
> complains with a better suggestion.
I agree that this new version behaves counterintuitively, and that
editing the source should not replace the icon with a stale image.
My feeling is that with 'off-point, the option preview-keep-stale-images
should control whether the construction icon is replaced by the stale
preview during regeneration, and nothing else. That way, previews are
open after source is modified (until regeneration begins), and
preview-keep-stale-images has some effect.
I believe we discussed this approach already and there were some pros
and cons (e.g., it might be unclear when the preview fails to generate),
so I'm likewise happy to leave it like it was in the previous patch
until someone who uses that combination of settings complains.
>> 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).
> [cont]
>>
>> I might be misremembering on this point -- I tried testing just now,
>> and it wasn't so jarring with the TeX source visible. Moreover, it
>> seems like the TeX source stays visible during the brief regeneration
>> even after loading an earlier preview.el.
> OK, I am not sure anymore. I believe the old and current versions close
> the preview (hide the source) while it's being generated. My idea of the
> "contract" is that the preview should only replace the source when it is
> an accurate reflection of it, and when the user is not editing the
> source. That is why I was suggesting keeping the preview open while
> generating. However, I tested this and it is indeed quite jarring, so I
> suggest we leave it as it as.
Sounds good.
> BTW, I restored `preview-inactive-string` and `preview-disabled-string`
> and marked them obsolete. I also tried adding a value setter for
> `preview-leave-open-previews-visible` as you suggested, however I ran
> into an issue where setting the value of `preview-keep-stale-images` and
> `preview-visibility-style` before loading preview, then loading preview
> results in resetting those variables (because
> 'preview-leave-open-previews-visible' is set to nil when defined), so I
> don't think it's a good solution. I am open to suggestions.
OK, I see. I can try thinking a bit more about this later.
Thanks, best,
Paul
_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex
