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 12:05:54 +0000 Message-ID: <20170212120553.GB3087@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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1486901222 5558 195.159.176.226 (12 Feb 2017 12:07:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2017 12:07:02 +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 12 13:06:57 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 1ccsvg-0000w2-M4 for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 13:06:56 +0100 Original-Received: from localhost ([::1]:51638 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccsvi-0000lo-Vx for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 07:06:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36323) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccsv8-0000li-Ig for emacs-devel@gnu.org; Sun, 12 Feb 2017 07:06:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccsv4-0000jj-JQ for emacs-devel@gnu.org; Sun, 12 Feb 2017 07:06:22 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:26061 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ccsv4-0000jP-9V for emacs-devel@gnu.org; Sun, 12 Feb 2017 07:06:18 -0500 Original-Received: (qmail 80892 invoked by uid 3782); 12 Feb 2017 12:06:15 -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 13:06:14 +0100 Original-Received: (qmail 4699 invoked by uid 1000); 12 Feb 2017 12:05:54 -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:212275 Archived-At: Hello, Stefan. On Sat, Feb 11, 2017 at 19:55:46 -0500, Stefan Monnier wrote: > > In the current situation I think that both Stefan and Dmitry have an > > emotional attachment to syntax-ppss despite its manifest flaws, and it > Of course, I have an emotional attachment to syntax-ppss, since I wrote > it and used it all over the place. And of course you have an emotional > attachment to comment-cache since you wrote it. I also have an attachment to it because it works, and would save me demoralizing work debugging bugs caused by open parens in column zero in comments. > But using words like "flaw" to describe a simple shortcoming of the > current implementation, is really not helping. I hope I never wrote > something about your comment-cache that was similarly aimed at just > putting it down. Bug #22983 is a flaw. It has been open for nearly a year, yet for some reason isn't being fixed. Also the cache invalidation in syntax-ppss is less than rigorous. For example, the cache isn't invalidated when syntax-table text properties are applied or removed. > 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. That particular flaw we're talking about doesn't appear in comment cache, so there's nothing to fix there. > Which is why I said many months ago that it'd be fine to use something > like your comment-cache *if* you extend it to provide the > functionality of syntax-ppss. Can't be done, as I keep telling you. comment-cache is solely for handling literals. > But that's also why I think this whole discussion is pointless: we first > need to focus on that "flaw" which comes to the problems of narrowing > and whether tools like syntax-ppss, comment-cache, font-lock, etc... can > and should widen and if so when and up to where. Maybe sometime. In the meantime, the bug with open parens in column zero in comments should be fixed. 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. 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"). If each buffer position has an unambiguous syntactic context the question of "widening" simply evaporates. > Stefan -- Alan Mackenzie (Nuremberg, Germany).