[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: |
Sun, 26 Feb 2017 16:37:24 +0000 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
Hello, Stefan.
On Sun, Feb 26, 2017 at 08:47:55 -0500, Stefan Monnier wrote:
> >> > I don't really see the distinction between users and code here.
> >> I think the details are very different: in Elisp code, it's typically
> >> combined with save-restriction, it's short lived, and performance is
> >> fairly important. For C-x n n none of those three aspects apply.
> > Sorry, I've lost the thread, here. The original point was that there is
> > currently an ambiguity in narrowed regions - that sometimes the
> > code/user wants to treat point-min as a syntactically neutral point,
> > other times it wants beginning of buffer to be that neutral point.
> > I think you've moved onto talking about something else, without saying
> > exactly what that something else is.
> Hmm... no, that's exactly what I'm talking about. I'm pointing out that
> cases where Elisp code uses narrowing is technically quite different
> from cases where `C-x n n` is used. In both cases, there is an
> ambiguity (i.e. some uses expect syntax to start at point-min others at
> 1).
OK. Resolving that ambiguity is what my proposal will do.
> >> > If we implement for one, it will work for the other, won't it?
> >> It's quite likely that if we can make it ...
> > "it" has no referent. What is "it"?
> The same as your "it", AFAIK (i.e. "it will work" meaning something like
> "we provide a way for the user/code to tell Emacs where syntax starts").
> >> Suit yourself. I find it to be a good way to think about it.
> > In that case, we'd need some other term to mean what I'm calling an
> > "island", i.e. a region of buffer bounded by island open/close
> > syntax-table text properties, possibly with its own syntax table, which
> > is syntactically disjoint from the surrounding buffer pieces.
> No, as I said, it's just a way to think about the *problem*. In the
> actual solution/API/implementation we'l probably still want to treat
> strings/comments specially rather than as islands.
I am proposing implementing islands as a solution to the problem, not as
a way of thinking about it.
> >> (save-restriction
> >> (narrow-to-region ...)
> >> (with-syntax-table ...
> >> (backward-sexp 1)))
> >> in order to efficiently jump over a small element (e.g. an SGML tag) and
> >> may very well want to do this within a loop.
> > Is there any need in that example for the narrow-to-region call to
> > create an island[*]?
> "create"? As such, no.
> But the issue is that the syntax beginning in the above example should be
> point-min, not 1.
Should it? Why? Are you positing this as a possibility, or are you
saying that in this code, the syntax beginning must always definitely
begin at point-min.
When does it actually make a difference, apart from when point-min is
inside a string or a comment? I don't think it makes a difference in
the (backward-sexp 1) case above.
> AFAICT in your currently suggested solution you have no other way to
> get that behavior than to "create" an island.
That is correct. The creation of an island will not be an expensive
action, unless it is in a tight loop - recording two current syntactic
elements, and calculating and setting two syntax-table text properties;
then restoring these later.
> BTW, I'm quite willing to tell authors that the above chunk of code
> needs to be rewritten with a new macro, if that can help.
Thanks.
> > I don't think that code would normally need an island. But the caches
> > (in particular, the syntax-ppss cache) are invalid inside the
> > with-syntax-table form anyway, and in the general case that has to be
> > dealt with somehow.
> Right. But I think we need to resolve this "somehow" as part of the
> new "island" design.
Do we? This is more a problem with syntax-ppss, which needs resolving
regardless of whether or not islands get implemented.
In the case where an island is a permanent feature of a buffer with its
own syntax table, the syntax-ppss cache would not become invalid on
scanning past the island open position.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Alan Mackenzie, 2017/02/25
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Stefan Monnier, 2017/02/25
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Alan Mackenzie, 2017/02/25
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Stefan Monnier, 2017/02/26
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution.,
Alan Mackenzie <=
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Stefan Monnier, 2017/02/26
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Alan Mackenzie, 2017/02/27
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Stefan Monnier, 2017/02/27
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Stefan Monnier, 2017/02/27
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Dmitry Gutov, 2017/02/27
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Alan Mackenzie, 2017/02/28
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Stefan Monnier, 2017/02/28
- Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution., Alan Mackenzie, 2017/02/28