all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Richard Stallman <rms@gnu.org>
Cc: dgutov@yandex.ru, emacs-devel@gnu.org
Subject: Re: A vision for multiple major modes: some design notes
Date: Sat, 23 Apr 2016 17:31:44 +0000	[thread overview]
Message-ID: <20160423173144.GD4624@acm.fritz.box> (raw)
In-Reply-To: <E1atwp2-0000qj-UW@fencepost.gnu.org>

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).



  reply	other threads:[~2016-04-23 17:31 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 19:44 A vision for multiple major modes: some design notes Alan Mackenzie
2016-04-20 21:06 ` Drew Adams
2016-04-20 23:00   ` Drew Adams
2016-04-21 12:43   ` Alan Mackenzie
2016-04-21 14:24     ` Stefan Monnier
2016-04-23  2:20       ` zhanghj
2016-04-23 22:36       ` Dmitry Gutov
2016-04-21 16:05     ` Drew Adams
2016-04-21 16:31       ` Eli Zaretskii
     [not found]     ` <<64f1d39a-dfd0-44ca-86c1-b4d6104b5702@default>
     [not found]       ` <<83oa926i0e.fsf@gnu.org>
2016-04-21 16:59         ` Drew Adams
2016-04-21 19:55           ` Eli Zaretskii
     [not found]     ` <<<64f1d39a-dfd0-44ca-86c1-b4d6104b5702@default>
     [not found]       ` <<<83oa926i0e.fsf@gnu.org>
     [not found]         ` <<791d74d1-2b1d-4304-8e7e-d6c31af7aa41@default>
     [not found]           ` <<83eg9y68jy.fsf@gnu.org>
2016-04-21 20:26             ` Drew Adams
2016-04-20 22:27 ` Phillip Lord
2016-04-21  9:14   ` Alan Mackenzie
2016-04-22 12:45     ` Phillip Lord
2016-04-21 14:17 ` Eli Zaretskii
2016-04-21 21:33   ` Alan Mackenzie
2016-04-21 22:01     ` Drew Adams
2016-04-22  8:13       ` Alan Mackenzie
2016-04-22 17:04         ` Drew Adams
2016-04-22  9:04     ` Eli Zaretskii
2016-06-13 21:17     ` John Wiegley
2016-06-14 13:13       ` Alan Mackenzie
2016-06-14 16:27         ` John Wiegley
2016-04-21 22:19   ` Alan Mackenzie
2016-04-22  8:48     ` Eli Zaretskii
2016-04-22 22:35       ` Alan Mackenzie
2016-04-23  7:39         ` Eli Zaretskii
2016-04-23 17:02           ` Alan Mackenzie
2016-04-23 18:12             ` Eli Zaretskii
2016-04-23 18:26               ` Dmitry Gutov
2016-04-23 21:08               ` Alan Mackenzie
2016-04-24  6:29                 ` Eli Zaretskii
2016-04-24 16:57                   ` Alan Mackenzie
2016-04-24 19:59                     ` Eli Zaretskii
2016-04-25  6:49                       ` Andreas Röhler
2016-04-22 13:42     ` Andy Moreton
2016-04-23 17:14       ` Alan Mackenzie
2016-04-22 14:33 ` Dmitry Gutov
2016-04-22 18:58 ` Richard Stallman
2016-04-22 20:22   ` Alan Mackenzie
2016-04-23 12:27     ` Andreas Röhler
2016-04-23 12:38     ` Richard Stallman
2016-04-23 17:31       ` Alan Mackenzie [this message]
2016-04-24  9:22         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160423173144.GD4624@acm.fritz.box \
    --to=acm@muc.de \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.