From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution. Date: Sat, 25 Feb 2017 21:32:49 -0500 Message-ID: References: <20170225135355.GA2592@acm> <20170225212236.GD2592@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488076433 15583 195.159.176.226 (26 Feb 2017 02:33:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 02:33:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 26 03:33:47 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 1choec-0002pd-C5 for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 03:33:42 +0100 Original-Received: from localhost ([::1]:45045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1choee-0001c1-Qx for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2017 21:33:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1choe5-0001bk-1C for emacs-devel@gnu.org; Sat, 25 Feb 2017 21:33:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1choe1-0007tj-Sh for emacs-devel@gnu.org; Sat, 25 Feb 2017 21:33:09 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:62395) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1choe1-0007tP-Na for emacs-devel@gnu.org; Sat, 25 Feb 2017 21:33:05 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiCADDPbJY/93njBhdGgEBAQECAQEBAQgBAQEBg1CKTZZeEJcyhiICghBDFAECAQEBAQEBAWIohHEBBAF5BQsLDQEmEhQYMS6JUQixLCYCiwsBCwElizuKOQWQUItOihiSSyaGNpMxNiGBASEUCCyFQ4FmIosAAQEB X-IPAS-Result: A0AiCADDPbJY/93njBhdGgEBAQECAQEBAQgBAQEBg1CKTZZeEJcyhiICghBDFAECAQEBAQEBAWIohHEBBAF5BQsLDQEmEhQYMS6JUQixLCYCiwsBCwElizuKOQWQUItOihiSSyaGNpMxNiGBASEUCCyFQ4FmIosAAQEB X-IronPort-AV: E=Sophos;i="5.35,205,1484024400"; d="scan'208";a="293805705" Original-Received: from unknown (HELO fmsmemgm.homelinux.net) ([24.140.231.221]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2017 21:33:01 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id A187DAE4C0; Sat, 25 Feb 2017 21:32:49 -0500 (EST) In-Reply-To: <20170225212236.GD2592@acm> (Alan Mackenzie's message of "Sat, 25 Feb 2017 21:22:36 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:212602 Archived-At: > I don't really see the distinction between users and code here. I think the details are very different: in Elisp code, it's typically combined with save-restriction, it's short lived, and performance is fairly important. For C-x n n none of those three aspects apply. > If we implement for one, it will work for the other, won't it? It's quite likely that if we can make it work for Elisp, we can also make it work satisfactorily for C-x n n. But the other way around is not necessarily true, I think. >> [ I like to consider that strings and comments are also a form of >> "island", although we're probably better off supporting them in >> a special way like we do now. ] > I think that's just confusing the meaning of "island", which I'd like to > keep clear and unambiguous. Something to be decided is how we'd handle > an island within a comment or string. Suit yourself. I find it to be a good way to think about it. I don't see why an island within a comment/string should need any special treatment. Just like an island within an island. >> > o - narrow-to-region will be given an optional argument which, if set, >> > directs Emacs to make the new region an island. Thus, C-u C-x n n >> > would enable a user to narrow to a "comment within a string" and edit >> > it as though it were a comment. >> How would this work (especially for uses from Elisp)? >> Would it set syntax-table text-properties? > Yes, it would. It would put an island open syntax-table property on the > character before START, and and island close on the character after END. > This would isolate the region syntactically from its surroudings. I don't think that's going to be fast enough, then. I'm thinking of cases where current Elisp code does something like (save-restriction (narrow-to-region ...) (with-syntax-table ... (backward-sexp 1))) in order to efficiently jump over a small element (e.g. an SGML tag) and may very well want to do this within a loop. This usage doesn't correspond to an island, really and shouldn't cause caches to be flushed. Stefan