GNU bug report logs - #16413
24.3.50; Inconsistent behavior of text property functions in narrowed buffer

Previous Next

Package: emacs;

Reported by: Nathan Trapuzzano <nbtrap <at> nbtrap.com>

Date: Sat, 11 Jan 2014 03:07:01 UTC

Severity: wishlist

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #62 received at 16413 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16413 <at> debbugs.gnu.org
Subject: Re: bug#16413: 24.3.50;
 Inconsistent behavior of text property functions in narrowed buffer
Date: Sat, 11 Jan 2014 15:13:44 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
>> Cc: 16413 <at> debbugs.gnu.org
>> Date: Sat, 11 Jan 2014 14:44:28 -0500
>> 
>> Eli Zaretskii <eliz <at> gnu.org> 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.)




This bug report was last modified 3 years and 23 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.