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: Bug #25608 and the comment-cache branch Date: Sun, 12 Feb 2017 12:49:29 -0500 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486921785 11055 195.159.176.226 (12 Feb 2017 17:49:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2017 17:49:45 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 18:49:41 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 1ccyHM-0002Ut-8i for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 18:49:40 +0100 Original-Received: from localhost ([::1]:52961 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccyHR-0003rR-Pi for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 12:49:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccyHJ-0003rM-9m for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:49:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccyHE-0005tA-Cr for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:49:37 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:48388) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ccyHE-0005sj-57 for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:49:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcKQAu3EVY//7rSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZehhwEAgKCEUQQAQIBAQEBAQEBYiiEaQEEAVYjBQsLDiYSFBgNJIh6CK0Ui0QBAQEBBgIBJIoRgQiKKQWPfIUAhWqbGoY6kg82IHgTDoVzIIZwKoITAQEB X-IPAS-Result: A0AcKQAu3EVY//7rSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZehhwEAgKCEUQQAQIBAQEBAQEBYiiEaQEEAVYjBQsLDiYSFBgNJIh6CK0Ui0QBAQEBBgIBJIoRgQiKKQWPfIUAhWqbGoY6kg82IHgTDoVzIIZwKoITAQEB X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="292712085" Original-Received: from 45-72-235-254.cpe.teksavvy.com (HELO ceviche.home) ([45.72.235.254]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2017 12:49:29 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 9734E6629F; Sun, 12 Feb 2017 12:49:29 -0500 (EST) In-Reply-To: <20170212120553.GB3087@acm> (Alan Mackenzie's message of "Sun, 12 Feb 2017 12:05:54 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:212299 Archived-At: > I also have an attachment to it because it works, and would save me ^^^ for you > demoralizing work debugging bugs caused by open parens in column zero in > comments. Is that really the only reason? It seems like an amazingly complicated way to go about it. Let's see some alternatives: - set open-paren-in-column-0-is-defun-start to nil. - add a font-lock rule which highlights open-paren-in-column-0 inside comments in bright red. - use my syntax-ppss-based patch. > Bug #22983 is a flaw. Great! We're trying to have a reasoned argument; I tell you that using this term to describe this problem is not helping and you insist on using it. From where I stand, this qualifies as provocation. > Also the cache invalidation in syntax-ppss is less than rigorous. Yup, syntax-ppss's implementation is not perfect. That can be improved. > For example, the cache isn't invalidated when syntax-table text > properties are applied or removed. This is not a correct characterization of the most common cache-invalidation problem with syntax-ppss: there's a correlation between the problem and syntax-table text properties, but that's all: it also affects all other properties, but it doesn't affect all changes to the syntax-table text properties. >> BTW, your comment-cache doesn't fix that "flaw" and hence won't help any >> of those users of syntax-ppss which can't be changed to use your >> comment-cache. > That's incoherent. comment-cache was never intended to help those other > uses, though it appears it could do so for most of them. It's only incoherent if you refuse to see the larger picture. > Can't be done, as I keep telling you. comment-cache is solely for > handling literals. Then it's useless, AFAIC: - we need syntax-ppss's data for lots of things. - your code can't replace all those uses. - so we're stuck with syntax-ppss, no matter how much you think it sucks. - then we might as well use it in back_comment instead of your code, since it's there and is cheap. > 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. I can agree with that. But currently that's not how Emacs behaves, so it's an incompatible change (which I'm quite willing to make, BTW), and needs to come with some way to recover the other behavior when that one is needed. > If I understand correctly, the problem is that multiple-major-mode modes > are trying to use narrowing to get a null syntactic context. That's the typical example, but not the only one. > They are trying this because we don't provide anything better. > We should provide something better. Agreed. > I suggested such a something last spring ("islands"). If each buffer > position has an unambiguous syntactic context the question of > "widening" simply evaporates. I think this is too specialized to a particular application (multiple major modes). We also need to accommodate other cases. For that we need to provide something equivalent to (save-restriction (narrow-to-region BEG END) ...) but where syntax-ppss and friends will know that we shouldn't widen past BEG/END and that BEG should be taken as "the (temporary) beginning of the buffer". Let's call it `with-region-as-subbuffer`. Most likely, this new functionality should also make it possible to temporarily provide a different syntax-table. Such things are used in various circumstances where the author simply wants to reuse Emacs's syntax.c code to avoid writing some ad-hoc parsing. IOW, we need to provide something on top of which we can build this `with-region-as-subbuffer` macro as well as your islands. Stefan