emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Syntax ambiguities in narrowed buffers and multiple major modes: a p


From: Alan Mackenzie
Subject: Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution.
Date: Fri, 24 Mar 2017 23:41:25 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

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 <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]