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: Mon, 6 Feb 2017 04:09:42 +0200 Message-ID: <8f9e68fc-4314-625d-b4bf-796c71c91798@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> 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 1486346995 19576 195.159.176.226 (6 Feb 2017 02:09:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 02:09:55 +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 Mon Feb 06 03:09:51 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 1caYkY-0004vk-ON for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 03:09:50 +0100 Original-Received: from localhost ([::1]:45234 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caYke-0006gh-9Z for ged-emacs-devel@m.gmane.org; Sun, 05 Feb 2017 21:09:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caYkY-0006ga-Bs for emacs-devel@gnu.org; Sun, 05 Feb 2017 21:09:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caYkV-0000FI-4A for emacs-devel@gnu.org; Sun, 05 Feb 2017 21:09:50 -0500 Original-Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:35553) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1caYkU-0000F9-Qu; Sun, 05 Feb 2017 21:09:47 -0500 Original-Received: by mail-wm0-x243.google.com with SMTP id u63so19009438wmu.2; Sun, 05 Feb 2017 18:09:46 -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=HAvOeqIZVze37b2oVzGeEVBOk23CKuu7i+1xoRijZfw=; b=O23M9JjVaS4YQeWA1koI5i9uApUjwt6X9ZBhC5/OlZyTMFvj8SMSPInfmzhKgqz6BF 3tINg7c8ppTvcFKMQulrubB6vLLKllpoi1cdI+umkMvdcz2q2rqJ/pUlgU8uWAKD4kPa GKyAy5YfjLmYRyJJgcImk4n6IPjRfQeULGAlUy5lp2q44cugJElyByhgJKCqL851AwLp C9+ezCf/8JTXpxLVi7eH3n4ATVy7bvTi1RwM0nQesfkI59k2O4naeVnmtjkBWPFfGpZy wOILJQOOsdcyzC4LbK+eIBypAHnl9Ar7K8UcxY0xhS6WFVaghBJcVDnZsLF4O0VEQ5mJ OvjA== 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=HAvOeqIZVze37b2oVzGeEVBOk23CKuu7i+1xoRijZfw=; b=Z8kjIU9SVzT/wEvsQ3cCzeTShMg1wt0Ee+etfhFgKqKQ5EmR6JKYFrQgDbLUr3rJMY nbqQjf2RKqYBQU3Wn9CSfBPe1TR88udorAs3+QRlL7nwICeN8clIg9lblP/lFefyxPjt a4eQ+a9UPJxfnVsfZ3NuSKco7IvhXAaSwHOuIvCGR8cAWl9jr3kddXzB8xH+k9pI5XPs Mw4/PyT4fhH7ki56uu8+FJm5yoEmfDp+ceggZeDAH/Y+KR5OnSAGClNV82bPf1cTD7Fq 52lSkaIMgAzju8ctYXkbM4cO66zsfZORx+z143XLzVmWSGhSae+VB/o8a9bU8sPayj0z gPYg== X-Gm-Message-State: AMke39n0e2bp1O3N3TwtAIRTIlBbCTz3ckMI1n0KBTqOm1SdsE5RmfIFzDK49dG0pK85rg== X-Received: by 10.28.52.19 with SMTP id b19mr6904495wma.134.1486346985467; Sun, 05 Feb 2017 18:09:45 -0800 (PST) Original-Received: from [10.8.0.14] (v-2-eu19-d3962-07.webazilla.com. [78.140.151.7]) by smtp.googlemail.com with ESMTPSA id 10sm9993182wmi.23.2017.02.05.18.09.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Feb 2017 18:09:44 -0800 (PST) In-Reply-To: <20170204102410.GA2047@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::243 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:212013 Archived-At: On 04.02.2017 12:24, Alan Mackenzie wrote: > You want comment-cache to be wholly abandoned. At least the part that maintains a separate cache. I'm not sure if there's anything else there. It's not because I enjoy disagreeing with you, though. >> And then we should seek the simplest solution that satisfies all of our >> requirements. > > As simple as possible, but definitely not simpler. The "solution" you > favour is too simple. It doesn't work all the time. I concede it's not ideal. However, I strongly believe "fixing" the narrowing problem in syntax-ppss with take care of this example, *and* will result in lower overall complexity and maintenance burden. Consider the problems you've had merging master into the comment-cache branch. If there were conflicts, that means the new code touches a changing area, and it will need to be considered and taken care of by the maintainers, probably on an ongoing basis. The AP, on the other hand, still applies cleanly. >> "It introduces a second source of truth" seems like a concise summary. > > So what? There are any number of "sources of truth" in Emacs. If one > of them turns out to be a "source of untruth" we call that a bug, and we > fix it. One normally adds an alternative source of truth (i.e. a "cache") to fix a significant performance problem, when one really can't do so otherwise. It seems we agree now that comment-cache's existence can't be justified by performance considerations. Cache invalidation is a known hard problem in CS, so we generally don't want to have extra caches. >> At best, it'll use more memory than it has to. > > The thing to do here is measure this extra memory. I did this back in > spring last year, and the number of extra conses used for the cache was > not inordinately high. Especially not for a 64-bit machine with several > gigabytes of RAM. Maybe it's not bad, without a direct link it's hard for me to comment on that now. But "no extra memory usage" would be a better outcome anyway. > I think you're seeing something that's not there. You're picturing some > imagined process where two alternative ways of storing information have > great difficulty staying together, and somehow, over time, are destined > to drift apart. Sort of like two national currencies trying to stay > pegged to eachother, or something like that. I'm picturing weird syntax highlighting/defun navigation/etc behavior that comes and goes seemingly randomly, and which forces us to debug both cache mechanisms to see which one is getting something wrong. They don't even have to drift far apart functionality-wise, as long as their implementations are largely independent. > That's not how computer programs work. If those two ways end up > differing, we have a bug, which can be fixed like any other bug. Heck, > even a single "source of truth" can be buggy, with just as severe > consequences. We get bugs, we fix them. And the more sources of truth we have, we more places we might end up having to fix. > Note, in this context, that syntax-ppss is broken (bug #22983) and > doesn't look like getting fixed any time soon, yet the world hasn't come > to an end. A consistently "wrong" behavior is better than having some standard library functions work "correctly", and some otherwise. Consider this again: as long as syntax-ppss continues to have problems in the cases you imagine, the caches _will_ diverge in those cases. Honestly, my head hurts when I start thinking up problem examples, but I'm sure the users and authors of modes that define syntax-propertize-function and/or use syntax-ppss won't like them. >>> Note that there has been NO constructive criticism of comment-cache. > >> That's insulting, Alan. > > It might be, but I think it's true. You want comment-cache to be wholly > abandoned. You are not suggesting ways to make it better. You haven't > tried it, that I'm aware of. You haven't looked for flaws, with the > intention of getting them fixed. You seem to argue that a high-level criticism can't be constructive, and that any good one has to discuss lower-level implementation details. > Instead you are putting forward > reasons, not all of them good, for abandoning comment-cache. Aside from "two sources of truth", the other reason is that we have a much-simpler patch that gives us (or will eventually give) the same benefits.