From unknown Wed Jun 18 00:26:14 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#16413 <16413@debbugs.gnu.org> To: bug#16413 <16413@debbugs.gnu.org> Subject: Status: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Reply-To: bug#16413 <16413@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:26:14 +0000 retitle 16413 24.3.50; Inconsistent behavior of text property functions in = narrowed buffer reassign 16413 emacs submitter 16413 Nathan Trapuzzano severity 16413 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 10 22:06:16 2014 Received: (at submit) by debbugs.gnu.org; 11 Jan 2014 03:06:16 +0000 Received: from localhost ([127.0.0.1]:45855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1ots-00089S-6m for submit@debbugs.gnu.org; Fri, 10 Jan 2014 22:06:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38079) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1otl-000897-QR for submit@debbugs.gnu.org; Fri, 10 Jan 2014 22:06:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1otd-0006Do-IA for submit@debbugs.gnu.org; Fri, 10 Jan 2014 22:06:09 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1otd-0006Dj-Fj for submit@debbugs.gnu.org; Fri, 10 Jan 2014 22:06:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1otW-00022X-I7 for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 22:06:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1otM-0006By-IB for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 22:05:54 -0500 Received: from alt-proxy13.mail.unifiedlayer.com ([67.222.34.81]:38111) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1W1otM-0006Br-7x for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 22:05:44 -0500 Received: (qmail 10121 invoked by uid 0); 11 Jan 2014 03:05:42 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy18.mail.unifiedlayer.com with SMTP; 11 Jan 2014 03:05:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=ExiW0GOHYFzYCUx7FMdjBqPs6eZJ8pWBk8/xWLtMqYk=; b=BsI9pGji0gQ5Q+TvL/Fc7dIKdTjs4NYurXMXyT5Rvo2B4mR/uAwpWbaUmsLE/juHI25G2P8KeisY/ewuc8bVqmjqZdNtyAT7+TaFTlkTLsLoaJOAKWmpg7Sf46asCFkP; Received: from [50.90.253.209] (port=60474 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W1otJ-0006ku-OW for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 20:05:41 -0700 From: Nathan Trapuzzano To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Date: Fri, 10 Jan 2014 22:05:38 -0500 Message-ID: <87mwj3fcal.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) The various functions for examining text properties behave unintuitively and incosistently at (point-max) on narrowed buffers. Rather than returning `nil', they return the prop(s) of the text at (point-max), even though the text is not actually visible in the buffer, due to narrowing. By contrast, `char-after' always returns `nil' when passed (point-max). It seems to me the text property functions should also return `nil', as they do at (eobp) on widened buffers. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 10 23:06:36 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 04:06:36 +0000 Received: from localhost ([127.0.0.1]:45903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1pqG-0001XW-7p for submit@debbugs.gnu.org; Fri, 10 Jan 2014 23:06:36 -0500 Received: from dancol.org ([96.126.100.184]:59478) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1pqD-0001XL-Ho for 16413@debbugs.gnu.org; Fri, 10 Jan 2014 23:06:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=4iz2HEPvRROjuqACXxDsN7dwciqwJny2Xtgcx+swfRg=; b=gVEEuj4xKQaCToF+EtZU1hGV//UoRLuckHqNSAflXr/z8Ux9Sedze4ApMrszS0jI2SeYvr1GNsrEIlJx5QL1oipcf8K7y3xZEk8TajadowzGXZH/Lex2bpkc6DkYmEMnb7yuD8SU3cwej94QISoH4++8vXWHjBkjGRo0wvTjIO45CIEFDztC+OdiakQynIBGQgAzYZcQyzgM1kPFu/iOvbKvKh2Lj23rPuLeQZNVmhzQNUdSFIJ7ErfI9gLjCYnDauW+FKks/Lnr/tND30sIwtJntlsVzIsscap1b2t7oiddkmc6dDUC6BR10/kSfBan56kZn5s8r48OcnrThxUgPA==; Received: from [173.252.71.189] (helo=[172.20.16.184]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W1pqC-0001SI-2E; Fri, 10 Jan 2014 20:06:32 -0800 Message-ID: <52D0C30D.9050305@dancol.org> Date: Fri, 10 Jan 2014 20:05:33 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Trapuzzano , 16413@debbugs.gnu.org Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> In-Reply-To: <87mwj3fcal.fsf@nbtrap.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 16413 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 01/10/2014 07:05 PM, Nathan Trapuzzano wrote: > The various functions for examining text properties behave unintuitively > and incosistently at (point-max) on narrowed buffers. Rather than > returning `nil', they return the prop(s) of the text at (point-max), > even though the text is not actually visible in the buffer, due to > narrowing. By contrast, `char-after' always returns `nil' when passed > (point-max). It seems to me the text property functions should also > return `nil', as they do at (eobp) on widened buffers. I agree that this behavior is unintuitive, but I wonder whether we can fix this bug without breaking existing elisp. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 10 23:10:31 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 04:10:31 +0000 Received: from localhost ([127.0.0.1]:45907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1pu2-0001ez-Rr for submit@debbugs.gnu.org; Fri, 10 Jan 2014 23:10:31 -0500 Received: from dancol.org ([96.126.100.184]:59484) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1ptz-0001er-WF for 16413@debbugs.gnu.org; Fri, 10 Jan 2014 23:10:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=jNW8gaWcz8GOCeEXo7bBBJWDZlSiLdyNgF3K7dXTrjo=; b=VBJsUN+FPD1ypx53djeDFlRVM6fBrpV3xsih2QNvNpuU2KhN9cVYDJBRe81UAMI5tbBKsqd1jg19AhLxR+yo5mBSP44YZq4lIcX4c3dT3eldmNFRDSzQ+37K+9A/IM7qCTW21Tcszxwxue/lXigpzG+pkwR8DUO2un85OLzZjuq1vzQXjCbZr2jj+pnKlloCGz73DWTYIGIukRgSIyX+NEt+ZcZBZBhO/pBYov9+EpKVjhcMojOFrNECwigvMELP2e1lPjBoSoIpHncYcdxfviDi3aHEWzBH11vGMNO93rJrr8zcUuTDugwu9toRwhNz6pA+ftS2ZBNqw/2+tW/IoQ==; Received: from [173.252.71.189] (helo=[172.20.16.184]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W1ptz-0001Su-Gq; Fri, 10 Jan 2014 20:10:27 -0800 Message-ID: <52D0C401.90208@dancol.org> Date: Fri, 10 Jan 2014 20:09:37 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Trapuzzano , 16413@debbugs.gnu.org Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> In-Reply-To: <52D0C30D.9050305@dancol.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 16413 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 01/10/2014 08:05 PM, Daniel Colascione wrote: > On 01/10/2014 07:05 PM, Nathan Trapuzzano wrote: >> The various functions for examining text properties behave unintuitively >> and incosistently at (point-max) on narrowed buffers. Rather than >> returning `nil', they return the prop(s) of the text at (point-max), >> even though the text is not actually visible in the buffer, due to >> narrowing. By contrast, `char-after' always returns `nil' when passed >> (point-max). It seems to me the text property functions should also >> return `nil', as they do at (eobp) on widened buffers. > > I agree that this behavior is unintuitive, but I wonder whether we can > fix this bug without breaking existing elisp. Which functions break, exactly? The following test passes. (ert-deftest text-property-narrowing () "Test that text properties outside narrowed buffer are invisible" (with-temp-buffer (insert " ") (put-text-property (1- (point-max)) (point-max) 'foo 'bar) (should (eq (get-text-property (1- (point-max)) 'foo) 'bar)) (narrow-to-region (point-min) (1- (point-max))) (should (null (get-text-property (1- (point-max)) 'foo))))) From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 03:02:27 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 08:02:27 +0000 Received: from localhost ([127.0.0.1]:45984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tWU-0008HI-JH for submit@debbugs.gnu.org; Sat, 11 Jan 2014 03:02:27 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:53017) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tWO-0008H2-Gt for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 03:02:22 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZ8007008TJO300@a-mtaout22.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 10:02:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ8007PO8ZUCV90@a-mtaout22.012.net.il>; Sat, 11 Jan 2014 10:02:18 +0200 (IST) Date: Sat, 11 Jan 2014 10:01:59 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <52D0C30D.9050305@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <8361praqvc.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: nbtrap@nbtrap.com, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 10 Jan 2014 20:05:33 -0800 > From: Daniel Colascione > > On 01/10/2014 07:05 PM, Nathan Trapuzzano wrote: > > The various functions for examining text properties behave unintuitively > > and incosistently at (point-max) on narrowed buffers. Rather than > > returning `nil', they return the prop(s) of the text at (point-max), > > even though the text is not actually visible in the buffer, due to > > narrowing. By contrast, `char-after' always returns `nil' when passed > > (point-max). It seems to me the text property functions should also > > return `nil', as they do at (eobp) on widened buffers. > > I agree that this behavior is unintuitive, but I wonder whether we can > fix this bug without breaking existing elisp. I don't even agree it's not intuitive: in the eob case there's nothing at point-max, while in a narrowed buffer there's a character there. Narrowing is not documented to make the text outside the region to magically disappear, it just prevents point from moving there. Nathan, could you show an example where this hurts anything besides intuition? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 03:03:52 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 08:03:53 +0000 Received: from localhost ([127.0.0.1]:45988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tXs-0008Jv-H3 for submit@debbugs.gnu.org; Sat, 11 Jan 2014 03:03:52 -0500 Received: from dancol.org ([96.126.100.184]:60168) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tXq-0008Jk-Bj for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 03:03:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qRUScgWszD6/BymfCIaKhrTbjeG8DhzdoZNtlXN96eo=; b=I84KDsSJp6Zev60OSEaYpJYmnIfVilLOpUHmK2OmhEDY8obZw0o9efrTmhney1ziJYS0Za2fRX3HUDCyADDczyIjPYm/0qCYMn7Cbag0j5ILWsA+gMWRfq/NztDMPPk9BU9/1PpGdmpBTbp4WTQeLPfjlQ+W+NiEzF5Ay84FLFv5OJqzDu79CLhdNrwRZf5PsaAPXUzeoDwofMAZjavT1iT7ta6NO0hThSdYxTn12sSi5Z4MvsI9GRzuY0esxTk1P/KtwJeW7DBl27CLZ7RBa/wxXjoa7cflv64JmHCrE/qboXkERUZIh8WugEK9uFf7J3CyMmDoM+uY15dJqwRPRQ==; Received: from [24.16.209.135] (helo=[192.168.1.101]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W1tXn-0001q7-Vd; Sat, 11 Jan 2014 00:03:48 -0800 Message-ID: <52D0FADE.8060605@dancol.org> Date: Sat, 11 Jan 2014 00:03:42 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> In-Reply-To: <8361praqvc.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 16413 Cc: nbtrap@nbtrap.com, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 01/11/2014 12:01 AM, Eli Zaretskii wrote: >> Date: Fri, 10 Jan 2014 20:05:33 -0800 >> From: Daniel Colascione >> >> On 01/10/2014 07:05 PM, Nathan Trapuzzano wrote: >>> The various functions for examining text properties behave unintuitively >>> and incosistently at (point-max) on narrowed buffers. Rather than >>> returning `nil', they return the prop(s) of the text at (point-max), >>> even though the text is not actually visible in the buffer, due to >>> narrowing. By contrast, `char-after' always returns `nil' when passed >>> (point-max). It seems to me the text property functions should also >>> return `nil', as they do at (eobp) on widened buffers. >> >> I agree that this behavior is unintuitive, but I wonder whether we can >> fix this bug without breaking existing elisp. > > I don't even agree it's not intuitive: in the eob case there's nothing > at point-max, while in a narrowed buffer there's a character there. > Narrowing is not documented to make the text outside the region to > magically disappear, it just prevents point from moving there. Narrowing *is* generally useful for treating part of a buffer as a consistent unit, though, especially when that part is syntactically different from the rest of the buffer. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 03:13:21 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 08:13:21 +0000 Received: from localhost ([127.0.0.1]:45993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1th2-00008Q-Kf for submit@debbugs.gnu.org; Sat, 11 Jan 2014 03:13:21 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:48864) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tgz-00008F-13 for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 03:13:18 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0MZ800N008U8IF00@mtaout29.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 10:13:57 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ8000GF9J8HF00@mtaout29.012.net.il>; Sat, 11 Jan 2014 10:13:57 +0200 (IST) Date: Sat, 11 Jan 2014 10:12:57 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <52D0FADE.8060605@dancol.org> To: Daniel Colascione Message-id: <834n5baqd2.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: nbtrap@nbtrap.com, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 11 Jan 2014 00:03:42 -0800 > From: Daniel Colascione > CC: nbtrap@nbtrap.com, 16413@debbugs.gnu.org > > Narrowing *is* generally useful for treating part of a buffer as a > consistent unit, though, especially when that part is syntactically > different from the rest of the buffer. Not sure what you mean by "consistent unit". >From the ELisp manual: 30.4 Narrowing ============== "Narrowing" means limiting the text addressable by Emacs editing commands to a limited range of characters in a buffer. The text that remains addressable is called the "accessible portion" of the buffer. Perceiving and treating narrowing as something beyond that can, indeed, cause conceptual and practical difficulties. For example, narrowing the buffer in the middle of bidirectional context will most of the time completely screw up the text on display. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 03:17:29 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 08:17:29 +0000 Received: from localhost ([127.0.0.1]:45998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tl2-0000Fl-MX for submit@debbugs.gnu.org; Sat, 11 Jan 2014 03:17:28 -0500 Received: from dancol.org ([96.126.100.184]:60216) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tl1-0000Fd-6F for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 03:17:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=btYlLcWFSxBIq2nmsnRvPWFSPSPO3jncNanAIE/g57g=; b=auA6SneXHfQ8TuCzNFuNYoDGBy/x7d8VAkWoewhdgDfy9LMSQNxxHpgg5C/hJNXmyX0KcEm4ZJslwwm9b/tt/6+NzXzq0fN85lDfosY70rBUxK2OB/3G43iBVia5pO2xrjkTRBA1mc/jasXs0pnyDSjHEB1e/lVyevmF254P3R90pcAcpgzK2BghF16DEE+2WH+EVCMQFK+PFSBRwi+CBrfBXm8OYuuIiYGGDhqE2YggLiNbUd2xjSFlCuyf/jfgq5cwyOp3fmWcJk/D8dzT7RYEvuU/aNEZL4euEkGmzCinhd+pkbPi/mi10NiWx5gxAIV1OS5lUs5Aat95CeRDkg==; Received: from [24.16.209.135] (helo=[192.168.1.101]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W1tkz-0001rn-Lo; Sat, 11 Jan 2014 00:17:25 -0800 Message-ID: <52D0FE0F.40907@dancol.org> Date: Sat, 11 Jan 2014 00:17:19 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <834n5baqd2.fsf@gnu.org> In-Reply-To: <834n5baqd2.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 16413 Cc: nbtrap@nbtrap.com, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 01/11/2014 12:12 AM, Eli Zaretskii wrote: >> Date: Sat, 11 Jan 2014 00:03:42 -0800 >> From: Daniel Colascione >> CC: nbtrap@nbtrap.com, 16413@debbugs.gnu.org >> >> Narrowing *is* generally useful for treating part of a buffer as a >> consistent unit, though, especially when that part is syntactically >> different from the rest of the buffer. > > Not sure what you mean by "consistent unit". Narrowing is useful as a poor man's mmm-mode, among other things, and programatically, it's useful for parsing delimited constructs (where we can just narrow to the region of interest). Narrowing hasn't been a purely visual hint, and plenty of lisp-level functions treat the edges of the accessible portion of the buffer as real buffer ends. Since this abstraction almost completely works today, we should try to fill any remaining gaps. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 03:28:17 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 08:28:17 +0000 Received: from localhost ([127.0.0.1]:46002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tvU-0000Yr-Pr for submit@debbugs.gnu.org; Sat, 11 Jan 2014 03:28:17 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:52852) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1tvR-0000Ye-Sx for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 03:28:15 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZ8002009ZLS000@a-mtaout20.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 10:28:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ8002T1A70JA80@a-mtaout20.012.net.il>; Sat, 11 Jan 2014 10:28:12 +0200 (IST) Date: Sat, 11 Jan 2014 10:27:53 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <52D0FE0F.40907@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <8338kuc48m.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <834n5baqd2.fsf@gnu.org> <52D0FE0F.40907@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: nbtrap@nbtrap.com, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 11 Jan 2014 00:17:19 -0800 > From: Daniel Colascione > CC: nbtrap@nbtrap.com, 16413@debbugs.gnu.org > > Narrowing is useful as a poor man's mmm-mode, among other things, and > programatically, it's useful for parsing delimited constructs (where we > can just narrow to the region of interest). Narrowing hasn't been a > purely visual hint, and plenty of lisp-level functions treat the edges > of the accessible portion of the buffer as real buffer ends. Since this > abstraction almost completely works today, we should try to fill any > remaining gaps. You will find this not an easy task, I'm afraid. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 07:20:22 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 12:20:22 +0000 Received: from localhost ([127.0.0.1]:46072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1xY5-0007Bj-Lt for submit@debbugs.gnu.org; Sat, 11 Jan 2014 07:20:22 -0500 Received: from oproxy1-pub.mail.unifiedlayer.com ([66.147.249.253]:47224) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W1xY2-0007BX-W6 for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 07:20:20 -0500 Received: (qmail 11297 invoked by uid 0); 11 Jan 2014 12:20:13 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy20.mail.unifiedlayer.com with SMTP; 11 Jan 2014 12:20:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=4W8mnFN65we/JyPGV1dCxXnM896lVaMZEvtNJ+thhTE=; b=d4ekmCpQ20IV3xdzyi/G3GmerM6wT1/m0/biEAsEgBq7N2aztH0ze60t09CEw0t7bRJBfwch6Eve1KL2O7EovlnkyXG3RfaBfEpCiBCg+LKfE5ZzFdFmW1rZNEK9jkND; Received: from [50.90.253.209] (port=33150 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W1xXx-0000dr-Ml; Sat, 11 Jan 2014 05:20:13 -0700 From: Nathan Trapuzzano To: Daniel Colascione Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <52D0C401.90208@dancol.org> Date: Sat, 11 Jan 2014 07:20:10 -0500 In-Reply-To: <52D0C401.90208@dancol.org> (Daniel Colascione's message of "Fri, 10 Jan 2014 20:09:37 -0800") Message-ID: <87eh4e677p.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Daniel Colascione writes: > Which functions break, exactly? The following test passes. > > (ert-deftest text-property-narrowing () > "Test that text properties outside narrowed buffer are invisible" > (with-temp-buffer > (insert " ") > (put-text-property (1- (point-max)) (point-max) 'foo 'bar) > (should (eq (get-text-property (1- (point-max)) 'foo) 'bar)) > (narrow-to-region (point-min) (1- (point-max))) > (should (null (get-text-property (1- (point-max)) 'foo))))) Those tests are looking at (1- (point-max)). I'm talking about (point-max). Functions that I know to be problematic include: get-text-property text-properties-at previous-single-property-change But I would geuss the problem extends to all text property fetch/search functions. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 07:24:39 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 12:24:39 +0000 Received: from localhost ([127.0.0.1]:46078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1xcE-0007J9-Nd for submit@debbugs.gnu.org; Sat, 11 Jan 2014 07:24:39 -0500 Received: from alt-proxy6.mail.unifiedlayer.com ([66.147.245.65]:53166) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W1xcB-0007Ix-BV for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 07:24:36 -0500 Received: (qmail 8865 invoked by uid 0); 11 Jan 2014 12:24:33 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy14.mail.unifiedlayer.com with SMTP; 11 Jan 2014 12:24:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=ciuhk1H8KWpr0mZ+w8i6xJVWffl3A/+J4SXX09PgFCQ=; b=cvGshx4z1HgzfQShzovlI7ximq91blqI5NKGlH1xjvJQKQC02zlewyU6lut3o+W+5Dbgbvfppx4dQ7WOCDHuIq0quHgrugbBw1Q5YcyUmNG5yGCjEwshP6cvMysATHat; Received: from [50.90.253.209] (port=33164 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W1xc9-0003Xn-FK; Sat, 11 Jan 2014 05:24:33 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> Date: Sat, 11 Jan 2014 07:24:30 -0500 In-Reply-To: <8361praqvc.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 10:01:59 +0200") Message-ID: <87a9f2670h.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: Daniel Colascione , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > I don't even agree it's not intuitive: in the eob case there's nothing > at point-max, while in a narrowed buffer there's a character there. > Narrowing is not documented to make the text outside the region to > magically disappear, it just prevents point from moving there. > > Nathan, could you show an example where this hurts anything besides > intuition? It's unintuitive or at least inconsistent because other functions (e.g. `char-after') treat the high edge of a narrowed buffer as though it were the actual end of the buffer. For an example of where this is problematic, look at the patch I submitted last night on this list. I was patching functions that use the text property search functions and had to make a special case for where point is at (point-max) and the buffer is narrowed. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 08:06:05 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 13:06:05 +0000 Received: from localhost ([127.0.0.1]:46130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1yGK-0001Cp-KE for submit@debbugs.gnu.org; Sat, 11 Jan 2014 08:06:05 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:54827) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1yGH-0001CM-T4 for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 08:06:03 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0MZ800L00LYURD00@mtaout29.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 15:06:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ800LTRN356C30@mtaout29.012.net.il>; Sat, 11 Jan 2014 15:06:41 +0200 (IST) Date: Sat, 11 Jan 2014 15:05:42 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87a9f2670h.fsf@nbtrap.com> To: Nathan Trapuzzano Message-id: <83vbxqact5.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Nathan Trapuzzano > Cc: Daniel Colascione , 16413@debbugs.gnu.org > Date: Sat, 11 Jan 2014 07:24:30 -0500 > > For an example of where this is problematic, look at the patch I > submitted last night on this list. I was patching functions that use > the text property search functions and had to make a special case for > where point is at (point-max) and the buffer is narrowed. point-max is and will always be a special case. There's no way around that. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 08:09:21 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 13:09:21 +0000 Received: from localhost ([127.0.0.1]:46134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1yJU-0001J2-M6 for submit@debbugs.gnu.org; Sat, 11 Jan 2014 08:09:21 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:45472) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1yJR-0001Ip-OP for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 08:09:18 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MZ800D00MLFRD00@a-mtaout21.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 15:09:16 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ800DO3N7GQR50@a-mtaout21.012.net.il>; Sat, 11 Jan 2014 15:09:16 +0200 (IST) Date: Sat, 11 Jan 2014 15:08:58 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87eh4e677p.fsf@nbtrap.com> X-012-Sender: halo1@inter.net.il To: Nathan Trapuzzano Message-id: <83txdaacnp.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <52D0C401.90208@dancol.org> <87eh4e677p.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Functions that I know to be problematic include: > > get-text-property > text-properties-at > previous-single-property-change The first two are low-level primitives that explicitly ignore the narrowing; don't use them if you want them to be limited to the narrowed region. The last one should simply returns the search limit if it hits the beginning of the narrowing, so I'm not sure why it is in this list. > But I would geuss the problem extends to all text property fetch/search > functions. That guess is wrong: functions that search for next/previous property changes stop at the end of the narrowed region. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 08:52:33 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 13:52:33 +0000 Received: from localhost ([127.0.0.1]:46157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1yzI-0002YT-Tr for submit@debbugs.gnu.org; Sat, 11 Jan 2014 08:52:33 -0500 Received: from oproxy9-pub.mail.unifiedlayer.com ([69.89.24.6]:47737) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W1yzF-0002YG-VG for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 08:52:30 -0500 Received: (qmail 1356 invoked by uid 0); 11 Jan 2014 13:53:24 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy9.mail.unifiedlayer.com with SMTP; 11 Jan 2014 13:53:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=lZ07UvlDjYkZkia3vJ642EnQ/IvoOnS6BMKhadL1/B8=; b=H+0yXC2rlrj/FcpeRLZqbxRy/PAUOqZIkn9w8011NgPGGKMo0PGypJHtX5kYePThwUi2sfnO7BBeKsn0tK8ilKRddOs1fjiFKCcwX/fOzhQFboISGWh0VuWJfem4TQZq; Received: from [50.90.253.209] (port=33538 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W1yzD-0003vh-1c; Sat, 11 Jan 2014 06:52:27 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <52D0C401.90208@dancol.org> <87eh4e677p.fsf@nbtrap.com> <83txdaacnp.fsf@gnu.org> Date: Sat, 11 Jan 2014 08:52:23 -0500 In-Reply-To: <83txdaacnp.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 15:08:58 +0200") Message-ID: <87eh4e1v8o.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> Functions that I know to be problematic include: >> >> get-text-property >> text-properties-at >> previous-single-property-change > > The first two are low-level primitives that explicitly ignore the > narrowing; don't use them if you want them to be limited to the > narrowed region. char-after is a primitive, and it behaves intuitively at (point-max) on narrowed buffers. Why shouldn't other functions behave consistently? > The last one should simply returns the search limit if it hits the > beginning of the narrowing, so I'm not sure why it is in this list. Nevermind about the search functions. I was confused about the behavior of previous-single-property-change. The problem lies in the functions that fetch the properties. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 08:56:38 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 13:56:38 +0000 Received: from localhost ([127.0.0.1]:46286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1z3G-0002jb-6v for submit@debbugs.gnu.org; Sat, 11 Jan 2014 08:56:38 -0500 Received: from qproxy1-pub.mail.unifiedlayer.com ([173.254.64.10]:52078 helo=qproxy1.mail.unifiedlayer.com) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W1z3A-0002jJ-MM for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 08:56:34 -0500 Received: (qmail 16856 invoked by uid 0); 11 Jan 2014 20:56:30 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by qproxy1.mail.unifiedlayer.com with SMTP; 11 Jan 2014 20:56:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=ZzHi7nSfEScbdtilwFyIcjnT9aYSHt639xbbszCpyLs=; b=rkINzDuOCeDcemC++4MqT0XnIuiSO9lpcMJzJlsifEePn3+Nq4xkQoaatOAKYr9Z6tEl2obD9ZK3xRlY5gnPtAlG4MORlfhVa/DCu4gskV0gfDqYWZXDqLTfuNhe8+rI; Received: from [50.90.253.209] (port=33541 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W1z37-0006pC-UJ; Sat, 11 Jan 2014 06:56:30 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> Date: Sat, 11 Jan 2014 08:56:26 -0500 In-Reply-To: <83vbxqact5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 15:05:42 +0200") Message-ID: <87zjn2y645.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: Nathan Trapuzzano >> Cc: Daniel Colascione , 16413@debbugs.gnu.org >> Date: Sat, 11 Jan 2014 07:24:30 -0500 >> >> For an example of where this is problematic, look at the patch I >> submitted last night on this list. I was patching functions that use >> the text property search functions and had to make a special case for >> where point is at (point-max) and the buffer is narrowed. > > point-max is and will always be a special case. There's no way around > that. But when dealing with text properties (and apparently only when dealing with text properties), there are _two_ special cases: (point-max) in a narrowed buffer, and (point-max) in a widened buffer. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 09:17:44 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 14:17:44 +0000 Received: from localhost ([127.0.0.1]:46372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1zNf-0004XE-Lc for submit@debbugs.gnu.org; Sat, 11 Jan 2014 09:17:43 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:43420) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1zNc-0004X3-IR for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 09:17:41 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZ800400QDCZW00@a-mtaout20.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 16:17:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ8004CTQDETQ60@a-mtaout20.012.net.il>; Sat, 11 Jan 2014 16:17:39 +0200 (IST) Date: Sat, 11 Jan 2014 16:17:21 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87eh4e1v8o.fsf@nbtrap.com> X-012-Sender: halo1@inter.net.il To: Nathan Trapuzzano Message-id: <83mwj2a9hq.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <52D0C401.90208@dancol.org> <87eh4e677p.fsf@nbtrap.com> <83txdaacnp.fsf@gnu.org> <87eh4e1v8o.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Nathan Trapuzzano > Cc: dancol@dancol.org, 16413@debbugs.gnu.org > Date: Sat, 11 Jan 2014 08:52:23 -0500 > > Eli Zaretskii writes: > > >> Functions that I know to be problematic include: > >> > >> get-text-property > >> text-properties-at > >> previous-single-property-change > > > > The first two are low-level primitives that explicitly ignore the > > narrowing; don't use them if you want them to be limited to the > > narrowed region. > > char-after is a primitive, and it behaves intuitively at (point-max) on > narrowed buffers. Why shouldn't other functions behave consistently? I don't know. One reason could be that we might need a primitive that can report properties of characters that are not reachable. But I don't have any evidence to that effect. > Nevermind about the search functions. I was confused about the behavior > of previous-single-property-change. The problem lies in the functions > that fetch the properties. The usual paradigm is to search for a possible place where the you might have the property, then examine the properties at that point. With this paradigm, if you never look at the properties when the search hits the limit of the search, you will never have this problem. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 09:18:48 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 14:18:48 +0000 Received: from localhost ([127.0.0.1]:46376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1zOi-0004ZI-67 for submit@debbugs.gnu.org; Sat, 11 Jan 2014 09:18:48 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:47635) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1zOg-0004Z4-JO for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 09:18:47 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MZ800D00PZYY300@a-mtaout21.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 16:18:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ800DK9QF6TI90@a-mtaout21.012.net.il>; Sat, 11 Jan 2014 16:18:42 +0200 (IST) Date: Sat, 11 Jan 2014 16:18:24 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87zjn2y645.fsf@nbtrap.com> X-012-Sender: halo1@inter.net.il To: Nathan Trapuzzano Message-id: <83lhyma9fz.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Nathan Trapuzzano > Cc: dancol@dancol.org, 16413@debbugs.gnu.org > Date: Sat, 11 Jan 2014 08:56:26 -0500 > > > point-max is and will always be a special case. There's no way around > > that. > > But when dealing with text properties (and apparently only when dealing > with text properties), there are _two_ special cases: (point-max) in a > narrowed buffer, and (point-max) in a widened buffer. Not if you never look at the properties when you hit the limit of the search for previous/next property change. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 14:43:25 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 19:43:25 +0000 Received: from localhost ([127.0.0.1]:47064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W24Sq-0005PL-Pr for submit@debbugs.gnu.org; Sat, 11 Jan 2014 14:43:25 -0500 Received: from alt-proxy6.mail.unifiedlayer.com ([66.147.245.65]:37081) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W24Sm-0005P9-5U for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 14:43:21 -0500 Received: (qmail 10357 invoked by uid 0); 11 Jan 2014 19:43:15 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy14.mail.unifiedlayer.com with SMTP; 11 Jan 2014 19:43:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=Y++ZVEgFYSJv7cJh1/dijMPebGWWhfUdK17g6BGAIRs=; b=iOhKLO09pPNdv9mqbq2M9slLNJmvxsUYDwhpJzTCVJQZQ7/8+xlaCMXt/ydV/cISC3JkQruBsoG73LleSoZso947jBPFaq3gxA2oJt1qSVD4fZO0IhdNELx4q2D5vc0S; Received: from [50.90.253.209] (port=35159 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W24Sh-0001Bg-Ba; Sat, 11 Jan 2014 12:43:15 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <52D0C401.90208@dancol.org> <87eh4e677p.fsf@nbtrap.com> <83txdaacnp.fsf@gnu.org> <87eh4e1v8o.fsf@nbtrap.com> <83mwj2a9hq.fsf@gnu.org> Date: Sat, 11 Jan 2014 14:43:11 -0500 In-Reply-To: <83mwj2a9hq.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 16:17:21 +0200") Message-ID: <87zjn25mpc.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: dancol@dancol.org, 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> char-after is a primitive, and it behaves intuitively at (point-max) on >> narrowed buffers. Why shouldn't other functions behave consistently? > > I don't know. One reason could be that we might need a primitive that > can report properties of characters that are not reachable. But I > don't have any evidence to that effect. Even if there were such a need, it could always be achieved with `save-restriction', etc. On the other hand, users should be able to expect that functions behave consistently with respect to narrowing, and these clearly don't >> Nevermind about the search functions. I was confused about the behavior >> of previous-single-property-change. The problem lies in the functions >> that fetch the properties. > > The usual paradigm is to search for a possible place where the you > might have the property, then examine the properties at that point. > With this paradigm, if you never look at the properties when the > search hits the limit of the search, you will never have this problem. I was confused by how `previous-single-property-change' actually doesn't look at the property at POSITION. It starts looking at (1- position) and then find the first difference from that point. It's not intuitive, but it makes sense if you think about it. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 14:44:42 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 19:44:42 +0000 Received: from localhost ([127.0.0.1]:47069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W24U5-0005Rt-Qi for submit@debbugs.gnu.org; Sat, 11 Jan 2014 14:44:42 -0500 Received: from alt-proxy17.mail.unifiedlayer.com ([66.147.241.60]:58373) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W24U2-0005Rh-TL for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 14:44:39 -0500 Received: (qmail 8253 invoked by uid 0); 11 Jan 2014 19:44:37 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy6.mail.unifiedlayer.com with SMTP; 11 Jan 2014 19:44:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=bqgongtAR/MB+OPLOUTk3SxULVHmN7YHhm7kFc22Tk4=; b=DLk9wAjmKrR6GLyOTw5ZI70SAyb2soRKhNcLqdOVNPd1pWaI10JKFaqbRG05x1kUzuqpWS25++/NXTilwWO6RcoTj7km9fjb4vDtLnJo8HGRisKjjhuriNe3xMBl5MOX; Received: from [50.90.253.209] (port=35160 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W24U1-00025U-J1; Sat, 11 Jan 2014 12:44:37 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> Date: Sat, 11 Jan 2014 14:44:28 -0500 In-Reply-To: <83lhyma9fz.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 16:18:24 +0200") Message-ID: <87vbxq5mn7.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> But when dealing with text properties (and apparently only when dealing >> with text properties), there are _two_ special cases: (point-max) in a >> narrowed buffer, and (point-max) in a widened buffer. > > Not if you never look at the properties when you hit the limit of the > search for previous/next property change. That may be true for searching, but the problem for fetching (`get-text-property', etc.) remains. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 14:59:14 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 19:59:14 +0000 Received: from localhost ([127.0.0.1]:47081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W24iA-0005qX-5c for submit@debbugs.gnu.org; Sat, 11 Jan 2014 14:59:14 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:55003) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W24i6-0005qK-KW for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 14:59:12 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZ900G0063RQW00@a-mtaout23.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 21:59:08 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ900GU466KMC90@a-mtaout23.012.net.il>; Sat, 11 Jan 2014 21:59:08 +0200 (IST) Date: Sat, 11 Jan 2014 21:58:51 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87vbxq5mn7.fsf@nbtrap.com> X-012-Sender: halo1@inter.net.il To: Nathan Trapuzzano Message-id: <83a9f29tok.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> <87vbxq5mn7.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Nathan Trapuzzano > Cc: 16413@debbugs.gnu.org > Date: Sat, 11 Jan 2014 14:44:28 -0500 > > Eli Zaretskii writes: > > >> But when dealing with text properties (and apparently only when dealing > >> with text properties), there are _two_ special cases: (point-max) in a > >> narrowed buffer, and (point-max) in a widened buffer. > > > > Not if you never look at the properties when you hit the limit of the > > search for previous/next property change. > > That may be true for searching, but the problem for fetching > (`get-text-property', etc.) remains. You need to fetch after searching, and never do that when the search hits the limit. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 15:13:52 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 20:13:52 +0000 Received: from localhost ([127.0.0.1]:47088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W24wJ-0006G1-UQ for submit@debbugs.gnu.org; Sat, 11 Jan 2014 15:13:52 -0500 Received: from alt-proxy13.mail.unifiedlayer.com ([67.222.34.81]:34983) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W24wI-0006Fq-1p for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 15:13:50 -0500 Received: (qmail 20813 invoked by uid 0); 11 Jan 2014 20:13:48 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy18.mail.unifiedlayer.com with SMTP; 11 Jan 2014 20:13:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=/xH2Yp2TosPVwFoiiMckWenNLevNCAokwCTX0utR7Uk=; b=p+OhXb6m6oIbU8uyqeKr8VMqLxHbxpc4piGEn+f6UV3hxtyRj/QNQRnJ8/5Vyd8B5orxQ6+d7LUv+IO0NL2fW8VDBI66INVoNv5E9ycMl4bkcuxDU66BuJT+NI8z8A1I; Received: from [50.90.253.209] (port=35213 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W24wF-0005Mc-SQ; Sat, 11 Jan 2014 13:13:48 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> <87vbxq5mn7.fsf@nbtrap.com> <83a9f29tok.fsf@gnu.org> Date: Sat, 11 Jan 2014 15:13:44 -0500 In-Reply-To: <83a9f29tok.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 21:58:51 +0200") Message-ID: <87mwj2l1jb.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: Nathan Trapuzzano >> Cc: 16413@debbugs.gnu.org >> Date: Sat, 11 Jan 2014 14:44:28 -0500 >> >> Eli Zaretskii writes: >> >> >> But when dealing with text properties (and apparently only when dealing >> >> with text properties), there are _two_ special cases: (point-max) in a >> >> narrowed buffer, and (point-max) in a widened buffer. >> > >> > Not if you never look at the properties when you hit the limit of the >> > search for previous/next property change. >> >> That may be true for searching, but the problem for fetching >> (`get-text-property', etc.) remains. > > You need to fetch after searching, and never do that when the search > hits the limit. I'm sorry, but this just seems totally contrived. Are people actually supposed to know this? And who's to say there's searching involved? What if I just want to look at the text properties at point? It shouldn't matter whether the buffer is narrowed. (If you think it _should_ matter, then why shouldn't it also matter for `char-after', etc. It's a consistency problem.) From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 15:27:38 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 20:27:38 +0000 Received: from localhost ([127.0.0.1]:47101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W259d-0006gD-CL for submit@debbugs.gnu.org; Sat, 11 Jan 2014 15:27:37 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:56271) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W259b-0006g5-Fn for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 15:27:36 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZ900G0075NTE00@a-mtaout23.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 22:27:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ900G9P7HXRT40@a-mtaout23.012.net.il>; Sat, 11 Jan 2014 22:27:34 +0200 (IST) Date: Sat, 11 Jan 2014 22:27:17 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87mwj2l1jb.fsf@nbtrap.com> X-012-Sender: halo1@inter.net.il To: Nathan Trapuzzano Message-id: <838uum9sd6.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> <87vbxq5mn7.fsf@nbtrap.com> <83a9f29tok.fsf@gnu.org> <87mwj2l1jb.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Nathan Trapuzzano > Cc: 16413@debbugs.gnu.org > Date: Sat, 11 Jan 2014 15:13:44 -0500 > > Eli Zaretskii writes: > > >> From: Nathan Trapuzzano > >> Cc: 16413@debbugs.gnu.org > >> Date: Sat, 11 Jan 2014 14:44:28 -0500 > >> > >> Eli Zaretskii writes: > >> > >> >> But when dealing with text properties (and apparently only when dealing > >> >> with text properties), there are _two_ special cases: (point-max) in a > >> >> narrowed buffer, and (point-max) in a widened buffer. > >> > > >> > Not if you never look at the properties when you hit the limit of the > >> > search for previous/next property change. > >> > >> That may be true for searching, but the problem for fetching > >> (`get-text-property', etc.) remains. > > > > You need to fetch after searching, and never do that when the search > > hits the limit. > > I'm sorry, but this just seems totally contrived. Are people actually > supposed to know this? And who's to say there's searching involved? > What if I just want to look at the text properties at point? It > shouldn't matter whether the buffer is narrowed. I was just trying to help you have less special cases in your code, that's all. How are you supposed to know about that? by reading the available code of course. That's how I learned this. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 15:40:53 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 20:40:53 +0000 Received: from localhost ([127.0.0.1]:47106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W25MT-00073J-7T for submit@debbugs.gnu.org; Sat, 11 Jan 2014 15:40:53 -0500 Received: from alt-proxy17.mail.unifiedlayer.com ([66.147.241.60]:50657) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W25MQ-00073A-L3 for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 15:40:51 -0500 Received: (qmail 14025 invoked by uid 0); 11 Jan 2014 20:40:44 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy6.mail.unifiedlayer.com with SMTP; 11 Jan 2014 20:40:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=ZJZsqb3I+aNH8nLb1N0NK9TeiRvdOP113wHAM9bF3LQ=; b=NhIZ+mxA/WZxobrgwA/3SRUik6d3p6pYNZX9fl3i5SuUJQrsdBo2MJkE6rt4fQqi2npubAIEqx4lZU/CbOGa6YfgJlXEKMjEgHGTyXNQ5aK0NUNusSh9Gb/urvDsqmPK; Received: from [50.90.253.209] (port=47591 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W25MK-0007C9-MF; Sat, 11 Jan 2014 13:40:44 -0700 From: Nathan Trapuzzano To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> <87vbxq5mn7.fsf@nbtrap.com> <83a9f29tok.fsf@gnu.org> <87mwj2l1jb.fsf@nbtrap.com> <838uum9sd6.fsf@gnu.org> Date: Sat, 11 Jan 2014 15:40:41 -0500 In-Reply-To: <838uum9sd6.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 22:27:17 +0200") Message-ID: <87k3e62qwm.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > I was just trying to help you have less special cases in your code, > that's all. Okay, I thought you were generalizing. > How are you supposed to know about that? by reading the available code > of course. That's how I learned this. I don't think people should have to read code to know what to expect from interfaces. So do you think the current behavior is consistent, or are you just cautious about trying to change it? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 15:46:25 2014 Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 20:46:25 +0000 Received: from localhost ([127.0.0.1]:47110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W25Rp-0007Ck-9Q for submit@debbugs.gnu.org; Sat, 11 Jan 2014 15:46:25 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:57174) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W25Rm-0007Ca-Qx for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 15:46:23 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZ900G008BGW200@a-mtaout23.012.net.il> for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 22:46:21 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ900GZF8D9RT70@a-mtaout23.012.net.il>; Sat, 11 Jan 2014 22:46:21 +0200 (IST) Date: Sat, 11 Jan 2014 22:46:04 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <87k3e62qwm.fsf@nbtrap.com> X-012-Sender: halo1@inter.net.il To: Nathan Trapuzzano Message-id: <8361pq9rhv.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> <87vbxq5mn7.fsf@nbtrap.com> <83a9f29tok.fsf@gnu.org> <87mwj2l1jb.fsf@nbtrap.com> <838uum9sd6.fsf@gnu.org> <87k3e62qwm.fsf@nbtrap.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Nathan Trapuzzano > Cc: 16413@debbugs.gnu.org > Date: Sat, 11 Jan 2014 15:40:41 -0500 > > So do you think the current behavior is consistent, or are you just > cautious about trying to change it? I'm cautious about changing this and don't see the apparent inconsistency as a big deal. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 22:42:40 2014 Received: (at 16413) by debbugs.gnu.org; 12 Jan 2014 03:42:40 +0000 Received: from localhost ([127.0.0.1]:47281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Bwd-0002AE-LT for submit@debbugs.gnu.org; Sat, 11 Jan 2014 22:42:40 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46696) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Bwa-0002A3-KN for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 22:42:36 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFpYlR/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFFpYlR/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44758457" Received: from 69-165-137-81.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.137.81]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Jan 2014 22:42:35 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B1E59AE15C; Sat, 11 Jan 2014 22:42:33 -0500 (EST) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Message-ID: References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> Date: Sat, 11 Jan 2014 22:42:33 -0500 In-Reply-To: <52D0FADE.8060605@dancol.org> (Daniel Colascione's message of "Sat, 11 Jan 2014 00:03:42 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , 16413@debbugs.gnu.org, nbtrap@nbtrap.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Narrowing *is* generally useful for treating part of a buffer > as a consistent unit, though, especially when that part is syntactically > different from the rest of the buffer. Actually, from where I stand, narrowing is harmful. If I could get rid of it, I would. The reason is precisely because it means different things to different people in different contexts, and these things require subtly different behaviors which are mutually incompatible. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 11 23:35:19 2014 Received: (at 16413) by debbugs.gnu.org; 12 Jan 2014 04:35:19 +0000 Received: from localhost ([127.0.0.1]:47306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Cla-0003em-5O for submit@debbugs.gnu.org; Sat, 11 Jan 2014 23:35:18 -0500 Received: from dancol.org ([96.126.100.184]:35510) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2ClX-0003eb-1e for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 23:35:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ZzQs43bgGBBDDMI0vnyx0jbdzVbVFwvmjeqarM0fx9Q=; b=Isp8wuTRWpF5WcqtQ+zwS+0At8zwtCLOwJ2KMk3aEklcUgZI4RVTC+EHRGPrBJMsdzQp5gpn7wMcAkNtmYQPXsVXVQzOpW/jzIgwSQSl2GPG7bm6sYhno0BaCHStcXoB8v9UXXldjJKZstVbPcuHK6ieCCIwTvn6s0OBIlnR+9Rfpd6pnZus5wTn6k8RBNx0D87kQHWViN0WABVAh9cpiX3mMFCuZJwkVg2xg2OTwJBeocUihN3gpin9574qht6ZoN14862WNYMm13+pDzdT/wW5V6RKVgBLGUrr5d/3Q6EeZh7Ma04RaojHGvtTQ9jN6xB9VPMsNn/V3lnHvOyoOg==; Received: from [2601:8:b200:217:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W2ClP-0004u5-IA; Sat, 11 Jan 2014 20:35:07 -0800 Message-ID: <52D21B75.501@dancol.org> Date: Sat, 11 Jan 2014 20:35:01 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , 16413@debbugs.gnu.org, nbtrap@nbtrap.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 01/11/2014 07:42 PM, Stefan Monnier wrote: >> Narrowing *is* generally useful for treating part of a buffer >> as a consistent unit, though, especially when that part is syntactically >> different from the rest of the buffer. > > Actually, from where I stand, narrowing is harmful. If I could get rid > of it, I would. Really? It's a very useful feature at a *user* level even if we ignore the lisp-level implications. Doesn't everyone whack C-x n d once in a while? Would you have implemented narrowing by putting invisible properties on the inaccessible region? > The reason is precisely because it means different > things to different people in different contexts, and these things > require subtly different behaviors which are mutually incompatible. As I see it, there are generally two use cases: 1) I'm a user and want to limit my view of the buffer, and 2) I'm a lisp program and want to put ad-hoc bounds on various operations. I don't see why the two uses would be incompatible. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 10:54:20 2014 Received: (at 16413) by debbugs.gnu.org; 12 Jan 2014 15:54:20 +0000 Received: from localhost ([127.0.0.1]:47943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2NMh-0007Mu-PF for submit@debbugs.gnu.org; Sun, 12 Jan 2014 10:54:20 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:55377) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2NMa-0007Mg-ED for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 10:54:13 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZA00100PE5SI00@a-mtaout22.012.net.il> for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 17:54:02 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZA0012SPI18090@a-mtaout22.012.net.il>; Sun, 12 Jan 2014 17:54:02 +0200 (IST) Date: Sun, 12 Jan 2014 17:53:47 +0200 From: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer In-reply-to: <52D21B75.501@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83r48d8ad0.fsf@gnu.org> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16413 Cc: nbtrap@nbtrap.com, 16413@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 11 Jan 2014 20:35:01 -0800 > From: Daniel Colascione > CC: Eli Zaretskii , nbtrap@nbtrap.com, > 16413@debbugs.gnu.org > > > The reason is precisely because it means different > > things to different people in different contexts, and these things > > require subtly different behaviors which are mutually incompatible. > > As I see it, there are generally two use cases: > > 1) I'm a user and want to limit my view of the buffer, and > 2) I'm a lisp program and want to put ad-hoc bounds on various operations. > > I don't see why the two uses would be incompatible. I think Stefan meant use cases with different Lisp-level features and operations, like moving point as opposed to examining text properties. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 16:37:52 2014 Received: (at 16413) by debbugs.gnu.org; 12 Jan 2014 21:37:52 +0000 Received: from localhost ([127.0.0.1]:48127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Sj9-000057-Sq for submit@debbugs.gnu.org; Sun, 12 Jan 2014 16:37:52 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:30269) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Sj6-00004x-9N for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 16:37:49 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2NGoNwA4hhnBmBXoMVgUk X-IPAS-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2NGoNwA4hhnBmBXoMVgUk X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44785684" Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Jan 2014 16:37:47 -0500 Received: by pastel.home (Postfix, from userid 20848) id B597C60321; Sun, 12 Jan 2014 16:37:46 -0500 (EST) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Message-ID: References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> Date: Sun, 12 Jan 2014 16:37:46 -0500 In-Reply-To: <52D21B75.501@dancol.org> (Daniel Colascione's message of "Sat, 11 Jan 2014 20:35:01 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , 16413@debbugs.gnu.org, nbtrap@nbtrap.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > As I see it, there are generally two use cases: > 1) I'm a user and want to limit my view of the buffer, and > 2) I'm a lisp program and want to put ad-hoc bounds on various operations. > I don't see why the two uses would be incompatible. Typical problematic questions: - should line-number-at-pos count from point-min or from 1? - should syntax-ppss consider that point-min is "outside of any comment/string/paren/..."? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 17:18:01 2014 Received: (at 16413) by debbugs.gnu.org; 12 Jan 2014 22:18:01 +0000 Received: from localhost ([127.0.0.1]:48139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2TM1-0001Ae-2o for submit@debbugs.gnu.org; Sun, 12 Jan 2014 17:18:01 -0500 Received: from alt-proxy1.mail.unifiedlayer.com ([70.40.203.67]:48972) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W2TLy-0001AU-Pv for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 17:18:00 -0500 Received: (qmail 32067 invoked by uid 0); 12 Jan 2014 22:17:55 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy12.mail.unifiedlayer.com with SMTP; 12 Jan 2014 22:17:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=GVS8BkXVQ9ZOueqZUQFhS3p0RLQYlE6fWC7GfrwQp8o=; b=cqY/BSf42+WBwNO7xcHmXNVwAXcjktOm2MhqSJAYzfflopMn6dHpIzOakiaCTT3jJl4EmdvJPEvz4W42k8pwa4b0FvsrfFvcpLyA8Z1mShgf786bGPIF/pL53IBIWhOt; Received: from [50.90.253.209] (port=34766 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W2TLv-0004xH-3x; Sun, 12 Jan 2014 15:17:55 -0700 From: Nathan Trapuzzano To: Stefan Monnier Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> Date: Sun, 12 Jan 2014 17:17:51 -0500 In-Reply-To: (Stefan Monnier's message of "Sun, 12 Jan 2014 16:37:46 -0500") Message-ID: <8761po975c.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , Daniel Colascione , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: > Typical problematic questions: > - should line-number-at-pos count from point-min or from 1? > - should syntax-ppss consider that point-min is "outside of any > comment/string/paren/..."? Apart from the consideration of breaking existing elisp, do you think there's substantial disagreement on these questions? In the case of the second question at least, the answer seems obvious if the end goal is proper syntax recognition in narrowed buffers. But maybe that's na=C3=AFve. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 23:01:31 2014 Received: (at 16413) by debbugs.gnu.org; 13 Jan 2014 04:01:31 +0000 Received: from localhost ([127.0.0.1]:48208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2YiQ-00025F-Mm for submit@debbugs.gnu.org; Sun, 12 Jan 2014 23:01:30 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49681) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2YiO-000257-RH for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 23:01:29 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44802663" Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Jan 2014 23:01:28 -0500 Received: by pastel.home (Postfix, from userid 20848) id 0279560FB9; Sun, 12 Jan 2014 23:01:27 -0500 (EST) From: Stefan Monnier To: Nathan Trapuzzano Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Message-ID: References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> <8761po975c.fsf@nbtrap.com> Date: Sun, 12 Jan 2014 23:01:27 -0500 In-Reply-To: <8761po975c.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Sun, 12 Jan 2014 17:17:51 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , Daniel Colascione , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Apart from the consideration of breaking existing elisp, do you think > there's substantial disagreement on these questions? Oh yes. Look at the uses of narrowing in info-mode for an example. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 23:04:40 2014 Received: (at 16413) by debbugs.gnu.org; 13 Jan 2014 04:04:40 +0000 Received: from localhost ([127.0.0.1]:48212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2YlT-0002AO-6d for submit@debbugs.gnu.org; Sun, 12 Jan 2014 23:04:40 -0500 Received: from dancol.org ([96.126.100.184]:39416) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2YlQ-0002AB-Dz for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 23:04:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=0mEKRkkazY8+BJIidF1Gmi848L+5C3xJy4TqcSEiyD0=; b=SvxBHzMfUtcu4eOIxE9jKWt03atMt0B9cqPV48mhHJZkqLGHXVQN2XwVjxDHSsLr2J4TcXE79cQ+DBExtfoW9hmwU5h7b45EwuUgsORGZn2Na3m85RrPGLfjk12UiTamQT21G7CwN4tgufwtFXrRyIT8zc7kahFmcRgdoes9VhLiDGxENBhEmcVxAAqBj20tb26qqGZLgUtw46xTukUjydRAWUdSoNnt438oGxLmcLAOx75o3Ajt2V4HyIHZsStKf35kD1CLufW7fuNUEOFsB/AnzcqKauweydVM3WqeJbxcoKhceHV/lA+JUw2zNRcaImrL5sd9rUTIhuK9rok4/g==; Received: from [2620:0:1cfe:99::7] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W2YlN-0007LQ-5g; Sun, 12 Jan 2014 20:04:33 -0800 Message-ID: <52D365C9.5050904@dancol.org> Date: Sun, 12 Jan 2014 20:04:25 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier , Nathan Trapuzzano Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> <8761po975c.fsf@nbtrap.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) On 01/12/2014 08:01 PM, Stefan Monnier wrote: >> Apart from the consideration of breaking existing elisp, do you think >> there's substantial disagreement on these questions? > > Oh yes. Look at the uses of narrowing in info-mode for an example. What about it? It looks like normal elisp use of narrowing to me. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 23:21:15 2014 Received: (at 16413) by debbugs.gnu.org; 13 Jan 2014 04:21:15 +0000 Received: from localhost ([127.0.0.1]:48237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Z1X-0002c9-9Q for submit@debbugs.gnu.org; Sun, 12 Jan 2014 23:21:15 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37779) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2Z1V-0002c2-VQ for 16413@debbugs.gnu.org; Sun, 12 Jan 2014 23:21:14 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMQCw4mEhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMQCw4mEhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44803031" Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Jan 2014 23:21:13 -0500 Received: by pastel.home (Postfix, from userid 20848) id 536B2613F1; Sun, 12 Jan 2014 23:21:13 -0500 (EST) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Message-ID: References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> <8761po975c.fsf@nbtrap.com> <52D365C9.5050904@dancol.org> Date: Sun, 12 Jan 2014 23:21:13 -0500 In-Reply-To: <52D365C9.5050904@dancol.org> (Daniel Colascione's message of "Sun, 12 Jan 2014 20:04:25 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16413 Cc: Nathan Trapuzzano , 16413@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >>> Apart from the consideration of breaking existing elisp, do you think >>> there's substantial disagreement on these questions? >> Oh yes. Look at the uses of narrowing in info-mode for an example. > What about it? It looks like normal elisp use of narrowing to me. To the user, the text outside of the visible area doesn't exist at all. (line-number-at-pos (point-min)) should return 1 there, even though there are always several/many lines of text before point-min. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 07:09:24 2014 Received: (at 16413) by debbugs.gnu.org; 13 Jan 2014 12:09:24 +0000 Received: from localhost ([127.0.0.1]:48528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2gKZ-0007iG-KH for submit@debbugs.gnu.org; Mon, 13 Jan 2014 07:09:24 -0500 Received: from oproxy7-pub.mail.unifiedlayer.com ([67.222.55.9]:42786) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W2gKQ-0007hs-NW for 16413@debbugs.gnu.org; Mon, 13 Jan 2014 07:09:21 -0500 Received: (qmail 22531 invoked by uid 0); 13 Jan 2014 12:09:10 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy7.mail.unifiedlayer.com with SMTP; 13 Jan 2014 12:09:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=jETop9B0asY7cefDEFnVHSK24fwuWzV6VKXiIVVZheo=; b=wrgywoKJZxc7rPFldKpK92hC/FMxxYTOJANaPR6gUHrWbzvWuZt+1vwIpLxtHEox9Be7I+/ruBimRZYPXiIZb+A8pv31sBMyaaBiwINAbduVvyl4D9LVrxp/v9hJHMGN; Received: from [50.90.253.209] (port=48911 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W2gKM-0003Qt-ER; Mon, 13 Jan 2014 05:09:10 -0700 From: Nathan Trapuzzano To: Stefan Monnier Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> <8761po975c.fsf@nbtrap.com> <52D365C9.5050904@dancol.org> Date: Mon, 13 Jan 2014 07:09:06 -0500 In-Reply-To: (Stefan Monnier's message of "Sun, 12 Jan 2014 23:21:13 -0500") Message-ID: <87y52k2ie5.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stefan Monnier writes: > To the user, the text outside of the visible area doesn't exist at all. > (line-number-at-pos (point-min)) should return 1 there, even though > there are always several/many lines of text before point-min. [...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [67.222.55.9 listed in psbl.surriel.com] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , Daniel Colascione , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stefan Monnier writes: > To the user, the text outside of the visible area doesn't exist at all. > (line-number-at-pos (point-min)) should return 1 there, even though > there are always several/many lines of text before point-min. [...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [67.222.55.9 listed in psbl.surriel.com] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid Stefan Monnier writes: > To the user, the text outside of the visible area doesn't exist at all. > (line-number-at-pos (point-min)) should return 1 there, even though > there are always several/many lines of text before point-min. So maybe there should be a defcustom that says whether to number lines according to the whole buffer or just the narrowed part. These problems seem far from insurmountable. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 09:51:26 2014 Received: (at 16413) by debbugs.gnu.org; 13 Jan 2014 14:51:26 +0000 Received: from localhost ([127.0.0.1]:48679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2irN-0007Lj-7u for submit@debbugs.gnu.org; Mon, 13 Jan 2014 09:51:25 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:20977) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2irL-0007Lb-45 for 16413@debbugs.gnu.org; Mon, 13 Jan 2014 09:51:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFMCoyj/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44824295" Received: from 76-10-140-163.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 13 Jan 2014 09:51:22 -0500 Received: by pastel.home (Postfix, from userid 20848) id 4CFF660592; Mon, 13 Jan 2014 09:51:22 -0500 (EST) From: Stefan Monnier To: Nathan Trapuzzano Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Message-ID: References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <52D0FADE.8060605@dancol.org> <52D21B75.501@dancol.org> <8761po975c.fsf@nbtrap.com> <52D365C9.5050904@dancol.org> <87y52k2ie5.fsf@nbtrap.com> Date: Mon, 13 Jan 2014 09:51:22 -0500 In-Reply-To: <87y52k2ie5.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Mon, 13 Jan 2014 07:09:06 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16413 Cc: Eli Zaretskii , Daniel Colascione , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > So maybe there should be a defcustom that says whether to number lines > according to the whole buffer or just the narrowed part. No, a variable is not sufficient: you can still use narrowing within the info-mode's narrowed page. The "outer narrowing" should give the illusion that the outer text doesn't exist, while the inner one shouldn't. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 07:10:11 2022 Received: (at 16413) by debbugs.gnu.org; 28 Apr 2022 11:10:11 +0000 Received: from localhost ([127.0.0.1]:45562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk22E-0004yv-Vk for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:10:11 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk22C-0004ye-SW for 16413@debbugs.gnu.org; Thu, 28 Apr 2022 07:10:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=d1Br5iGk64RC66K+NmBVM7yrRVMNwFXANx58Ca296aY=; b=QAte5JcJ5lDXAJxFrmpnjO93pJ ECRCRYmmUt3jbuXyf+ncv1SUtkS0fHLfgOt0pnIrh02GvdmAliLdOr3I1X6N/ezbaibVqzJ6O8qrO uRrp/I8EazutCmGspFY7NhnVT41A8YE19QfDPAmtQUZbrQRrBoDP9FcB41SlhA2Fh+4E=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk222-0008QI-KJ; Thu, 28 Apr 2022 13:10:00 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <8361praqvc.fsf@gnu.org> <87a9f2670h.fsf@nbtrap.com> <83vbxqact5.fsf@gnu.org> <87zjn2y645.fsf@nbtrap.com> <83lhyma9fz.fsf@gnu.org> <87vbxq5mn7.fsf@nbtrap.com> <83a9f29tok.fsf@gnu.org> <87mwj2l1jb.fsf@nbtrap.com> <838uum9sd6.fsf@gnu.org> <87k3e62qwm.fsf@nbtrap.com> <8361pq9rhv.fsf@gnu.org> X-Now-Playing: New Fast Automatic Daffodils's _This Is Fascism (1)_: "This Is Fascism" Date: Thu, 28 Apr 2022 13:09:58 +0200 In-Reply-To: <8361pq9rhv.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 22:46:04 +0200") Message-ID: <87o80lmpkp.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> So do you think the current behavior is consistent, or are you just >> cautious about trying to change it? > > I'm cautious about changing this and don't see the apparent > inconsistency as a big d [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 16413 Cc: Nathan Trapuzzano , 16413@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> So do you think the current behavior is consistent, or are you just >> cautious about trying to change it? > > I'm cautious about changing this and don't see the apparent > inconsistency as a big deal. (I'm going through old bug reports that unfortunately weren't resolved at the time.) I don't think we want to change the behaviour at this point, as that might break a lot of code subtly out there, but it should be documented. So I've now done that in Emacs 29, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 07:10:13 2022 Received: (at control) by debbugs.gnu.org; 28 Apr 2022 11:10:13 +0000 Received: from localhost ([127.0.0.1]:45565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk22H-0004zC-DD for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:10:13 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk22G-0004yl-MS for control@debbugs.gnu.org; Thu, 28 Apr 2022 07:10:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NCHByEf09XmlbAcTW3IFpZHazPJ7u1dGp6XRyyaqIg4=; b=O7Dj5Wj4kl0KxGJpsIIPOZ7meF sLLD51+DMAVeyd6y4UnyTLEArxmLNOX9H8bj/ds7YH8tdpUJcf1WKEnFHc88yxrBBvQWcvxHTcZYf 3gyD0l7t3Bf4Dj/6PqI1hd0BzXUxUlwMTcqdYVeEkC9c/acVEegyipJ/BN9OnwlgNbk8=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk229-0008Qh-2R for control@debbugs.gnu.org; Thu, 28 Apr 2022 13:10:06 +0200 Date: Thu, 28 Apr 2022 13:10:04 +0200 Message-Id: <87mtg5mpkj.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #16413 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 16413 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 16413 quit From unknown Wed Jun 18 00:26:14 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 26 May 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator