all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution.
Date: Sun, 26 Feb 2017 08:47:55 -0500	[thread overview]
Message-ID: <jwvo9xpjco7.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: 20170226120656.GA3811@acm

>> > 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).

>> > 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.

>> (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.  AFAICT in your currently suggested solution you have
no other way to get that behavior than to "create" an island.

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.

> 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.


        Stefan




  parent reply	other threads:[~2017-02-26 13:47 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 [this message]
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

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvo9xpjco7.fsf-monnier+gmane.emacs.devel@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.