Hi Al,

>> One example involves abbrevs.  To reproduce, create an abbrev containing tex 
>> code (e.g., "dx" mapping to "$x$") and quickly type a couple abbrevs (e.g., 
>> "dx and dx" expanding to "$x$ and $x$").  Then I often get a preview for 
>> only the second formula.  If I keep typing, then both previews often fail to 
>> generate.
>>
>
> I would actually expect no previews in this case. When a command (an
> abbrev, a yank, a snippet) inserts a complete math region and leaves
> point after it, no preview is generated, however slowly you type. The
> same happens if you leave a math region and start typing before its
> preview has been generated, either within preview-automatic-delay or
> while LaTeX is still running.
>
> This is by design. Previews are only generated for the region at point
> when Emacs becomes idle, so each idle period starts at most one preview
> run. Tracking every changed region instead would make the work
> unbounded: a large yank, a query-replace or an undo would queue a
> preview for every math region it touched, which effectively runs
> preview-buffer in the background while you edit. Tying previews to point
> seemed the most reasonable compromise between efficiency and
> convenience.

Thanks, that clarified the intended behavior.  In my workflow, I
regularly insert complete formulas using abbrevs and then continue
typing prose.  I agree that queuing every changed formula throughout the
document ("effectively preview-buffer") would be excessive, but there
are alternatives.  For instance, preview-auto searches a configurable
neighborhood of point, skips existing previews, batches nearby formulas,
etc.  This has worked well for me.  Could preview-automatic provide
(optional?) support for that kind of policy?  The callback that returns
regions comes close, but we would also need to be able to trigger
additional work after a preview run finishes.  I'd be happy to help sort
this out, or adapt any relevant code from preview-auto.

>> Here is something more deterministic.  Put point just before the closing $ 
>> of a generated preview, then do
>>
>>   M-: (progn (save-excursion (end-of-line) (insert " ")) (insert "+1")).
>>
>> The preview then fails to update.
>>
>
> This is a timeout bug unfortunately. I am not proposing this as a
> solution, but this should not happen if you use this branch on my fork:
>
> https://github.com/haji-ali/timeout/tree/timeout-state
>
> This fixes several issues in timeout which I proposed as a PR for
> Karthik, but haven't got a response yet. If this does indeed fix your
> issues as I suspect and we want to fix this issue on release, we might
> need to include a stripped-down version of the corrected functionality,
> which I really wanted to avoid.

Indeed, I've applied your changes to my local Emacs and they fix the
issue.  For now, is there any reason not to just drop the first branch
of

(if (require 'timeout nil t) ...)

until the timeout bug is fixed?

Thanks, best,

Paul



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

Reply via email to