From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Bug #25608 and the comment-cache branch Date: Wed, 08 Feb 2017 19:28:46 +0200 Message-ID: <83a89w6181.fsf@gnu.org> References: <20170202202418.GA2505@acm> <9d0b3156-e8b2-c2d8-0d0c-a025861e5e0c@yandex.ru> <20170203164457.GB2250@acm> <20170204110259.GB2047@acm> <20170206200116.GD3568@acm> <834m066mu3.fsf@gnu.org> <20170207210942.GB2490@acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1486574949 2002 195.159.176.226 (8 Feb 2017 17:29:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2017 17:29:09 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 08 18:29:04 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbW38-0008RP-Uz for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2017 18:28:59 +0100 Original-Received: from localhost ([::1]:60675 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbW3D-00010Z-0N for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2017 12:29:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbW36-00010S-4y for emacs-devel@gnu.org; Wed, 08 Feb 2017 12:28:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbW32-0003dY-QH for emacs-devel@gnu.org; Wed, 08 Feb 2017 12:28:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbW32-0003dP-Nw; Wed, 08 Feb 2017 12:28:52 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2957 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cbW31-00010S-24; Wed, 08 Feb 2017 12:28:52 -0500 In-reply-to: <20170207210942.GB2490@acm> (message from Alan Mackenzie on Tue, 7 Feb 2017 21:09:42 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212139 Archived-At: > Date: Tue, 7 Feb 2017 21:09:42 +0000 > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Alan Mackenzie > > > 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.