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: Bug #25608 and the comment-cache branch Date: Sun, 12 Feb 2017 17:29:00 +0000 Message-ID: <20170212172900.GC3087@acm> References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170205220045.GB2294@acm> <83d1es61li.fsf@gnu.org> <20170211232511.GA13712@acm> <20170212120553.GB3087@acm> <5dac24ba-a73e-b4f4-f595-30f86564b00a@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1486920580 26423 195.159.176.226 (12 Feb 2017 17:29:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2017 17:29:40 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 18:29:36 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 1ccxxw-00068w-2P for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 18:29:36 +0100 Original-Received: from localhost ([::1]:52863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccxxt-0006Fb-B4 for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 12:29:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccxxm-0006FV-L2 for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:29:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccxxj-0000fF-Gm for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:29:26 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:47843 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ccxxj-0000f2-Ac for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:29:23 -0500 Original-Received: (qmail 42349 invoked by uid 3782); 12 Feb 2017 17:29:21 -0000 Original-Received: from acm.muc.de (p548C7DA1.dip0.t-ipconnect.de [84.140.125.161]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Feb 2017 18:29:20 +0100 Original-Received: (qmail 9180 invoked by uid 1000); 12 Feb 2017 17:29:00 -0000 Content-Disposition: inline In-Reply-To: <5dac24ba-a73e-b4f4-f595-30f86564b00a@yandex.ru> 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:212295 Archived-At: Hello, Dmitry. On Sun, Feb 12, 2017 at 17:57:24 +0200, Dmitry Gutov wrote: > On 12.02.2017 14:05, Alan Mackenzie wrote: > > That's incoherent. comment-cache was never intended to help those other > > uses, though it appears it could do so for most of them. That > > particular flaw we're talking about doesn't appear in comment cache, so > > there's nothing to fix there. > You're changing a low-level primitive to adhere to a non-flexible view > of the world that is incompatible with syntax-ppss. No. comment-cache and syntax-ppss are independent of each other and thus not incompatible. > > Maybe sometime. In the meantime, the bug with open parens in column > > zero in comments should be fixed. > If you're willing to give up narrowing support, that bug can be fixed in > no time, with the 20-line patch we all know about. I'm not willing to give up narrowing support. Neither are lots of other people. It's a fundamental feature of Emacs, widely used. > > The question of "widening" is not difficult. Narrowing a buffer should > > not change the syntax of the characters in it. Doing so leads to > > inconsistencies. > Yeah, you really want narrowing to be interpreted the way that is more > convenient for your usage habits. I want it to be handled correctly and consistently. > I want it to be interpreted that's more convenient for the code I've > written and ended up maintaining. Resolving this conflict requires > some thought. Multiple-major-mode code? Narrowing is not a good way of doing this, and I propose a better way. > > If I understand correctly, the problem is that multiple-major-mode modes > > are trying to use narrowing to get a null syntactic context. They are > > trying this because we don't provide anything better. We should provide > > something better. I suggested such a something last spring ("islands"). > You suggested implementing a big, ambiguously defined feature. It was big, yes, but reasonably well defined. What I really meant in my last paragraph was that the syntax bits of "islands" should be used in place of what is now done with narrowing. This would introduce two new syntax classes "open island" and "close island". "Open island" would stack the current syntactic state and start anew, with a new syntax table. "Close island" would pop this stack, restoring the previous state and syntax table. > We basically have no way to determine whether it would work out. I've > spent some time on that discussion helping you narrow down the specs, > but my personal takeaway is that it's too complex. It's not complicated. It's just big. It's intention is to be the simplest possible natural implementation of multiple-buffer-modes which doesn't need nasty workarounds. > Maybe I'm too unimaginative and lazy, though, so please go ahead and > work on a prototype if you're confident. I'm confident it could work, but there's much more work involved than I'm capable of doing on my own in a reasonable time. It would need a team to work on it. That's not really the way Emacs gets developed. > In the meantime, however, we need to keep Emacs compatible with > multiple-major-mode modes some other way. See above. -- Alan Mackenzie (Nuremberg, Germany).