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: Clément Pit--Claudel
Subject: Re: forward-comment and syntax-ppss
Date: Thu, 8 Dec 2016 14:54:34 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 2016-12-08 14:31, Alan Mackenzie wrote:
>> Stefan and you are in a better position than I am to assess the
>> significance of that issue.  The only data point that I can share is
>> that I've found multiple packages to be broken by narrowing, to the
>> point that I don't use narrowing any more.
>
> That's tragic.  You clearly wanted to use narrowing, yet some bug, quite
> likely to be #22983, made narrowing such a bad experience that you
> stopped using it.  Did you raise any bug reports for these failures?

These are not Emacs bugs.  They are bugs in packages.  The most prominent one, 
which affects my day to day work, is in Proof General (which I have since then 
become a co-maintainer of).

The problem is simple.  Proof General locks portions of the source code that 
have been sent to an underlying interpreter/compiler.  This locking is achieved 
by placing read-only overlays spanning from (point-min) to the current point, 
every time a new region is sent.

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.

> Narrowing isn't "invasive", whatever that means.  It's such a natural and
> useful feature that it's surprising other editors haven't got it too.
> It's the pertinent bug (likely to be #22983) which has screwed up code
> when narrowing is used which is at fault, not narrowing itself.

Sorry to have been unclear.  Restricting the visible and editable portion of a 
buffer feels natural; but that's not what narrowing does: it makes it so that 
naively written code doesn't realize that there is anything outside of the 
narrowed region.  That's what I meant by "invasive": as a package writer, I 
must always be aware that (point-min)…(point-max) may only cover a subset of 
the buffer.

Clément.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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