Re: forward-comment and syntax-ppss

[Dmitry Gutov]

On 16.12.2016 18:22, Drew Adams wrote:

> I said "certain...operations".  You said "some facilities".
> I did not say that _every_ operation/facility needs or
> takes advantage of such text inaccessibility.  Those that
> instead want to ignore narrowing do so.  No problem.

The facilities do not "want", they can't make these choices for us. The 
difficulty is in deciding which Lisp code should ignore narrowing, and 
which shouldn't.

And also, for each arbitrary piece of code, for the programmer to 
remember to make that choice.

> That narrowing restricts the buffer limits is its effect.
> Code can use that effect to any purpose it wants.

Except if the other code, which the current code wants to call inside a 
narrowing (and respect that narrowing!), always widens.

> That's a question of designing the two bits of code.

Because that's never difficult.

And if only all code was written by one person.

> The
> latter bit is working with what the former bit dishes out.
> It has choices for how to deal with it, one of which is to
> `save-restriction', then `widen' and do its
> ignore-the-restriction thing.

That only helps to retain the narrowing bounds for the caller code.

> See my reply to Clément for the case of reusing code that
> is broken because it does not expect `point-min' to refer
> to a buffer-restriction limit.

It's not enough to know what the code you're reusing does, if there's no 
way to make that code respect your narrowing.

> > You haven't been paying attention.
>
> Prove it.  See above.  I don't see a problem with
> narrowing.

We've had numerous discussions on this subject already. If you still 
don't see any problem, good luck with that.

> Maybe we need to beef up the doc of `point-min', to
> emphasize that it is the lower _buffer-restriction_
> limit.  And maybe some users need to better document
> their functions, to make it clear when they respect a
> narrowed buffer (as the Isearch doc makes clear, for
> instance).

Neither of that helps in the actual problem cases.