From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing. Date: Sat, 06 May 2023 09:26:40 +0300 Message-ID: <83mt2igelb.fsf@gnu.org> References: <166939872890.18950.12581667269687468681@vcs2.savannah.gnu.org> <83wn4le8s3.fsf@gnu.org> <0f053182b02103503c26@heytings.org> <83pmaccnz7.fsf@gnu.org> <0f053182b04357300cb1@heytings.org> <83lel0chku.fsf@gnu.org> <0f053182b00a59a41caa@heytings.org> <835yc3cdhk.fsf@gnu.org> <9e9ed8043fc8bfe49bfe@heytings.org> <83h6vnaukn.fsf@gnu.org> <9e9ed8043f4ff9316461@heytings.org> <83k00exj56.fsf@gnu.org> <10ececa33f0a4af46fd2@heytings.org> <83edp3zwjk.fsf@gnu.org> <83r0t3y6yy.fsf@gnu.org> <83lejby3nk.fsf@gnu.org> <83h6tzy19k.fsf@gnu.org> <83bkk6yicv.fsf@gnu.org> <83jzxoll20.fsf@gnu.org> <221c67168567a20a89c1@heytings.org> <834joqiyuq.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15115"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 06 08:26:09 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pvBMu-0003fM-Ru for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 May 2023 08:26:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvBMp-00023J-MG; Sat, 06 May 2023 02:26:03 -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 1pvBMp-000237-0g for bug-gnu-emacs@gnu.org; Sat, 06 May 2023 02:26:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pvBMo-0002XF-Oe for bug-gnu-emacs@gnu.org; Sat, 06 May 2023 02:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pvBMo-00027D-Ab for bug-gnu-emacs@gnu.org; Sat, 06 May 2023 02:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 May 2023 06:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.16833543548114 (code B ref 56682); Sat, 06 May 2023 06:26:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 6 May 2023 06:25:54 +0000 Original-Received: from localhost ([127.0.0.1]:58061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvBMg-00026m-0e for submit@debbugs.gnu.org; Sat, 06 May 2023 02:25:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvBMd-00026a-TJ for 56682@debbugs.gnu.org; Sat, 06 May 2023 02:25:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvBMX-0002Nr-Q6; Sat, 06 May 2023 02:25:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dOG8k6vDzroKY0jGtfo0/TDNR0pZJld+cFNvuvUpS5A=; b=Hvhsfwu4bQhE KUScciz57z84NHghUcC7t6cmX66hbNsV8mwUXE5eVoLTNMJZtvT64UW9kFblrFKQRgguFPq1fDPKX Kh6PE3tq/VMCyMdmZOLJsbDEHX9CdSNNR6yxjLEs7QFrxrRXdccji3emO4K2YJ4diK4wEmr0dvvDX bxMJRaXliVWCi+wLxyrJzgya28tOiVG43MdSi0XgAzExsHXDuvKLhJVZIniakZrXLSNTXazagoNyy iRnLP4ETqkXlGhZysYoS0hG67np5mMqQYEr3XxgyYkAi7sXw71kMnBtoj/a5uiuY+On62Y/fUSu6g uKKMrdZA6ThFwKYQYu4odA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvBMX-0000a0-64; Sat, 06 May 2023 02:25:45 -0400 In-Reply-To: (message from Gregory Heytings on Fri, 05 May 2023 21:29:16 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261160 Archived-At: > Date: Fri, 05 May 2023 21:29:16 +0000 > From: Gregory Heytings > cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca > > >> + struct Lisp_Marker *begv > >> + = labeled_restrictions_get_bound (buf, true, true); > >> + struct Lisp_Marker *zv > >> + = labeled_restrictions_get_bound (buf, false, true); > > > > Why the strange design of having a function return a pointer to a > > 'struct Lisp_Marker'? why not return the marker itself instead? (I > > realize that this was so in the code we already have, but I still don't > > understand why you did it that way, and prefer that function to return a > > marker instead.) > > > > Good question. You mean that it would have been better to return a > Lisp_Object, right? I don't recall exactly, I think it was because in the > calls to SET_BUF_BEGV_BOTH/SET_BUF_ZV_BOTH (which are the only places > where the return value of labeled_restrictions_get_bound are used) one can > use the pointer to a struct Lisp_Marker immediately, whereas a call to > XMARKER would have been necessary if a Lisp_Object had been used. I'd prefer to use a marker there, but that can be a separate changeset. > > Is it okay for this function to return a position > POS, its input? > > Unless I misunderstood something, it cannot, because find_newline1 is > called with end = pos and end_byte = pos_bytepos. The logic is quite convoluted, so I think we should have an assertion about this before the function returns, because callers depend on the returned position not to exceed POS, AFAICT. Please install this after fixing those nits, and please ack this time after installing. Thanks.