unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Tom Tromey <tom@tromey.com>
Cc: emacs-devel@gnu.org
Subject: Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution.
Date: Fri, 24 Mar 2017 23:41:25 +0000	[thread overview]
Message-ID: <20170324234125.GC2254@acm> (raw)
In-Reply-To: <87y3wkj0d8.fsf@tromey.com>

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 <acm@muc.de> 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).



      reply	other threads:[~2017-03-24 23:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-25 13:53 Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution Alan Mackenzie
2017-02-25 19:42 ` 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 [this message]

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=20170324234125.GC2254@acm \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=tom@tromey.com \
    /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).