From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes: some design notes Date: Sat, 23 Apr 2016 17:31:44 +0000 Message-ID: <20160423173144.GD4624@acm.fritz.box> References: <20160420194450.GA3457@acm.fritz.box> <20160422202224.GC1873@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1461432736 13044 80.91.229.3 (23 Apr 2016 17:32:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Apr 2016 17:32:16 +0000 (UTC) Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 23 19:32:05 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1au1PZ-0004Nm-Af for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2016 19:32:05 +0200 Original-Received: from localhost ([::1]:53085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au1PY-0008GR-MX for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2016 13:32:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au1PJ-0008Cs-Jv for emacs-devel@gnu.org; Sat, 23 Apr 2016 13:31:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1au1PH-0007Ov-Sa for emacs-devel@gnu.org; Sat, 23 Apr 2016 13:31:49 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:55045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au1PH-0007Na-K4 for emacs-devel@gnu.org; Sat, 23 Apr 2016 13:31:47 -0400 Original-Received: (qmail 67612 invoked by uid 3782); 23 Apr 2016 17:31:45 -0000 Original-Received: from acm.muc.de (p579E8F13.dip0.t-ipconnect.de [87.158.143.19]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 23 Apr 2016 19:31:43 +0200 Original-Received: (qmail 5244 invoked by uid 1000); 23 Apr 2016 17:31:44 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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 X-Received-From: 193.149.48.3 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:203219 Archived-At: Hello, Richard. On Sat, Apr 23, 2016 at 08:38:04AM -0400, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Are you saying that there won't be a character with the "open island" > in the syntax table, but rather a text property will give a particular > string in the buffer the "open island" syntax? Yes. I think it would most unwise to assign a character such a syntax in the syntax table - the island boundaries would be unstable, existing or not existing depending on the syntax table of the island one was currently in. I anticipate writing a warning about this in the Emacs Lisp manual. > That makes more sense. But I think that in some cases "separate > islands" might be a better designation. For instance, consider the > three sections of a Bison input file. They are separated by a > delimiter. It would be artificial and arbitrary to try to divide up > the delimiter into a string to end the previous island and a string to > start the next one. I think Bison and Lex are somewhat special cases; they each divide a file into three sections of equal status, rather than there being a containing mode and sections contained within it. > Which reminds me that the first island in the Bison input file > has no string to "open" it. It starts at the start of the buffer. > And the third island ends and the end of the buffer. A workaround for this would be to have the first section being the "super mode" and containing the second and third sections. The delimiter "%%" between sections 2 and 3 has space to hold both an island close and an island open, despite what you say about this being artificial, etc. I don't see there would be an absolute need for there to be a "close island" mark at the end of the buffer. > -- > Dr Richard Stallman > President, Free Software Foundation (gnu.org, fsf.org) > Internet Hall-of-Famer (internethalloffame.org) > Skype: No way! See stallman.org/skype.html. -- Alan Mackenzie (Nuremberg, Germany).