From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution. Date: Sun, 26 Feb 2017 08:47:55 -0500 Message-ID: References: <20170225135355.GA2592@acm> <20170225212236.GD2592@acm> <20170226120656.GA3811@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488116941 28430 195.159.176.226 (26 Feb 2017 13:49:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 13:49:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 26 14:48:51 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 1chzBy-0006W9-Af for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 14:48:50 +0100 Original-Received: from localhost ([::1]:46595 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chzC4-0002ki-9X for ged-emacs-devel@m.gmane.org; Sun, 26 Feb 2017 08:48:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chzBR-0002kd-3o for emacs-devel@gnu.org; Sun, 26 Feb 2017 08:48:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chzBK-0000QE-VJ for emacs-devel@gnu.org; Sun, 26 Feb 2017 08:48:17 -0500 Original-Received: from [195.159.176.226] (port=52808 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1chzBK-0000Pw-OE for emacs-devel@gnu.org; Sun, 26 Feb 2017 08:48:10 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1chzB7-0002DF-5v for emacs-devel@gnu.org; Sun, 26 Feb 2017 14:47:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:e4Kh6aB6ge/G70h2iLmM8NQsJR4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:212609 Archived-At: >> > 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