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: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution. Date: Sat, 25 Feb 2017 21:22:36 +0000 Message-ID: <20170225212236.GD2592@acm> References: <20170225135355.GA2592@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1488057793 9189 195.159.176.226 (25 Feb 2017 21:23:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2017 21:23:13 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 25 22:23:09 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 1chjo1-0001ZO-VM for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2017 22:23:06 +0100 Original-Received: from localhost ([::1]:44301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chjo7-0006Fn-Vk for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2017 16:23:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chjo2-0006FQ-00 for emacs-devel@gnu.org; Sat, 25 Feb 2017 16:23:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chjny-0005up-RQ for emacs-devel@gnu.org; Sat, 25 Feb 2017 16:23:05 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:57112 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1chjny-0005ud-GW for emacs-devel@gnu.org; Sat, 25 Feb 2017 16:23:02 -0500 Original-Received: (qmail 3468 invoked by uid 3782); 25 Feb 2017 21:23:01 -0000 Original-Received: from acm.muc.de (p4FC463DD.dip0.t-ipconnect.de [79.196.99.221]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 25 Feb 2017 22:23:00 +0100 Original-Received: (qmail 14342 invoked by uid 1000); 25 Feb 2017 21:22:36 -0000 Content-Disposition: inline In-Reply-To: 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:212599 Archived-At: Hello, Stefan On Sat, Feb 25, 2017 at 14:42:06 -0500, Stefan Monnier wrote: > Sounds fairly close to some of the ideas I toyed with. Excellent! > Here are a few comments: > > o - Ambiguity involved with narrowed regions - sometimes programs and > > users wish to see syntactic entities (e.g. strings, comments) as > > though point-min were a syntactically neutral position - other times > > they want the syntax to be relative to the beginning of the buffer. > I don't think this need is very serious for users. > So, I think we should focus on those cases where this is used by Elisp > code. I don't really see the distinction between users and code here. If we implement for one, it will work for the other, won't it? > > o - There will be two new syntax classes introduced for use in syntax > > table text properties: "island open" and "island close". Together, > > these enclose an "island", a region of the buffer syntactically > > disjoint from the text outside of the region. > [ 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. > I think we should try not to limit ourselves to nesting of islands. > IOW, we should strive to find a design where a single char can close an > island and open another one. That would need just a minor extension of what I set out, I think. Something like an "island swap" syntax class. This might find use in languages like lex and yacc. > > 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. > Stefan -- Alan Mackenzie (Nuremberg, Germany).