bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Daniel Colascione]

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)))))

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Daniel Colascione <dancol@dancol.org> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> Cc: dancol@dancol.org,  16413@debbugs.gnu.org
> Date: Sat, 11 Jan 2014 08:52:23 -0500
> 
> Eli Zaretskii <eliz@gnu.org> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> Date: Fri, 10 Jan 2014 20:05:33 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 
> 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?

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Daniel Colascione]

On 01/11/2014 12:01 AM, Eli Zaretskii wrote:
>> Date: Fri, 10 Jan 2014 20:05:33 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>>
>> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> Date: Sat, 11 Jan 2014 00:03:42 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Daniel Colascione]

On 01/11/2014 12:12 AM, Eli Zaretskii wrote:
>> Date: Sat, 11 Jan 2014 00:03:42 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> Date: Sat, 11 Jan 2014 00:17:19 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Stefan Monnier]

> 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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Daniel Colascione]

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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> Date: Sat, 11 Jan 2014 20:35:01 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: Eli Zaretskii <eliz@gnu.org>, 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Stefan Monnier]

> 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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Stefan Monnier <monnier@iro.umontreal.ca> 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ïve.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Stefan Monnier]

> 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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Daniel Colascione]

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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Stefan Monnier]

>>> 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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Stefan Monnier]

> 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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> Cc: Daniel Colascione <dancol@dancol.org>,  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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
>> Cc: Daniel Colascione <dancol@dancol.org>,  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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> writes:

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

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

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

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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> 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?

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> 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.

bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> 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