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:19:34 -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="36228"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Alan Mackenzie , 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 18:20:50 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 1opYSw-0009Fc-F0 for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Oct 2022 18:20:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opYSA-0004TC-AD; Mon, 31 Oct 2022 13:20: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 ) id 1opYRx-0004RR-Dc for emacs-devel@gnu.org; Mon, 31 Oct 2022 13:19: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 1opYRt-0008HI-RO; Mon, 31 Oct 2022 13:19:47 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 09BE380898; Mon, 31 Oct 2022 13:19:43 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5CEDA80091; Mon, 31 Oct 2022 13:19:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667236781; bh=fn6WU3yAYi2T+EIaZc8nmF1XP0tt20ag/XfE2MwsTo8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=A8ZJjXeQlc9OTqqO+E68Tbuw3Oh+Z6vn2vdQizhhe6hXu52Q9uQJ9sovLqFyrG2BR dHU51lgVr9w4Mq2k+12LLeDIgKlpV/yJ2yukiUrFWnt6fWtWUHGeBq/qVavzMrzxLM xstIDM2BRqKxakrfirf8mx0gRPXtOfq2+sJaPfiLb2wUAOG3NpuUCIRUAWpk5Bma4C pytH+vgTUaz2ohSvwfGjtE/8PNY8kUcxVBm5oAxjN+UJCKoa4dwgPplxgN42xA4sUz 8GoBGN6m6EUx+Gc6iF48m8FE5nSg82KGic137rkDdIPD1IQTRMm/EWe7QvhUcsr7Hv CfUYDVa4cJEjQ== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 449A81206F6; Mon, 31 Oct 2022 13:19:41 -0400 (EDT) In-Reply-To: <83pme8dp2r.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 31 Oct 2022 16:50:52 +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+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298875 Archived-At: >> 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? > Stefan, Lars, WDYT? I'd be interested to see numbers showing that it's indeed "too costly" to just use `set-buffer`, before we add such primitives. > Anyway, a couple of minor comments: AFAIK `get-buffer` will return non-nil when passed a killed buffer, so I think those two functions currently would misbehave when passed a killed buffer. >> +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'? That would be a lot more invasive, so hard to justify for a functionality that we're not even sure we want to have. > And why in buffer.c and not in editfns.c? [ Truth be told, I don't really understand how these are split :-( ] >> + 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. I suspect the performance impact is negligible compared to what it would cost using `set-buffer`. Since we're not convinced the cost of `set-buffer` is high enough to justify `set-buffer-point`, I wouldn't worry about optimizing the case where the arg is a marker. Stefan