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 12:06:57 +0000 Message-ID: <20170226120656.GA3811@acm> References: <20170225135355.GA2592@acm> <20170225212236.GD2592@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1488110884 17112 195.159.176.226 (26 Feb 2017 12:08:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 12:08:04 +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 13:08:00 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 1chxcJ-0003gk-K8 for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 13:07:55 +0100 Original-Received: from localhost ([::1]:46133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chxcP-000612-DE for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 07:08:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chxbr-00060w-1l for emacs-devel@gnu.org; Sun, 26 Feb 2017 07:07:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chxbn-0007zT-RJ for emacs-devel@gnu.org; Sun, 26 Feb 2017 07:07:27 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:25645 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1chxbn-0007z6-LD for emacs-devel@gnu.org; Sun, 26 Feb 2017 07:07:23 -0500 Original-Received: (qmail 42893 invoked by uid 3782); 26 Feb 2017 12:07:22 -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 13:07:21 +0100 Original-Received: (qmail 4288 invoked by uid 1000); 26 Feb 2017 12:06:57 -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:212606 Archived-At: Hello, Stefan. On Sat, Feb 25, 2017 at 21:32:49 -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. > > 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"? > .... work for Elisp, we can also make it work satisfactorily for C-x n > n. But the other way around is not necessarily true, I think. > >> [ I like to consider that strings and comments are also a form of > >> "island", although we're probably better off supporting them in > >> a special way like we do now. ] > > I think that's just confusing the meaning of "island", which I'd like to > > keep clear and unambiguous. Something to be decided is how we'd handle > > an island within a comment or string. > 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. > I don't see why an island within a comment/string should need any > special treatment. Just like an island within an island. It doesn't need special treatment, but it does need to be dealt with somehow. Probably by silently skipping over the island. A bit like how comments are usually skipped in scan-lists. But I think you're right, it's not a big thing. > >> > o - narrow-to-region will be given an optional argument which, if set, > >> > directs Emacs to make the new region an island. Thus, C-u C-x n n > >> > would enable a user to narrow to a "comment within a string" and edit > >> > it as though it were a comment. > >> How would this work (especially for uses from Elisp)? > >> Would it set syntax-table text-properties? > > Yes, it would. It would put an island open syntax-table property on the > > character before START, and and island close on the character after END. > > This would isolate the region syntactically from its surroudings. > I don't think that's going to be fast enough, then. I'm thinking of > cases where current Elisp code does something like > (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[*]? Or, more precisely, _when_ is there any need to create an island? If this did need an island and were within a loop, surely the code could be rearranged for the loop to be inside the with-syntax-table form. [*] I'm envisaging narrow-to-region getting an &optional parameter make-island, if that's not clear. > This usage doesn't correspond to an island, really and shouldn't cause > caches to be flushed. 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. > Stefan -- Alan Mackenzie (Nuremberg, Germany).