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.