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: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution. Date: Sat, 25 Feb 2017 13:53:56 +0000 Message-ID: <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 1488030913 23191 195.159.176.226 (25 Feb 2017 13:55:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2017 13:55:13 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 25 14:55: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 1chcoX-0005Nc-0i for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2017 14:55:09 +0100 Original-Received: from localhost ([::1]:42814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chcob-0000YI-9U for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2017 08:55:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chcnx-0000Wy-LJ for emacs-devel@gnu.org; Sat, 25 Feb 2017 08:54:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chcnm-0007Ga-HB for emacs-devel@gnu.org; Sat, 25 Feb 2017 08:54:27 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:59364 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1chcnm-0007GT-Au for emacs-devel@gnu.org; Sat, 25 Feb 2017 08:54:22 -0500 Original-Received: (qmail 8362 invoked by uid 3782); 25 Feb 2017 13:54:19 -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 14:54:19 +0100 Original-Received: (qmail 4774 invoked by uid 1000); 25 Feb 2017 13:53:56 -0000 Content-Disposition: inline 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:212595 Archived-At: 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).