From: Alan Mackenzie <acm@muc.de>
To: emacs-devel@gnu.org
Subject: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution.
Date: Sat, 25 Feb 2017 13:53:56 +0000 [thread overview]
Message-ID: <20170225135355.GA2592@acm> (raw)
Hello, Emacs.
This post proposes a method of coding up syntactic "islands" as a
solution to various syntactic problems in the current Emacs. It aims to
address the various problems raised in the thread Subject: Bug #25608
and the comment-cache branch.
(i) Problems:
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.
o - Multiple major modes - each submode region should start
syntactically at a syntactically neutral position, regardless of the
syntactic context of the enclosing supermode. This region should be
able to have its own syntax table.
(ii) Proposed solution - islands.
o - By default, in a narrowed region, the syntactic context of a
position will be that relative to BOB.
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.
o - An island open syntax class will have, in place of the matching
character argument (used by open/close parenthesis classes), a list
argument containing:
* - the (optional) syntax table for the island;
* - the "previous syntax" of the position, which has been overwritten
by the island open class syntax-table text property.
* - Possible further items.
o - An island close syntax class will have, in place of the
matching character argument, a list containing:
* - The "previous syntax" of the position.
* - Possible further items.
(iii) Effect on parse-partial-sexp/syntax-ppss.
o - The 10-element parser state would become a stack of parser states.
o - Each time parse-partial-sexp encounters an island open, it pushes
the current state, including the syntax table, onto this stack,
reinitialises the state, and optionally sets the syntax table, for
the island just being opened. The island begins at the buffer
position _after_ the one bearing the island open syntax.
o - Each time parse-partial-sexp encounters an island close, it pops
the suspended state, including the syntax table, off the stack of
states. (If there is no stacked state, the function stops at this
point, somewhat analagously to reaching the end of buffer.)
o - parse-partial-sexp would be amended to allow the caller to direct
the parsing to stop at the end (and possibly beginning) of an island,
much as it currently does for strings and comments.
(iv) Modification of certain commands and functions.
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.
o - A new function would be needed to get the "base" syntax of a
position, the syntax it would have if it weren't for any island
open/close syntax table properties on it.
o - forward-comment will need to cope, one way or another, with the
possibility of an island inside a comment. Several other scanning
commands will likewise need amendment.
(v) Advantages of this proposal.
o - The ambiguity in narrowed regions would be resolved without loss of
functionality.
o - The fact that the syntactic context is always global in a buffer
facilitates the building and manipulation of syntax caches (of
whatever nature).
o - Multiple major mode modes could be implemented without abusing the
narrowing mechanism.
--
Alan Mackenzie (Nuremberg, Germany).
next reply other threads:[~2017-02-25 13:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-25 13:53 Alan Mackenzie [this message]
2017-02-25 19:42 ` Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution Stefan Monnier
2017-02-25 21:22 ` Alan Mackenzie
2017-02-26 2:32 ` Stefan Monnier
2017-02-26 12:06 ` Alan Mackenzie
2017-02-26 12:24 ` Yuri Khan
2017-02-26 16:10 ` Alan Mackenzie
2017-02-26 13:47 ` Stefan Monnier
2017-02-26 16:37 ` Alan Mackenzie
2017-02-27 4:05 ` Stefan Monnier
2017-02-27 19:05 ` Alan Mackenzie
2017-02-27 20:52 ` Stefan Monnier
2017-02-27 23:22 ` Stefan Monnier
2017-02-27 23:48 ` Dmitry Gutov
2017-02-28 18:58 ` Alan Mackenzie
2017-02-28 19:09 ` Stefan Monnier
2017-02-28 20:27 ` Alan Mackenzie
2017-03-02 22:28 ` Alan Mackenzie
2017-03-03 12:47 ` Filipp Gunbin
2017-03-04 19:41 ` Tom Tromey
2017-03-24 23:41 ` Alan Mackenzie
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170225135355.GA2592@acm \
--to=acm@muc.de \
--cc=emacs-devel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).