* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
@ 2014-01-11 3:05 Nathan Trapuzzano
2014-01-11 4:05 ` Daniel Colascione
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 3:05 UTC (permalink / raw)
To: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 3:05 bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Nathan Trapuzzano
@ 2014-01-11 4:05 ` Daniel Colascione
2014-01-11 4:09 ` Daniel Colascione
2014-01-11 8:01 ` Eli Zaretskii
0 siblings, 2 replies; 34+ messages in thread
From: Daniel Colascione @ 2014-01-11 4:05 UTC (permalink / raw)
To: Nathan Trapuzzano, 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 4:05 ` Daniel Colascione
@ 2014-01-11 4:09 ` Daniel Colascione
2014-01-11 12:20 ` Nathan Trapuzzano
2014-01-11 8:01 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: Daniel Colascione @ 2014-01-11 4:09 UTC (permalink / raw)
To: Nathan Trapuzzano, 16413
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)))))
^ permalink raw reply [flat|nested] 34+ messages in thread* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 4:09 ` Daniel Colascione
@ 2014-01-11 12:20 ` Nathan Trapuzzano
2014-01-11 13:08 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 12:20 UTC (permalink / raw)
To: Daniel Colascione; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 12:20 ` Nathan Trapuzzano
@ 2014-01-11 13:08 ` Eli Zaretskii
2014-01-11 13:52 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 13:08 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 13:08 ` Eli Zaretskii
@ 2014-01-11 13:52 ` Nathan Trapuzzano
2014-01-11 14:17 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 13:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 13:52 ` Nathan Trapuzzano
@ 2014-01-11 14:17 ` Eli Zaretskii
2014-01-11 19:43 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 14:17 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 14:17 ` Eli Zaretskii
@ 2014-01-11 19:43 ` Nathan Trapuzzano
0 siblings, 0 replies; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 19:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 4:05 ` Daniel Colascione
2014-01-11 4:09 ` Daniel Colascione
@ 2014-01-11 8:01 ` Eli Zaretskii
2014-01-11 8:03 ` Daniel Colascione
2014-01-11 12:24 ` Nathan Trapuzzano
1 sibling, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 8:01 UTC (permalink / raw)
To: Daniel Colascione; +Cc: nbtrap, 16413
> 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?
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 8:01 ` Eli Zaretskii
@ 2014-01-11 8:03 ` Daniel Colascione
2014-01-11 8:12 ` Eli Zaretskii
2014-01-12 3:42 ` Stefan Monnier
2014-01-11 12:24 ` Nathan Trapuzzano
1 sibling, 2 replies; 34+ messages in thread
From: Daniel Colascione @ 2014-01-11 8:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: nbtrap, 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 8:03 ` Daniel Colascione
@ 2014-01-11 8:12 ` Eli Zaretskii
2014-01-11 8:17 ` Daniel Colascione
2014-01-12 3:42 ` Stefan Monnier
1 sibling, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 8:12 UTC (permalink / raw)
To: Daniel Colascione; +Cc: nbtrap, 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 8:12 ` Eli Zaretskii
@ 2014-01-11 8:17 ` Daniel Colascione
2014-01-11 8:27 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Daniel Colascione @ 2014-01-11 8:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: nbtrap, 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 8:17 ` Daniel Colascione
@ 2014-01-11 8:27 ` Eli Zaretskii
0 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 8:27 UTC (permalink / raw)
To: Daniel Colascione; +Cc: nbtrap, 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 8:03 ` Daniel Colascione
2014-01-11 8:12 ` Eli Zaretskii
@ 2014-01-12 3:42 ` Stefan Monnier
2014-01-12 4:35 ` Daniel Colascione
1 sibling, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2014-01-12 3:42 UTC (permalink / raw)
To: Daniel Colascione; +Cc: 16413, nbtrap
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-12 3:42 ` Stefan Monnier
@ 2014-01-12 4:35 ` Daniel Colascione
2014-01-12 15:53 ` Eli Zaretskii
2014-01-12 21:37 ` Stefan Monnier
0 siblings, 2 replies; 34+ messages in thread
From: Daniel Colascione @ 2014-01-12 4:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16413, nbtrap
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-12 4:35 ` Daniel Colascione
@ 2014-01-12 15:53 ` Eli Zaretskii
2014-01-12 21:37 ` Stefan Monnier
1 sibling, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-12 15:53 UTC (permalink / raw)
To: Daniel Colascione; +Cc: nbtrap, 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-12 4:35 ` Daniel Colascione
2014-01-12 15:53 ` Eli Zaretskii
@ 2014-01-12 21:37 ` Stefan Monnier
2014-01-12 22:17 ` Nathan Trapuzzano
1 sibling, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2014-01-12 21:37 UTC (permalink / raw)
To: Daniel Colascione; +Cc: 16413, nbtrap
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-12 21:37 ` Stefan Monnier
@ 2014-01-12 22:17 ` Nathan Trapuzzano
2014-01-13 4:01 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-12 22:17 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-12 22:17 ` Nathan Trapuzzano
@ 2014-01-13 4:01 ` Stefan Monnier
2014-01-13 4:04 ` Daniel Colascione
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2014-01-13 4:01 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-13 4:01 ` Stefan Monnier
@ 2014-01-13 4:04 ` Daniel Colascione
2014-01-13 4:21 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Daniel Colascione @ 2014-01-13 4:04 UTC (permalink / raw)
To: Stefan Monnier, Nathan Trapuzzano; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-13 4:04 ` Daniel Colascione
@ 2014-01-13 4:21 ` Stefan Monnier
2014-01-13 12:09 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2014-01-13 4:21 UTC (permalink / raw)
To: Daniel Colascione; +Cc: Nathan Trapuzzano, 16413
>>> 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
^ permalink raw reply [flat|nested] 34+ messages in thread* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-13 4:21 ` Stefan Monnier
@ 2014-01-13 12:09 ` Nathan Trapuzzano
2014-01-13 14:51 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-13 12:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-13 12:09 ` Nathan Trapuzzano
@ 2014-01-13 14:51 ` Stefan Monnier
0 siblings, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2014-01-13 14:51 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 8:01 ` Eli Zaretskii
2014-01-11 8:03 ` Daniel Colascione
@ 2014-01-11 12:24 ` Nathan Trapuzzano
2014-01-11 13:05 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 12:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 12:24 ` Nathan Trapuzzano
@ 2014-01-11 13:05 ` Eli Zaretskii
2014-01-11 13:56 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 13:05 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 13:05 ` Eli Zaretskii
@ 2014-01-11 13:56 ` Nathan Trapuzzano
2014-01-11 14:18 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 13:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 13:56 ` Nathan Trapuzzano
@ 2014-01-11 14:18 ` Eli Zaretskii
2014-01-11 19:44 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 14:18 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 14:18 ` Eli Zaretskii
@ 2014-01-11 19:44 ` Nathan Trapuzzano
2014-01-11 19:58 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 19:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 19:44 ` Nathan Trapuzzano
@ 2014-01-11 19:58 ` Eli Zaretskii
2014-01-11 20:13 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 19:58 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 19:58 ` Eli Zaretskii
@ 2014-01-11 20:13 ` Nathan Trapuzzano
2014-01-11 20:27 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 20:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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.)
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 20:13 ` Nathan Trapuzzano
@ 2014-01-11 20:27 ` Eli Zaretskii
2014-01-11 20:40 ` Nathan Trapuzzano
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 20:27 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 20:27 ` Eli Zaretskii
@ 2014-01-11 20:40 ` Nathan Trapuzzano
2014-01-11 20:46 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Nathan Trapuzzano @ 2014-01-11 20:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16413
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?
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 20:40 ` Nathan Trapuzzano
@ 2014-01-11 20:46 ` Eli Zaretskii
2022-04-28 11:09 ` Lars Ingebrigtsen
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2014-01-11 20:46 UTC (permalink / raw)
To: Nathan Trapuzzano; +Cc: 16413
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer
2014-01-11 20:46 ` Eli Zaretskii
@ 2022-04-28 11:09 ` Lars Ingebrigtsen
0 siblings, 0 replies; 34+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-28 11:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Nathan Trapuzzano, 16413
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
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2022-04-28 11:09 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-11 3:05 bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Nathan Trapuzzano
2014-01-11 4:05 ` Daniel Colascione
2014-01-11 4:09 ` Daniel Colascione
2014-01-11 12:20 ` Nathan Trapuzzano
2014-01-11 13:08 ` Eli Zaretskii
2014-01-11 13:52 ` Nathan Trapuzzano
2014-01-11 14:17 ` Eli Zaretskii
2014-01-11 19:43 ` Nathan Trapuzzano
2014-01-11 8:01 ` Eli Zaretskii
2014-01-11 8:03 ` Daniel Colascione
2014-01-11 8:12 ` Eli Zaretskii
2014-01-11 8:17 ` Daniel Colascione
2014-01-11 8:27 ` Eli Zaretskii
2014-01-12 3:42 ` Stefan Monnier
2014-01-12 4:35 ` Daniel Colascione
2014-01-12 15:53 ` Eli Zaretskii
2014-01-12 21:37 ` Stefan Monnier
2014-01-12 22:17 ` Nathan Trapuzzano
2014-01-13 4:01 ` Stefan Monnier
2014-01-13 4:04 ` Daniel Colascione
2014-01-13 4:21 ` Stefan Monnier
2014-01-13 12:09 ` Nathan Trapuzzano
2014-01-13 14:51 ` Stefan Monnier
2014-01-11 12:24 ` Nathan Trapuzzano
2014-01-11 13:05 ` Eli Zaretskii
2014-01-11 13:56 ` Nathan Trapuzzano
2014-01-11 14:18 ` Eli Zaretskii
2014-01-11 19:44 ` Nathan Trapuzzano
2014-01-11 19:58 ` Eli Zaretskii
2014-01-11 20:13 ` Nathan Trapuzzano
2014-01-11 20:27 ` Eli Zaretskii
2014-01-11 20:40 ` Nathan Trapuzzano
2014-01-11 20:46 ` Eli Zaretskii
2022-04-28 11:09 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).