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: 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?



reply via email to

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