unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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).



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