From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Bug #25608 and the comment-cache branch Date: Tue, 7 Feb 2017 03:42:50 +0200 Message-ID: <4f0fabf3-be9c-7492-379b-59dc93e72b4f@yandex.ru> References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170203172952.GC2250@acm> <0a40d539-b7bc-2655-5429-6280022106ee@yandex.ru> <20170204102410.GA2047@acm> <8f9e68fc-4314-625d-b4bf-796c71c91798@yandex.ru> <20170206192423.GB3568@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1486431797 14392 195.159.176.226 (7 Feb 2017 01:43:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 01:43:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 07 02:43:10 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 1cauoH-0003OB-Fj for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 02:43:09 +0100 Original-Received: from localhost ([::1]:51482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cauoM-0001nr-UF for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 20:43:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cauoA-0001ml-BT for emacs-devel@gnu.org; Mon, 06 Feb 2017 20:43:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cauo5-0000cd-Bg for emacs-devel@gnu.org; Mon, 06 Feb 2017 20:43:02 -0500 Original-Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:32818) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cauo5-0000cK-3t; Mon, 06 Feb 2017 20:42:57 -0500 Original-Received: by mail-wm0-x242.google.com with SMTP id v77so25363981wmv.0; Mon, 06 Feb 2017 17:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8D3xE2t6pzhnzscY94oq2IdUHMbBHR0rtkIANHrDMvo=; b=NIfZ+XqlNQIiNvNMlvOEe2jMH+L4chP12ut5HpDobMC/IFFWkB5zZ42XflXIL/g5LY hVnLzgEf/aWi50vKZhQwdE0yXYJDi+ptHGtksIGUStEDijJE/J2d+h+W70eHlLbEtLpa JBRvjdZkJrwNfOrzztnSxdcEle5lY9CrKJazL6ebjYmQFeL95ERcYETizn/LJjTBIKV6 9eibGF5yb0xMUelLV3NzgtVMxuzd7NVDCGpMZIkNNkLu6Q3iDegemMvNv8tmgwdi29/u nzdLTNVlF9yQC7vRrMBt8iKSVcUaI7hhWrbhKN3EieUE5snzM2MXTP0EIv5h3KR4/Ig3 P9fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8D3xE2t6pzhnzscY94oq2IdUHMbBHR0rtkIANHrDMvo=; b=HjLXTN8NqpKE+3HQkLZ7yuy+Az3lEONnG9+3SydpPksSXPBoLpAbqpkaKJ1l2/dtrA pPZ3iwReqeZwN76TA7ONMrQtD/gLqByNhjlIZVsKWCyla5sdklm6QZ0kS2GHzhpirXkL 7Gw0UdFLTwragS2EBaH2TO0p9hvas+oyOFAO/wRkdiQmBDcqvmOrHh1ySNBpNGJi7g2m lwMtwtin0oD6JLYNggwn+fMVQFvwzttTCYPcvANHuKlsOmoipDak7la6NoiDHhAJapDh rrM6NFJiYiGZT4XdgLIRP1BaKf2vpkbgV3S4z/UvoslIK+wn/IpeHFhGli/JQ3MDSN8F AYpQ== X-Gm-Message-State: AMke39lL1pBqeD2Kb25XgaE8JLH6xpylg6MBAn2taZrYREK1UeTLzbxHPr8KJbm6j+IZ/g== X-Received: by 10.28.15.2 with SMTP id 2mr11794743wmp.66.1486431774008; Mon, 06 Feb 2017 17:42:54 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id c202sm15965475wmd.10.2017.02.06.17.42.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 17:42:53 -0800 (PST) In-Reply-To: <20170206192423.GB3568@acm> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::242 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:212071 Archived-At: Hey Alan, On 06.02.2017 21:24, Alan Mackenzie wrote: > The essence of comment-cache is scanning comments only in the forward > direction. This is impractical without a good cache. The syntax-ppss > cache is wholly inadequate here (and would be even if it worked in the > general case). How come the "alternative patch" works well, then? The only bugs you've outlined so far are related to narrowing and syntax table change, but not any static complex syntactic situations, which is where I would expect scanning direction to have an impact. > There's no sign of syntax-ppss being fixed. Bug #22983 has been open > for almost a year, and despite repeated requests from me, there has been > no movement on it. You didn't show any enthusiasm about the initial proposed fix, which was rather simple. Now we've had more discussions, and the bar for a solution has been raised. I'm thinking about it again. Let's not give up. > Anyways, there are other problems with the "alternative patch". It > doesn't clear it's caches when syntax-table properties are applied to or > removed from a buffer. It doesn't clear its caches when a "literal > relevant" change is made to the current syntax table, or a different > syntax-table is made current. Tracking changes inside a syntax table is possible (at the expense of some performance, as usual), but kinda pointless, I think. Most issues related to that, if they ever come up, could be answered with "don't do that". Tracking the used syntax table is also a problem which we need to solve for syntax-ppss. A good design could handle it and narrowing together. > comment-cache handles these situations > correctly - that's where its perceived complexity scores. And it does that in a pretty inflexible way. > comment-cache has rewriten backward_comment entirely, hence the > troublesome merge. It's no more difficult for maintainers than the > current version of Emacs. But surely it is more complex, with cache handling logic. > They shouldn't drift apart at all. But drifting apart is no worse a > problem than a single cache being wrong. Yes, it is worse. You have more code to debug. And comment-cache adds quite a bit of code. > Arguing for complete abandonment is not constructive criticism. When an alternative approach is recommended, yes, it is. > I'm not saying the "alternative patch" couldn't be enhanced to do these > things properly, but it would then no longer be a 20-line patch. I think it would be. The enhancements you're referring to will most likely be implemented on the Lisp level, and they are needed anyway. So the "speed up forward-comment" patch would still come out to 20 lines. > It would also likely be much slower. I wouldn't be so sure. A syntax table comparison, for instance, would be pretty cheap compared to what syntax-ppss does already.