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: Sun, 26 Feb 2017 16:37:24 +0000 Message-ID: <20170226163724.GD3811@acm> References: <20170225135355.GA2592@acm> <20170225212236.GD2592@acm> <20170226120656.GA3811@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1488127126 16423 195.159.176.226 (26 Feb 2017 16:38:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 16:38:46 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 26 17:38:43 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 1ci1qJ-000310-W0 for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 17:38:40 +0100 Original-Received: from localhost ([::1]:47451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ci1qL-0006XK-A9 for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 11:38:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ci1pb-0006XE-NJ for emacs-devel@gnu.org; Sun, 26 Feb 2017 11:37:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ci1pY-000126-JB for emacs-devel@gnu.org; Sun, 26 Feb 2017 11:37:55 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:41219 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ci1pY-00011u-9O for emacs-devel@gnu.org; Sun, 26 Feb 2017 11:37:52 -0500 Original-Received: (qmail 8781 invoked by uid 3782); 26 Feb 2017 16:37:49 -0000 Original-Received: from acm.muc.de (p548C6C97.dip0.t-ipconnect.de [84.140.108.151]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 26 Feb 2017 17:37:48 +0100 Original-Received: (qmail 5729 invoked by uid 1000); 26 Feb 2017 16:37:24 -0000 Content-Disposition: inline In-Reply-To: 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:212613 Archived-At: 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).