> Hmmm... I am not sure what I am missing. On my setup, the construction
> symbol only appears when the source is modified. If I open the preview
> by having the cursor "go into" the preview image, then navigate away
> from the source, the preview is collapsed again if I don't modify the
> source.
>
> The documentation is also unclear, because the first part of
> `preview-leave-open-previews-visible` leans toward what you say:
>
> --8<---------------cut here---------------start------------->8---
> Whether to leave previews visible when they are opened.
>
> If nil, then the TeX preview icon is used when the preview is opened.
> If non-nil, then the preview image remains visible. In either case, the
> TeX code appears either below or to the right of the displayed graphic.
> --8<---------------cut here---------------end--------------->8---
>
> but then the next part is what I am seeing:
>
> --8<---------------cut here---------------start------------->8---
> If you enable this option, the preview image doesn't turn into
> construction sign temporarily when you edit the underlying LaTeX code
> and regenerate the preview; it is just replaced by updated image when
> ready. This behavior suppresses flicker in the appearance.
> --8<---------------cut here---------------end--------------->8---
I may have added to the confusion by writing "construction symbol" (what
shows up when a preview is regenerating) in a few places where I should
have written "TeX symbol" (what shows up when the TeX source is made
visible after point enters a preview).
You're right that the docstring covers two behaviors: (i) what happens
when a preview is revealed, and (ii) what happens when it's regenerated.
I was talking about (i) before. Since you write that the discussion
below clarified things somewhat, I'll focus my response there.
>
>> Let me restate the proposal using your terminology and proposed setting
>> 'preview-display-style' (for which the 'both option is not what I had in
>> mind, but could also be considered). Two independent knobs:
>>
>> - preview-display-style ('preview, 'src): controls what's shown for
>> previews away from point, that the cursor is *not* inside.
>>
>> - preview-reveal-display ('none, 'after, 'before, 'buframe). What to
>> show when point enters a previewed region (i.e., the overlay or the
>> underlying tex source):
>>
>> - 'none means just show the tex source and the construction sign
>>
>> - 'before means show the preview before the tex source while editing
>>
>> - 'after means show the preview after the tex source while editing
>>
>> - 'buframe means to show the preview in a buframe while editing
>>
>
> OK, this makes it clearer somewhat. Though see above regarding how
> modification of the TeX source changes behaviour (at least in my
> setup). You also mention "while editing", so what happens when not
> editing?
When I say "while editing", I mean "when the point enters the TeX
source, so that the user could in principle edit it". Consider how
'preview-point' behaves right now: either the point is inside some TeX
region (that's what I mean by "while editing"), or away from it.
Behavior "when not editing" is controlled by 'preview-display-style'.
>> Let's translate current behaviors to the above setup:
>>
>> Traditional preview with preview-leave-open-previews-visible nil:
>>
>> (setopt preview-display-style 'preview)
>> (setopt preview-reveal-display 'none)
>
> I am gonna assume you mean that while editing or during the generation
> of the preview the construction sign appears (before or after?). What
> happens when the preview is ready?
When the point later exits the TeX source (and, if modification occurs,
after the preview regenerates), the display reverts to what is specified
by 'preview-display-style'.
>> One benefit of separating these concerns is that we could keep
>> traditional preview behavior away from point while using a buframe for
>> live editing of tex source:
>>
>> (setopt preview-display-style 'preview)
>> (setopt preview-reveal-display 'buframe)
> This is what I was trying to say. I think using a buframe for source
> editing is not really tenable and would be too difficult to get
> right.
I think we have a misunderstanding. By "using a buframe for source
editing", I mean:
- The point is in the TeX source, editing the TeX code there.
- The previewed math is (only) displayed in a separate buframe (updating
live as the user edits, if automatic previewing is enabled).
This is what exactly 'preview-point' already does in its current
implementation. (It sounds to me like you thought I was proposing to
have the TeX source in the buframe, which was not my intention; I can
see how you would view that proposal as untenable.)
> Overall, I am of the opinion that (modulo some forward-thinking
> introduction of the options) we do not over-complicate the current
> implementation at this point by introducing more modes of operation.
I don't think I'm proposing to introduce more modes of operation. I'm
just observing that preview-point bundles two orthogonal features: (a)
disabling preview display by default, and (b) richer customization of
how to display the preview at point. Feature (b) would be useful even
without feature (a), so it seems worth decoupling the two and allowing
them to be configured separately. Does that clarify what I had in mind?
Thanks, best,
Paul
_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex
