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: Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution. Date: Fri, 24 Mar 2017 23:41:25 +0000 Message-ID: <20170324234125.GC2254@acm> References: <20170225135355.GA2592@acm> <87y3wkj0d8.fsf@tromey.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1490398938 6945 195.159.176.226 (24 Mar 2017 23:42:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Mar 2017 23:42:18 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 25 00:42:14 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 1crYqN-0000c7-9Y for ged-emacs-devel@m.gmane.org; Sat, 25 Mar 2017 00:42:07 +0100 Original-Received: from localhost ([::1]:35316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crYqT-00019u-3b for ged-emacs-devel@m.gmane.org; Fri, 24 Mar 2017 19:42:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crYqM-00019k-SZ for emacs-devel@gnu.org; Fri, 24 Mar 2017 19:42:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1crYqI-0008AR-Rv for emacs-devel@gnu.org; Fri, 24 Mar 2017 19:42:06 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:24214 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1crYqI-0008AF-HT for emacs-devel@gnu.org; Fri, 24 Mar 2017 19:42:02 -0400 Original-Received: (qmail 24396 invoked by uid 3782); 24 Mar 2017 23:42:01 -0000 Original-Received: from acm.muc.de (p548C6C41.dip0.t-ipconnect.de [84.140.108.65]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 25 Mar 2017 00:42:00 +0100 Original-Received: (qmail 7059 invoked by uid 1000); 24 Mar 2017 23:41:25 -0000 Content-Disposition: inline In-Reply-To: <87y3wkj0d8.fsf@tromey.com> 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:213323 Archived-At: Hello, Tom. I know it's almost three weeks ago, but.... On Sat, Mar 04, 2017 at 12:41:23 -0700, Tom Tromey wrote: > >>>>> "Alan" == Alan Mackenzie writes: > Alan> o - Each time parse-partial-sexp encounters an island open, it pushes > Alan> the current state, including the syntax table, onto this stack, > Alan> reinitialises the state, and optionally sets the syntax table, for > Alan> the island just being opened. The island begins at the buffer > Alan> position _after_ the one bearing the island open syntax. > This approach means that an island can't start at the beginning of a > buffer. I don't have an example offhand where this matters, but it > seems like an arbitrary restriction, and furthermore one not imposed by > the current approach of having syntax table property on the affected > characters. Maybe an island could be delimited in this same way, that > is, an island would be a contiguous group of characters that have a > property ('island, or whatever) with the same value. I've been thinking about this. One problem would be temporarily putting an island in the middle of another one. When the time came to remove that enclosed island, the 'island property would need to be restored, somehow. It might get messy if a "temporary" island T crosses the boundary between "permanent" islands, A and B, like this: ..........AAAAAAAAAAAAAAAABBBBBBBBBBBBB............. TTTTTTTTTT . It's the difference between marking end points, and covering an interval. In the first, the markers take up space; in the second what gets covered sometimes needs uncovering. I think this could work, but needs more thought. > Alan> o - A new function would be needed to get the "base" syntax of a > Alan> position, the syntax it would have if it weren't for any island > Alan> open/close syntax table properties on it. > Would you mind giving an example of what this would be used for? It was something Dmitry said a few weeks back, which I can't quite remember. It was something to do with an island ending at an EOL, which would have the EOL's syntax superseded by an island close, thus damaging other code which needs to see the EOL's syntax rather than the island close syntax. Maybe a better way to implement islands would be to have new text properties to mark their boundaries rather than extending 'syntax-table. The syntax code would recognise and handle the new 'island-open property, yet this wouldn't obliterate the "base" syntax of a position. This way, it might be possible to have the island beginning at the position the 'island-open property is on, and ending at the 'island-close property. That would allow islands as small as two character positions. It might even allow us islands as small as a single character position, if we can put 'island-open and 'island-close on the same character position. Or something like that. > Tom -- Alan Mackenzie (Nuremberg, Germany).