emacs-devel
[Top][All Lists]
Advanced

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

Re: Bug #25608 and the comment-cache branch


From: Eli Zaretskii
Subject: Re: Bug #25608 and the comment-cache branch
Date: Wed, 08 Feb 2017 19:28:46 +0200

> Date: Tue, 7 Feb 2017 21:09:42 +0000
> Cc: address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > If that's what you think, you are not talking about Emacs.  Emacs
> > always behaved as if nothing existed outside of the current
> > narrowing.
> 
> Not consistently.  Font lock, in all the modes I'm aware of, does not
> invert its "stringiness" when point-min lies within a string.

There are a few exceptions, yes.  But mostly what I described is
accurate.

> > Even the display engine behaves like that: e.g., by suitable narrowing
> > of bidirectional text you can completely change how the accessible
> > portion is displayed.
> 
> Is this a deliberate design decision, or is it simply what tumbled out
> after bidi was implemented in the easiest and most natural fashion?

It isn't related to bidi in any way, it's how the display engine
behaved since day one, long before I started coding the bidirectional
support.  I just left that aspect alone and didn't change it.

> > Emacs currently doesn't have any means of knowing that, because the
> > portions of the buffer outside the accessible region are simply not
> > accessible.
> 
> As you know, I've implemented a scheme by which Emacs can know this.

Dmitry's point is exactly that a solution to these issues will also
resolve some bugs related to CC mode, which you tried to solve in your
branch.  I tend to agree with Dmitry that narrowing and its effect on
Emacs internals is a separate problem that needs to be solved in a
more general way than just in CC mode or thereabouts.

> Up till now, recognition of literals has been done solely by the local
> context, probably because it was easier to implement this way rather
> than any deep design decision.  Or am I wrong here?

I think it isn't an accident.  There's a deeper issue here: if some
portion of the buffer is inaccessible to user-level commands, it might
be confusing if some features would internally behave as if the
restriction didn't exist, at least in general.

Finding a solution for this which doesn't introduce the confusion is a
challenge.



reply via email to

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