Hi Paul,

On 30/10/2025, Paul D. Nelson wrote:

> I've started taking a look and have several comments.
Thank you for taking the time, really appreciate it as well as your
earlier work on preview-auto.

What's the best practice here about updating patches? Should I send an
updated full patch or a new one on top of the current one?

> I have several unrelated comments:
Thanks for those, I agree with all of them and will make those changes.

> It would be much more ergonomic if we could enable preview-point after
> visiting a buffer.  Is this a hard limitation?
No, I can make this change. It would simply require modifying a couple
of hooks. Should the logic be in a custom-setter code, or in a
function/mode? Note that the setting has to be global (at least in the
current implementation -- though I might be able to make it buffer-local
if there's a real need for it).

> The documentation does not indicate any intended value.  Also, from what
> I understand, this setting controls when new previews are generated, but
> does not affect whether existing previews are automatically regenerated;
> the docs don't seem to emphasize this distinction.
This setting should be for both. Updating existing previews when the
text is changed and for generating new ones whenever
`preview-point-auto-p` returns non-nil on (point). For example, one can
set it to `texmathp` to automatically generate previews for math
expressions. I will see how I can update the documentation to better
reflect this.

> The command ends in "-mode" but does not come from a major/minor mode.
> Perhaps instead something like "preview-point-toggle-display"?
>
> It might be cleaner to move the body of this command to a custom setter
> for preview-point and then either delete the command altogether, or
> rewrite it as a light wrapper around customize-set-variable.  That way,
> users can tweak preview-point via either the new C-c C-p C-t bind or
> customize-set-variable.

I'll see how that would look. Just to say, the purpose of this command
is to provide an easy way to hide/show previews, for example if they are
getting in the way of editing text. I wasn't thinking about it as a way
to enable preview-point. I am open to suggestions of improvement
to this interface.

>> +(defun preview-point-toggle-auto-update (enable &optional silent)
>
> This reads like a minor mode.  I would suggest introducing a small,
> display-agnostic "preview-automatic-mode", bound to C-c C-p C-a, that,
> when enabled, automatically regenerates existing previews, for both
> preview-point and "traditional" preview.  This aligns with an earlier
> suggestion [1] to upstream automatic previewing.  (It's simpler than
> preview-auto, which also *finds* new regions to preview, but that
> feature could be added later via a strategy variable or hook.)  I'd be
> happy to draft that refactor on top of your patch if the idea sounds
> reasonable.
>
> [1] https://lists.gnu.org/archive/html/auctex-devel/2024-06/msg00031.html

I agree a minor mode is better here and a patch would be appreciated
(once I send the updated one with your suggested changes).

I had actually wanted to ask you if the introduction of
`preview-point-auto-p` could be a clean way to incorporate the logic of
`preview-auto`, since I think one can have the clever code in
preview-auto which detects if a preview should be generated as a
customization of this variable.

My thinking is to have automatic previewing split into two logical
parts: The mechanism of updating previews which should be general
enough, and the detection of when to do it which will be
user-controlled.

In any case, I think it would be good to have the infrastructure of
automatic previewing which is being added here as suitable for the
integration of preview-auto as possible (we might need to modify
`preview-point-auto-p` so that it can return a region).

>> +
>> +;;; preview-point -- Auto-preview
>
> If we refactor as suggested above, then most of the functions below
> should be given agnostic names ("preview-automatic-*"?), reflecting that
> they are not specific to the preview-point feature.
Agreed, though I haven't tested automatic previewing without
preview-point.

> --8<---------------cut here---------------start------------->8---
> Automatic previewing code derived from preview-auto.el (Copyright 2024
> FSF, by Paul D. Nelson), adapted and integrated by Al-Haji Ali.
> --8<---------------cut here---------------end--------------->8---
Will add this comment to the commit message. 

Best regards,
-- Al



_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex

Reply via email to