Ignacio Casso San Román <[email protected]> writes:

>> That will cause bugs:
>> 2. Indirect buffer has its buffer-file-name set to nil, which is not
>>    expected by some code
> It does have a name, the first argument of `clone-indirect-buffer`, right?

But not file name (`buffer-file-name').

>> 3. You are passing DISPLAY-FLAG, that will unconditionally display the
>>    cloned buffer, which can trigger similar errors.
> I'm passing the value nil, so it doesn't display, right?

Right. Sorry, I missed the argument order.

>> Cloning buffer is also not a cheap operation. So, performance will
>> degrade.

> Could we only do it when it's actually needed then? When the buffer is
> visible in other window I mean. I proposed it because it was my
> understanding that it was not too expensive

Maybe. This is hard to judge without tests.
But the concern about overlays and other subtle unexpected changes are
more grave.

>> 1. Indirect buffer does not contain the original buffer overlays, so
>>    folding state will not be preserved
> But yes, I guess this will be a problem for some use cases
>
> What about this then? We identify whether the buffer is currently
> visible, and if it is, we temporarilly select that window while
> executing the code (restoring the original buffer and window points
> after we are done) I would be something like
>
> ```
>     (let ((window (get-buffer-window (maker-buffer ,marker) 'visible)))
>       (if window
>           (with-selected-window window
>             (save-excursion
>               (goto-char ,marker)
>               ,@body))
>         (with-current-buffer (marker-buffer ,marker)
>           (save-excursion
>             (goto-char ,marker)
>             ,@body))))
> ```

Will it solve the problem with ,@body somehow triggering window
configuration change?

My feeling is that all these complications are not going to solve
all possible problems with point changes. For example, there is point
adjustment on invisible text that might trigger on redisplay or other
things. The whole thing sounds to me like what we have with match data -
we need to be aware that various functions may alter match data and take
care to preserve it if we need to. Same with point position - functions
dealing with redisplay and window configurations may alter point
position, and that's something to be accounted for by the code calling
those functions.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Reply via email to