question about narrowed behavior of next-property-change et al.

question about narrowed behavior of next-property-change et al.

[Miles Bader]

Info contains the following check to avoid refontifying fontified nodes:

   (defun Info-fontify-node ()
     ;; Only fontify the node if it hasn't already been done.
     (unless (next-property-change (point-min))
        ...

However, this often doesn't always work properly because it assumes that
`next-property-change' will return nil if there's no property change
before the narrowed end of the buffer, and in fact if there's a
property change _beyond_ the narrowed end, it will return (point-max),
even though the user passed a LIMIT arg of nil.

It's easy enough to change Info-fontify-node to be more paranoid, but to
me, the current behavior of `next-property-change' seems wrong in this
case -- I think if there's no property change before (point-max), and
the user passed LIMIT == nil, then it should return nil, regardless of
whether (point-max) is due to narrowing or not.

Any comments before I make such a change?

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: question about narrowed behavior of next-property-change et al.

[Stefan Monnier]

> It's easy enough to change Info-fontify-node to be more paranoid, but to
> me, the current behavior of `next-property-change' seems wrong in this
> case -- I think if there's no property change before (point-max), and
> the user passed LIMIT == nil, then it should return nil, regardless of
> whether (point-max) is due to narrowing or not.

100% agreement (obviously, for those who've looked at the changelog ;-)


	Stefan

Re: question about narrowed behavior of next-property-change et al.

[Richard Stallman]

    It's easy enough to change Info-fontify-node to be more paranoid, but to
    me, the current behavior of `next-property-change' seems wrong in this
    case -- I think if there's no property change before (point-max), and
    the user passed LIMIT == nil, then it should return nil, regardless of
    whether (point-max) is due to narrowing or not.

    Any comments before I make such a change?

It is certainly more logical that way--the question is, what will it
break?  It would be necessary to check all the programs that use
next-property-change and make sure they are still going to work.

Re: question about narrowed behavior of next-property-change et al.

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     I think if there's no property change before (point-max), and the
>     user passed LIMIT == nil, then it should return nil, regardless of
>     whether (point-max) is due to narrowing or not.
> 
> It is certainly more logical that way--the question is, what will it
> break?  It would be necessary to check all the programs that use
> next-property-change and make sure they are still going to work.

Since the suggested change would only effect narrowed buffers, and only
to make them act more like a normal non-narrowed buffer, I would think
that only code that explicitly uses narrowing is potentially a problem
(under the assumption that a narrowed buffer should usually appear to
lisp code as if it were a normal buffer containing only the narrowed
region).

Since most code is written assume a `normal' buffer, I suspect the net
effect of the current wierd behavior is to cause problems with such code
expecting the usual non-narrowed behavior in the rare case where it is
used with a narrowed buffer.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: question about narrowed behavior of next-property-change et al.

[Richard Stallman]

    Since the suggested change would only effect narrowed buffers, and only
    to make them act more like a normal non-narrowed buffer, I would think
    that only code that explicitly uses narrowing is potentially a problem
    (under the assumption that a narrowed buffer should usually appear to
    lisp code as if it were a normal buffer containing only the narrowed
    region).

This reasoning is plausible indeed, but I still think that whoever
changes this should also check the callers one buy one.

Re: question about narrowed behavior of next-property-change et al.

[Stefan Monnier]

>     Since the suggested change would only effect narrowed buffers, and only
>     to make them act more like a normal non-narrowed buffer, I would think
>     that only code that explicitly uses narrowing is potentially a problem
>     (under the assumption that a narrowed buffer should usually appear to
>     lisp code as if it were a normal buffer containing only the narrowed
>     region).
> 
> This reasoning is plausible indeed, but I still think that whoever
> changes this should also check the callers one buy one.

Instead of spending this time, I'd rather bet $1000 that Miles's change will
not introduce any new bug: it might make an existing bug show up more
often, but introducing a new bug with his suggested change seems incredibly
unlikely.


	Stefan

Re: question about narrowed behavior of next-property-change et al.

[Richard Stallman]

    Instead of spending this time, I'd rather bet $1000 that Miles's change will
    not introduce any new bug:

Thanks for the offer, but I don't know who we could pay to do
this checking with that $1000.  It needs to be checked.

Re: question about narrowed behavior of next-property-change et al.

[Stefan Monnier]

>     Instead of spending this time, I'd rather bet $1000 that Miles's change will
>     not introduce any new bug:
> 
> Thanks for the offer, but I don't know who we could pay to do
> this checking with that $1000.  It needs to be checked.

No, it doesn't, because if you think about the possible case where
Miles's change can impact the behavior of code, you'll realize that
it can only do so for code that is already flawed.


	Stefan

Re: question about narrowed behavior of next-property-change et al.

[Miles Bader]

On Mon, Jan 27, 2003 at 08:33:32AM -0500, Stefan Monnier wrote:
> No, it doesn't, because if you think about the possible case where
> Miles's change can impact the behavior of code, you'll realize that
> it can only do so for code that is already flawed.

... and I suspect in most cases where it has any effect, it will to _fix_ a
(yet undiscovered) bug, rather than creating one.  So even without any
checking, the net effect is likely to be positive rather than negative.

I did a grep for "{next,prev}{,-single}-property-change" (which I think is
the set of functions effect), and there are over 200 occurances (most of
which are actually the `-single' variants).  This seems enough that doing any
kind of thorough check is a fair burden, and I really don't think it's worth
the time.

What about just doing some spot checks, just to see if there appear to be any
cases where the current undocumented behavior is relied upon?

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: question about narrowed behavior of next-property-change et al.

[Richard Stallman]

    I did a grep for "{next,prev}{,-single}-property-change" (which I think is
    the set of functions effect), and there are over 200 occurances (most of
    which are actually the `-single' variants).  This seems enough that doing any
    kind of thorough check is a fair burden, and I really don't think it's worth
    the time.

I think you can check them all in an hour.  Why not?