[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: forward-comment and syntax-ppss
From: |
Drew Adams |
Subject: |
RE: forward-comment and syntax-ppss |
Date: |
Fri, 16 Dec 2016 08:22:45 -0800 (PST) |
> >> Thus, without making things harder for many other facilities.
> > No one has given an example of how narrowing makes things
> > hard "for many other facilities" - or even for one facility.
>
> I think I gave one example of how narrowing breaks proof-general; in fact, I
> explained I developed my own alternative to narrowing with overlays because
> other packages broke in the face of regular narrowing.
"Narrowing breaks proof-general". Really? Narrowing did that?
This is all I saw that you said about it:
There are many such places; unfortunately, the use of (point-min)
means that the overlays do not have the right starting point:
they start from the beginning of the narrowed region.
It's hard to fix this issue, because uses of point-min don't
carry sufficient semantic information: did the original author
mean (point-min), or 1? There's no general way to tell but to
read the surrounding code.
IIUC, the problem is that p-g makes use of some code that uses
`point-min', and p-g does not know whether that code intended
for `point-min' to mean the start of a buffer restriction or
position 1 of the buffer.
My answer to that is that `point-min' ALWAYS means the start
of the buffer restriction (narrowing), if it is restricted.
If p-g cannot count on that then it cannot count on using
code that doesn't understand that. It should know what code
that it reuses does; if not, all bets are off.
It sounds like it is not narrowing that broke p-g, but its
use of some broken code that uses `point-min' without
understanding that it refers to the beginning of a buffer
restriction. Or perhaps p-g just does not know what the
code it reuses does.
For p-g to decide whether it should `widen', it should be
enough for it to know whether _it_ wants to work with the
full buffer. If it tries to reuse some other code that is
flakey or unsure in that regard, then I'd say that p-g is
breaking itself.
Code that uses `point-min' should always expect that the
buffer is (because it could be) narrowed. It should never
assume that `point-min' is necessarily position 1.
Am I missing something?
- Re: forward-comment and syntax-ppss, (continued)
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/16
- Re: forward-comment and syntax-ppss, Alan Mackenzie, 2016/12/16
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16
- Re: forward-comment and syntax-ppss, Stefan Monnier, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16
- Re: forward-comment and syntax-ppss, Stefan Monnier, 2016/12/17
- Re: forward-comment and syntax-ppss, Clément Pit--Claudel, 2016/12/16
- RE: forward-comment and syntax-ppss,
Drew Adams <=
- Re: forward-comment and syntax-ppss, Clément Pit--Claudel, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16
- Re: forward-comment and syntax-ppss, Clément Pit--Claudel, 2016/12/16
- Wording of the Elisp manuals (was: forward-comment and syntax-ppss), Marcin Borkowski, 2016/12/16
- Re: Wording of the Elisp manuals, Michael Heerdegen, 2016/12/20
- Re: Wording of the Elisp manuals (was: forward-comment and syntax-ppss), Jean-Christophe Helary, 2016/12/20
- Re: Wording of the Elisp manuals (was: forward-comment and syntax-ppss), Eli Zaretskii, 2016/12/20
- Re: forward-comment and syntax-ppss, Alan Mackenzie, 2016/12/16
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16