From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie 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 15:46:07 +0000 Message-ID: References: <83v8o0dtg3.fsf@gnu.org> <83pme8dp2r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31264"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii 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 16:46:38 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 1opWzm-0007x3-DB for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Oct 2022 16:46:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opWzO-0007Pl-KQ; Mon, 31 Oct 2022 11:46:14 -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 1opWzM-0007PW-Dz for emacs-devel@gnu.org; Mon, 31 Oct 2022 11:46:12 -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 ) id 1opWzK-0005zn-A4 for emacs-devel@gnu.org; Mon, 31 Oct 2022 11:46:12 -0400 Original-Received: (qmail 94584 invoked by uid 3782); 31 Oct 2022 16:46:07 +0100 Original-Received: from acm.muc.de (p4fe15da4.dip0.t-ipconnect.de [79.225.93.164]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 31 Oct 2022 16:46:07 +0100 Original-Received: (qmail 18912 invoked by uid 1000); 31 Oct 2022 15:46:07 -0000 Content-Disposition: inline In-Reply-To: <83pme8dp2r.fsf@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=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:298867 Archived-At: Hello, Eli. On Mon, Oct 31, 2022 at 16:50:52 +0200, Eli Zaretskii wrote: > > Date: Mon, 31 Oct 2022 14:32:12 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > Anyhow, I proposed buffer-point and set-buffer-point. They would be a > > lot faster than set-buffer followed by point and goto-char. Here is my > > first version of these. What do you think? > I'm not sure performance in a debugger is a reason good enough to add > 2 more primitives. The fact that we didn't need them until now should > tell us something, no? Well, I timed it. With 207 buffers, creating an alist of (buffer . buffere-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. It's probably moot, though, since the "slow" restoration only took 0.00137 seconds for all 207 buffers. 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. > Stefan, Lars, WDYT? > Anyway, a couple of minor comments: > > +DEFUN ("buffer-point", Fbuffer_point, Sbuffer_point, 1, 1, 0, > > + doc: /* Return the buffer point of BUFFER-OR-NAME. > > +The argument may be a buffer or the name of an existing buffer. */) > > + (Lisp_Object buffer_or_name) > 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. buffer.c was the first file that sprang to mind. It could easily be somewhere else, though. > > + return (make_fixnum (b->pt)); > 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. The whole idea of the new functions is to avoid having to switch buffers. > > + CHECK_FIXNUM_COERCE_MARKER (pos); > > + p = XFIXNUM (pos); > This is sub-optimal: a marker holds both character and byte position, > and you lose it here. Ignoring the byte position is only justified if > the marker belongs to the wrong buffer. And I need to check the marker's in the correct buffer, too. But thanks for the tip! > > + if (p < b->begv) p = b->begv; > > + if (p > b->zv) p = b->zv; > We have clip_to_bounds. And again, always use BUF_BEGV and BUF_ZV, > not literal references to members of struct buffer. I knew there was some sort of function, but couldn't think of the name, and couldn't find a way to search for it. ;-( > > + SET_PT (p); > We have SET_BUF_PT_BOTH. OK. That SET_PT was a mistake; it sets point in the current buffer, not the buffer that was the argument. But I take the point (no pun intended). If we've already got point_byte, there's no point calculating it all over again. Thanks! -- Alan Mackenzie (Nuremberg, Germany).