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: Mon, 27 Feb 2017 19:05:58 +0000 Message-ID: <20170227190558.GA2921@acm> References: <20170225135355.GA2592@acm> <20170225212236.GD2592@acm> <20170226120656.GA3811@acm> <20170226163724.GD3811@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1488222912 2362 195.159.176.226 (27 Feb 2017 19:15:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Feb 2017 19:15:12 +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 Mon Feb 27 20:15:08 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 1ciQlE-0008Hh-L5 for ged-emacs-devel@m.gmane.org; Mon, 27 Feb 2017 20:15:04 +0100 Original-Received: from localhost ([::1]:55939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciQlK-0001Es-I6 for ged-emacs-devel@m.gmane.org; Mon, 27 Feb 2017 14:15:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciQcw-00038J-MJ for emacs-devel@gnu.org; Mon, 27 Feb 2017 14:06:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ciQcs-0006GB-LM for emacs-devel@gnu.org; Mon, 27 Feb 2017 14:06:30 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:21664 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ciQcs-0006Fm-Bm for emacs-devel@gnu.org; Mon, 27 Feb 2017 14:06:26 -0500 Original-Received: (qmail 22204 invoked by uid 3782); 27 Feb 2017 19:06:23 -0000 Original-Received: from acm.muc.de (p548C7277.dip0.t-ipconnect.de [84.140.114.119]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 27 Feb 2017 20:06:22 +0100 Original-Received: (qmail 3506 invoked by uid 1000); 27 Feb 2017 19:05:58 -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:212626 Archived-At: Hello, Stefan. On Sun, Feb 26, 2017 at 23:05:44 -0500, Stefan Monnier wrote: > > I am proposing implementing islands as a solution to the problem, not as > > a way of thinking about it. > In order to design a solution, we need to think about the problem somehow. That's all very well, but we could spend weeks (or months) talking about the problem without getting anywhere. With a proposed solution, we can at least discuss whether it fixes the given problem, and if not, modify it until it does. You've already pointed out a sensible enhancement to it. (Having a third new syntax class which can swap syntax tables without nesting.) > >> But the issue is that the syntax beginning in the above example should be > >> point-min, not 1. Incidentally, a parse state (like a voltage) is always a _difference_ between two points. It is determined by (parse-partial-sexp start end ...). It is an error in thinking to think that there is any a priori syntax beginning in any buffer situation. It is only the addition of a syntax cache which creates the notion of this syntax beginning, but we must never forget that this syntax beginning is a property of the cache, NOT of the narrowing. Caches are complicated things, but narrowing is simple and unambiguously defined. > > Should it? Here's that code fragment again, for reference: (save-restriction (narrow-to-region ...) (with-syntax-table ... (backward-sexp 1))) > It's not really inherent in the code, but it's how it currently behaves > (mostly), and in some cases that is what the author wants. In other > cases, the author wants something else. That code appears to be from .../lisp/obsolete/complete.el, function PC-lisp-complete-symbol. If that's the case it's simply using narrowing without any syntax cache, so there's no concept of a syntax beginning whatsoever, there. There would be no need to create an island in that `narrow-to-region'. > > 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. > backward-sexp will call back_comment, so yes it makes a difference. > And since speed may be important, it's also important to make sure we > don't scan over the 100KB of text that comes before point-min. :-) There will be situations where things like backward-sexp will call back_comment (which is why it is important that back_comment be fast) but that code fragment isn't one of them. And even if it did (which will be rare), it is not doing it inside a tight loop. > > 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. > But won't setting those islands flush the caches (e.g. comment-cache, > syntax-ppss cache, ...)? I think you've chosen a bad example for making that point. The syntax-ppss cache in the above code will need flushing anyway due to the with-syntax-table. The comment-cache cache might or might not need flushing for that reason (depending on the differences between the two syntax tables). Creating an island will invalidate the syntax-ppss cache from the beginning of the island, yes. But few of the existing `narrow-to-region's (there are ~750 in Emacs) will require to create islands. This is only needed where the newly created accessible portion needs to be syntactically separated from what is outside of it. In most `narrow-to-region's (like that one in complete.el) this won't be the case. The only circumstances this would be concerning would be (i) creating islands in a tight loop; and (ii) moving forward in the buffer in this loop. Are there any such circumstances in Emacs? I honestly don't believe the flushing of caches is an important problem in the proposed islands implementation. > Stefan -- Alan Mackenzie (Nuremberg, Germany).