RE: forward-comment and syntax-ppss

[Drew Adams <drew.adams@oracle.com>]

> > That's not the point of narrowing, even if it is one effect.
> > It's used to make some buffer contents inaccessible to certain
> > (many, typical, ordinary) operations.  It is not just you who
> > does not see parts of the buffer; it is also Emacs features
> > that do not perceive them.
> 
> Why should some facilities ignore narrowing, then? E.g.
> font-lock and indentation, which have traditionally done so.

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.

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

If some code deals with a narrowed buffer and it doesn't
really want to - if it instead really wants to pretend it
is not restricted, it's free to do that.  Not hard to do.

I think you're referring to contexts where some code
narrows the buffer (presumably for a good reason), and
some other code has to deal with that narrowed buffer
even though it does not want to.

That's a question of designing the two bits of code.  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.

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.

> > No one has given an example of how narrowing makes
> > things hard "for many other facilities" - or even
> > for one facility.
> 
> You haven't been paying attention.

Prove it.  See above.  I don't see a problem with
narrowing.  I do see that some code might mistakenly
think that the current buffer limits are the full
buffer limits, i.e., that it might mistakenly use
`point-min' when it should use 1.  That's not the
fault of narrowing or a problem introduced by narrowing.
It's a misunderstanding of what `point-min' is about.

There is also the problem of someone mistakenly
reusing code that _rightfully_ uses `point-min'
(because it wants the restriction limit, not 1).
That's not the fault of the reused code or of narrowing.
That's the fault of the reuser.

Some code is wrong.  People make mistakes when coding,
and not thinking that a buffer might be narrowed is
one possible mistake.  And not realizing that some
code one reuses intentionally acts differently when
the buffer is narrowed is another possible mistake.

Buffer restriction is the _general_ case.  An
unrestricted buffer is a special "restriction" case,
even if it is the more usual case.

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