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: Tue, 07 Feb 2017 17:29:40 +0200 Message-ID: <834m066mu3.fsf@gnu.org> References: <20170202202418.GA2505@acm> <9d0b3156-e8b2-c2d8-0d0c-a025861e5e0c@yandex.ru> <20170203164457.GB2250@acm> <20170204110259.GB2047@acm> <20170206200116.GD3568@acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1486481449 1523 195.159.176.226 (7 Feb 2017 15:30:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 15:30:49 +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 Tue Feb 07 16:30:46 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 1cb7jB-00009u-1J for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 16:30:45 +0100 Original-Received: from localhost ([::1]:54849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cb7jG-0005dU-Hi for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 10:30:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cb7iD-0004mm-0G for emacs-devel@gnu.org; Tue, 07 Feb 2017 10:29:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cb7i9-0008Vt-VJ for emacs-devel@gnu.org; Tue, 07 Feb 2017 10:29:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cb7i9-0008Vp-Sq; Tue, 07 Feb 2017 10:29:41 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1716 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cb7i9-0005ZV-4k; Tue, 07 Feb 2017 10:29:41 -0500 In-reply-to: <20170206200116.GD3568@acm> (message from Alan Mackenzie on Mon, 6 Feb 2017 20:01:16 +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:212097 Archived-At: > 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. 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. > 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.