A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00107.html below:

Re: Edebug corrupting point in buffers.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Stefan Monnier Subject: Re: Edebug corrupting point in buffers. Date: Wed, 02 Nov 2022 09:12:57 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) 
>> Really?  My reading of the code:
>
>>            /* As documented in Fcurrent_window_configuration, don't
>>               restore the location of point in the buffer which was
>>               current when the window configuration was recorded.  */
>>            if (!EQ (p->buffer, new_current_buffer)
>>                && XBUFFER (p->buffer) == current_buffer)
>>              Fgoto_char (w->pointm);
>
>> is that it's done only for the current buffer and only if it's different
>> from the "to be current buffer".
>
>> Am I missing something?
>
> Hmm.  I spent a great deal of yesterday asserting false things, then
> apologising for them.  The above was the last such false thing, for which
> I also apologise.

If we had to apologize every time we misread/misunderstood code, we'd
never get anywhere :-)

> There's clearly been a lot of confusion about window/buffer point over
> the decades which shows in the number of places such changes in buffer
> point occur, and the bugs which have sometimes resulted, like the one
> you cite above.

This is arguably one of the most subtle/delicate/complex aspect of
ELisp's semantics, indeed.


        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