RE: forward-comment and syntax-ppss

[Drew Adams]

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

Therein lies your mistake - mistaken assumption, perhaps.

Why should "the current code" call other code that widens,
and yet expect that it will _not_ widen?

The fault here is not from the "other code" narrowing or
widening.  It is from the "current code" calling such
"other code".  Code needs to choose wisely any "other code"
that it tries to use.

IOW, this sounds a lot like a case where the doctor should
tell you, "If it hurts, stop doing that."

But if the called code is indeed defective - if it should
in fact restore the initial buffer restriction after it
widens or narrows to do its work, then that should be
fixed.  That's no reason to say that it should never
widen or narrow.

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

Why?  If you call a function in your code, regardless of who
wrote that function, you need to know what it does, no?

And in particular, you need to know how it handles a buffer
restriction - at least if you are _counting on_ some particular
behavior wrt that.  You need to know whether you need to wrap
its call (or some other bits of your code) in `save-restriction',
for example.

Or to otherwise set and save some restriction limits, and then
restore them at the proper time.  Restriction limits are just
buffer positions.  Setting and saving them is not rocket science.

This is similar to knowing whether called code moves point or
changes which buffer is current or which window is selected or...

It sounds like you are complaining that when you use function
`abcde' it doesn't behave as you would like.  Maybe consider
not trying to expect it to do something that it does not do?

Or (again) if the code being called is defective, and it should
really restore the initial restriction, then fix that.

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

What do you mean by "respect your narrowing"?  If you mean
that there is no way to prevent called code from applying
a different buffer restriction (including widening completely),
then, well, duh!

Just as there is no way to prevent it from assigning a different
value to a variable that is visible to it.  Or to prevent it
from changing the current buffer (and even leaving it changed),
or the selected window.  Or any number of other things.

If code that you're thinking about calling from your code does
something you do not want, then, well, don't call it.  Call
some other code - maybe write your own, possibly enhance the
code you were thinking about calling unwisely,...

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

That's one way to evacuate the discussion...  How about:
If you still see a problem, and you cannot articulate it,
good luck with that.

If you think it is important enough, perhaps speak concretely,
in terms of particular code.  Show a case where something
really needs to be changed in Emacs, because there is an
inherent problem.

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

What "actual problem cases"?