From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Bug #25608 and the comment-cache branch Date: Tue, 7 Feb 2017 21:09:42 +0000 Message-ID: <20170207210942.GB2490@acm> References: <20170202202418.GA2505@acm> <9d0b3156-e8b2-c2d8-0d0c-a025861e5e0c@yandex.ru> <20170203164457.GB2250@acm> <20170204110259.GB2047@acm> <20170206200116.GD3568@acm> <834m066mu3.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1486501977 20441 195.159.176.226 (7 Feb 2017 21:12:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 21:12:57 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 07 22:12:53 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 1cbD4G-0004wF-EE for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 22:12:52 +0100 Original-Received: from localhost ([::1]:56398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbD4J-0001dQ-31 for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 16:12:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbD1c-0000Or-Dg for emacs-devel@gnu.org; Tue, 07 Feb 2017 16:10:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbD1Y-0000PS-6H for emacs-devel@gnu.org; Tue, 07 Feb 2017 16:10:08 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:18160 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cbD1X-0000Ov-S1 for emacs-devel@gnu.org; Tue, 07 Feb 2017 16:10:04 -0500 Original-Received: (qmail 73314 invoked by uid 3782); 7 Feb 2017 21:10:01 -0000 Original-Received: from acm.muc.de (p548C7312.dip0.t-ipconnect.de [84.140.115.18]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 07 Feb 2017 22:10:01 +0100 Original-Received: (qmail 13882 invoked by uid 1000); 7 Feb 2017 21:09:42 -0000 Content-Disposition: inline In-Reply-To: <834m066mu3.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 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:212113 Archived-At: Hello, Eli. On Tue, Feb 07, 2017 at 17:29:40 +0200, Eli Zaretskii wrote: > > Date: Mon, 6 Feb 2017 20:01:16 +0000 > > From: Alan Mackenzie > > Cc: emacs-devel@gnu.org > > The syntactic significance of a buffer position is not changed by > > any narrowing in force, no matter what the narrowing is "used for". > 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. > 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? > > That one or more multiple-mode attempts attempt to use narrowing that > > way is a fundamental problem in those modes which we should solve by > > providing a better method. > That's true, but it doesn't affect the basic fact that Emacs behaves > differently, and you cannot change that without significant changes on > levels below applications. > > Even if the user narrows to the string, it's still a string. > 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. 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? Is there any part of Emacs which depends on this way of recognising literals, and would that be badly hurt if literals came to be recognised by their global context (as syntax-ppss currently sort of does)? -- Alan Mackenzie (Nuremberg, Germany).