From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Edebug corrupting point in buffers. Date: Thu, 03 Nov 2022 16:39:23 -0400 Message-ID: References: <83wn8fcgvd.fsf@gnu.org> <83iljydh7e.fsf@gnu.org> <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> <83mt99a223.fsf@gnu.org> <834jvf7ruw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2812"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 03 21:41:02 2022 Return-path: 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 ) id 1oqh1K-0000Ze-D5 for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 21:41:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqgzw-0001zs-BG; Thu, 03 Nov 2022 16:39:36 -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 ) id 1oqgzu-0001zf-3M for emacs-devel@gnu.org; Thu, 03 Nov 2022 16:39:34 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqgzp-0007Ta-K0; Thu, 03 Nov 2022 16:39:33 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6DA1E441D87; Thu, 3 Nov 2022 16:39:27 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 378E5441D8D; Thu, 3 Nov 2022 16:39:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667507966; bh=OGPpbvCOMC7RPaskEr7GJhLBLVEXkmEy6Honvp07E2o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TBg0pnfahJTGPfIDnR7m2OtKzUNrD4+G8ecBPYS7btuMlon3uiIT38UaPiOmW1Utd zfZMRfSMbvjOEwM5czdJMrv5ZtZgbNW0iqU5zZbZEPomBjKT64jO01TmaQowJ/B3Yv ANgnEfX6IJDdEVon6BEiiSncLsLgVTW0IE6zMB9sj1j0vgZxhojLGUm6ghuAGPi9Er xDd9Ak6++n9nRGSA2Ho9QzOkeCxnGF/og2EoeyaBTclb+SX16lx9VZMnCAlRyuIWtP IvvRZSOLhg5uN6QXmvFBx/tIfoXL2MNlZctylumD0GKsHcG4suXntrxvXf+0V+ZReE Er6yE1G0m5zqA== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 14159120753; Thu, 3 Nov 2022 16:39:26 -0400 (EDT) In-Reply-To: <834jvf7ruw.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 03 Nov 2022 21:36:23 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299104 Archived-At: > I think before digging into the reasons, we should decide what kind of > behavior we would consider "correct" and/or "useful" in the relevant > use cases with Edebug. The answer is not easy, because AFAIU Edebug > cannot easily know which window(s) and which buffer(s) are affected by > the program being debugged. If we follow the model or "traditional debuggers" which run in a separate process, then it would make a lot of sense for Edebug to save&restore points in all the buffers that it (Edebug) touches, so as to better preserve the behavior we get when Edebug is not invoked. For that Edebug doesn't need to know which buffers are affected by the program being debugged, it just needs to know the buffers that it (itself) affects, which doesn't sound impractically difficult. Stefan