emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forward-comment and syntax-ppss


From: Dmitry Gutov
Subject: Re: forward-comment and syntax-ppss
Date: Fri, 16 Dec 2016 21:14:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]