From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Alan Mackenzie <acm@muc.de>
Newsgroups: gmane.emacs.devel
Subject: Re: Edebug corrupting point in buffers.
Date: Thu, 3 Nov 2022 19:57:46 +0000
Message-ID: <Y2QdOpsEKPqBoSrC@ACM>
References: <83iljydh7e.fsf@gnu.org> <Y2EiK32B9lxLSFms@ACM>
 <838rkud9d5.fsf@gnu.org> <Y2FSHvmj2H8a5AS6@ACM>
 <83v8nybnuk.fsf@gnu.org> <Y2FWSoSCQnnY9en1@ACM>
 <83pme6bls8.fsf@gnu.org> <Y2JVzZNiWKx/W6KQ@ACM>
 <83mt99a223.fsf@gnu.org> <jwvy1sryhb3.fsf-monnier+emacs@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="25459"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
To: Stefan Monnier <monnier@iro.umontreal.ca>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 03 20:58:52 2022
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1oqgMV-0006Nj-N6
	for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 20:58:51 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1oqgLi-00014s-Lj; Thu, 03 Nov 2022 15:58:02 -0400
Original-Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acm@muc.de>) id 1oqgLf-000134-6D
 for emacs-devel@gnu.org; Thu, 03 Nov 2022 15:57:59 -0400
Original-Received: from mx3.muc.de ([193.149.48.5])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acm@muc.de>) id 1oqgLc-0001FP-KR
 for emacs-devel@gnu.org; Thu, 03 Nov 2022 15:57:58 -0400
Original-Received: (qmail 38689 invoked by uid 3782); 3 Nov 2022 20:57:48 +0100
Original-Received: from acm.muc.de (p4fe15d9a.dip0.t-ipconnect.de [79.225.93.154])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Thu, 03 Nov 2022 20:57:47 +0100
Original-Received: (qmail 9416 invoked by uid 1000); 3 Nov 2022 19:57:46 -0000
Content-Disposition: inline
In-Reply-To: <jwvy1sryhb3.fsf-monnier+emacs@gnu.org>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
X-Primary-Address: acm@muc.de
Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de;
 helo=mx3.muc.de
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Original-Sender: "Emacs-devel" <emacs-devel-bounces@gnu.org>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:299099
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/299099>

Hello, Stefan.

On Thu, Nov 03, 2022 at 15:29:38 -0400, Stefan Monnier wrote:
> Eli Zaretskii [2022-11-02 16:00:52] wrote:

> >> Date: Wed, 2 Nov 2022 11:34:37 +0000
> >> Cc: emacs-devel@gnu.org
> >> From: Alan Mackenzie <acm@muc.de>

> >> (i) Emacs -Q.
> >> (ii) On a single frame, arrange buffers *scratch*, test-edebug.el, and
> >>   some other substantial buffer, that I call emacs.README.
> >> (iii) Put point in emacs.README somewhere other than point-max.
> >> (iv) Instrument test-edebug for edebug with C-u C-M-x.
> >> (iv)a Put point into window *scratch*.
> >> (v) M-: (test-edebug).
> >> (vi) Step through test-edebug using the space key.
> >> (vii) Note that the second text insertion happens where point was in the
> >>   window, not at point-max.  This is the bug.

> > Yes, I see the problem, but setting edebug-save-windows to nil
> > eliminates it.  So I think we already have a solution for the rare
> > situations where this is an issue.

> 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.

The solution, were it practicable, would be to have only the command
loop or maybe redisplay copying WP to BP, and only just before the
window becomes the current place where the user might edit.

> 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.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).