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; we need buffer-point and set-buffer-point, perhaps. Date: Mon, 31 Oct 2022 13:33:36 -0400 Message-ID: References: <83v8o0dtg3.fsf@gnu.org> <83pme8dp2r.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="25200"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 31 18:34:27 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 1opYg7-0006Hl-2x for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Oct 2022 18:34:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opYfa-0004Oh-9B; Mon, 31 Oct 2022 13:33:54 -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 1opYfU-0004O5-M3 for emacs-devel@gnu.org; Mon, 31 Oct 2022 13:33:50 -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 1opYfT-0005Db-2v; Mon, 31 Oct 2022 13:33:48 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C661A80390; Mon, 31 Oct 2022 13:33:44 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0EDA580091; Mon, 31 Oct 2022 13:33:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667237619; bh=8aKyEgg3Zu0Qf8dFVDyez6mj+2VHcL/8m1N62ria5aw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FctDjXgOD57bbDpOzwzqwG0rCev3EjAm5hLhiEn5O1QLY8kGUjD2XGatry+XpN2Si vKANzG0FKx6XHTkRjD8lhUtbTAuHfenXchFTKV2NG/bRzwSkKXAsCQav4xUOu/nip5 JjI0PlvNucQHsQqqVHW/sBCaLFoPJkmDWx2YuYcUMzVoP3c3W8ox4SMjQCYS2ltKDk vhbE3SxfR6EorGPoU2pDp9e0bcxex+qYRat2rdQplNfEgsCmhZUwaitmmXRq8arqr6 u4i/MeNCVhuKLcu7xKgDJlTNS2wD8EKpzNbu/+ma5YXhGg/dYnwYDgHMlXib6hPQAa HtPW33AYCoteA== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CD09F12100E; Mon, 31 Oct 2022 13:33:38 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Mon, 31 Oct 2022 15:46:07 +0000") 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+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298878 Archived-At: [ Duh, sorry I saw this message too late. ] > Well, I timed it. With 207 buffers, creating an alist of (buffer . > buffer-point) with my new function was 17 times as fast as using > with-current-buffer and point. Restoring the buffer-points was > 8 times as fast with my new function. I actually expected worse than 17x. > It's probably moot, though, since the "slow" restoration only took > 0.00137 seconds for all 207 buffers. That's the main issue for me, yes. I mean, I regularly have more than 200 buffers in my Emacs sessions, but AFAICT the rest of the work performed by Edebug when it interrupts the execution of the main program will dwarf this anyway. I think the better way forward is to define `edebug--buffer-point` and `edebug--set-buffer-point` functions in `debug.el` for now. If at some point we can see that it's useful in other packages we can move those definitions elsewhere and remove their `edebug--` prefix. And if at some point they show up as a significant contribution in a CPU profile, *then* we can move them to C. > But on the other hand, these two functions feel like they ought to exist. > They could save a lot of clumsy programming with swapping the buffer, > just to get or set point. (with-current-buffer BUF (point)) and (with-current-buffer BUF (goto-char POS)) aren't that terribly verbose. >> Why not an optional argument to 'point'? And why in buffer.c and not >> in editfns.c? > I'm not sure what you mean by an optional argument, here. IIUC he's suggesting to redefine `point` to take an optional argument (and merge it with `buffer-point`). >> Please never-ever use b->pt etc. directly. We have BUF_PT and other >> macros for that, and for a good reason. > BUF_PT and friends work specifically on current_buffer. No, that's `PT`. `BUF_PT` takes a buffer argument. Stefan