>> I wish Someone⢠could dig into the problem further and find the source
>> of the problem and an actual fix, but indeed, this seems like a fair
>> workaround in the mean time.
>
> I think I said something about this earlier on in the thread. The cause
> seems to be that random bits of software wrongly consider it their
> business to overwrite the buffer point with a window point.
>
> Amongst these bits of software are select-window,
> set-window-configuration, and our very own edebug-set-buffer-points
> (triggered by the option edebug-save-displayed-buffer-points). I think
> there are many more.
This characterization is a bit too vague and open-ended to be
actionable, sadly. I was thinking of "the source of the problem" for
the specific case you described earlier in the bug-report (i.e. one we
can conveniently reproduce). Admittedly, fixing this one case may
not fix all cases, but will at least get us closer.
>> Maybe a good short term "fix/workaround" is to change the implementation
>> of `edebug-save-windows` so that in addition to the windows's info it
>> also saves&restores the buffer-point of those buffers displayed in the
>> saved windows.
> My first patch did something like this. It saved the buffer points of
> all buffers, then restored it in buffers selected by the user. This
> patch was rejected (and I think rightly so) for being too clumsy to use.
I was thinking that by limiting the saved&restored buffer-points to
those displayed in the saved windows, we'd make it more "automatic" than
your patch.
Stefan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4