>>> What if we have multiple overlays at point? For example latex preview
>>> overlay inside table with shrunk columns.
>>> I think it will glitch with display-live=t
>>
>> I couldn't get it to glitch, but if you have a reproducer let me know.
>
> 1. make repro
> 2. (setq org-latex-preview-mode-display-live t)
> 3. Open
> | <5> | <50> |
> | \( 11 - 2 = 3 \) | this is test |
> 4. M-x org-latex-preview-mode
> 5. On table, C-c tab
> 6. Enter the cursor into the equation, no preview is displayed
> 7. C-c tab - preview is displayed
> (also, table alignment is a mess, but that's a different story)
Okay, I follow.
>> I understand the issue in principle: some other org-overlay-type
>> covering a LaTeX preview overlay, but in three years of using this
>> feature I haven't had it happen.
>>
>>
>> [...]
>>
>>
>> But if there are multiple overlays that are setting the display property
>> I think glitches will happen no matter what. Let me know what you
>> think.
>
> I think that you have
> (dolist (o (overlays-in beg end))
> (when (eq (overlay-get o 'org-overlay-type)
> 'org-latex-overlay)
> in several places.
> That should be reliable.
> There is also `org-find-overlays'.
I have replaced most of the get-char-property checks with explicit loops
like the above dolist. I used cl-loop instead of cl-find or seq-find to
find the LaTeX overlay for speed -- many of these checks happen in pre
and post command hooks.
I also benchmarked the performance of the loop to that of
get-char-property. They are comparable when there are only 2-3 overlays
at point. I tested a case with 70 overlays over one point and the
cl-loop method was slower, but still not noticeable in practice.
seq-find was much slower.
In any case, this does not fix the issue with multiple overlays fighting
for control of the display property, and live LaTeX preview display in
shrunk table columns (for example) is quite broken. There is no easy
way to fix this, as far as I know. (We use a low priority for the LaTeX
preview overlay to not interfere with hl-line, etc.)
>>>> (get-char-property (point) 'view-text)
>>>
>>> So, 'view-text is boolean. I think it is worth discussing the values of
>>> 'view-text and other special properties in the comment describing how
>>> preview-mode works.
>>
>> Added for all four special overlay properties. But in the process I
>> realized org-latex-preview-mode--insert-front-handler and
>> org-latex-preview-mode--insert-behind-handler might not be needed at
>> all. I'm leaving it in for now and it should be fine to include them in
>> the patch, but I will need to do some testing to make sure I'm not
>> misunderstanding their purpose.
>
> Ok. In theory, overlay should automatically expand as text is
> inserted/deleted, given that their market types are correct.
I was aware of this fact in winter 2022 as well, so I'm assuming I added
these for some reason. I think we can leave it in.
>>>> (elem-end (- (org-element-property :end element)
>>>> (or (org-element-property :post-blank
>>>> element) 0)
>>>> (if (eq (char-before (org-element-property
>>>> :end element))
>>>> ?\n)
>>>> 1 0)))
>>>
>>> This will be broken if a latex environment has blank lines that are not
>>> mere newlines but also contain whitespace.
>>
>> Why? I tried it with
>>
>> --8<---------------cut here---------------start------------->8---
>> \begin{align}
>> x + 3
>>
>> \end{align}
>>
>>
>> And some more text
>> --8<---------------cut here---------------end--------------->8---
>>
>> with the point in the align environment, which has a blank line with
>> some whitespace. It appears to work as expected.
>
> :post-blank for paragraph-like elements is a number of lines.
> It is literally calculated using `count-lines'.
> So, :post-blank cannot, in general, be used to calculate character
> offsets.
> In particular, when you have somethink on the blank lines after element.
> Try adding some tabs and spaces + a dozen of lines. You will get wrong
> results.
I understand the issue now. I thought you meant whitespace-only lines
_inside_ the LaTeX environment, not after. I'm working on a fix.
>>>> (if org-latex-preview-mode
>>>> (progn
>>>> (setq org-latex-preview-mode--marker (make-marker))
>>>> (add-hook 'pre-command-hook
>>>> #'org-latex-preview-mode--handle-pre-cursor nil 'local)
>>>
>>> What if there is indirect buffer?
>>
>> It works fine in indirect buffers when the buffer-local variables and
>> hooks get copied over. Do you have an example of a problem?
>
> 1. make repro
> 2. Open
> * Test
> \( 12 - 2 = 3 \)
> 3. M-x org-latex-preview-mode and trigger preview
> 4. M-x org-tree-to-indirect-buffer
> 5. Switch to the new buffer
> 6. Go into the formula and edit it
> 7. Move away, observe preview being updated in the indirect buffer
> 8. Preview in the main buffer is not updated.
Discussed off-list. The conclusion is that we want to document this
limitation in the docstrings of org-latex-preview-mode-track-inserts and
org-latex-preview-mode-display-live for now, with the possibility of
improvements in the future.
Added to docstrings.
