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: Tue, 7 Feb 2017 19:21:19 +0000 Message-ID: <20170207192119.GA2490@acm> 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> <4f0fabf3-be9c-7492-379b-59dc93e72b4f@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1486495318 22584 195.159.176.226 (7 Feb 2017 19:21:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 19:21:58 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 07 20:21:54 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 1cbBKq-0005bP-GQ for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 20:21:52 +0100 Original-Received: from localhost ([::1]:56056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbBKw-0001UF-47 for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 14:21:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbBKl-0001T7-56 for emacs-devel@gnu.org; Tue, 07 Feb 2017 14:21:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbBKg-0003nJ-R0 for emacs-devel@gnu.org; Tue, 07 Feb 2017 14:21:47 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:15990 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cbBKg-0003lF-Hj for emacs-devel@gnu.org; Tue, 07 Feb 2017 14:21:42 -0500 Original-Received: (qmail 48593 invoked by uid 3782); 7 Feb 2017 19:21:40 -0000 Original-Received: from acm.muc.de (p548C7312.dip0.t-ipconnect.de [84.140.115.18]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 07 Feb 2017 20:21:39 +0100 Original-Received: (qmail 3313 invoked by uid 1000); 7 Feb 2017 19:21:19 -0000 Content-Disposition: inline In-Reply-To: <4f0fabf3-be9c-7492-379b-59dc93e72b4f@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:212109 Archived-At: Hello, Dmitry. On Tue, Feb 07, 2017 at 03:42:50 +0200, Dmitry Gutov wrote: > 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? Well, aside from the fact that it doesn't (IMAO), it is only consulted relatively rarely, in certain cases of back_coment where the backward scanning hits something it doesn't want to handle. The AP is marginally slower than comment-cache. If such awkward comments were prominent in a file, it would be noticeably slower. In comment-cache, the cache is used for every back_comment. > 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. Those bugs are enough, aren't they? (forward-comment -1) etc., should work correctly in any circumstances. There might be the sort of bugs you're looking for, but I suspect not. The backward scanning code is very complicated. > > 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. I wasn't enthusiastic about your proposed fix because I found it ugly. > > 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". That sounds like you've decided you want to use syntax-ppss no matter what, and the bugs this will cause will just be relabeled as features. As I've said before, the aim should be for back_comment always to work. > 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. You should now be able to see why I dislike syntax-ppss so much. As well as being incompatible with narrowing (which should be sort of fixable), there is an essential lack of cache invalidating (which would only be fixable by a radically different design). There is no sign that much thought was given to cache invalidation in the design of syntax-ppss. This probably cannot be fixed, or if it can, will involve lots of programming at the C level, and will slow Emacs down quite a bit. > > comment-cache handles these situations correctly - that's where its > > perceived complexity scores. > And it does that in a pretty inflexible way. It works. Other ways (apart from M-nil (master with open-paren-in-column-0-is-defun-start set to nil)) don't. The sort of flexibility I recall you wanting is simply not possible in comment-cache, though its role could be expanded for other uses which need the literality of a position. > > comment-cache has rewriten back_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. It's differently complicated. master's back_comment, which attempts to scan comments backwards is more complicated than comment-cache's back_comment (including its cacheing 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. How have you quantified "quite a bit"? > > Arguing for complete abandonment is not constructive criticism. > When an alternative approach is recommended, yes, it is. There is nothing to indicate you've even looked at comment-cache. All the criticisms you've made have been from a distance, based on rumour (even if the source of that rumour has been me). These criticisms have been entirely destructive. I repeat, you want comment-cache to be wholly abandoned, apparently because you like syntax-ppss so much. The alternative "recommended" approach has documented deficiencies, yet you still advocate it. > > 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. They can't be implemented at the Lisp level. The tools Emacs Lisp provides for cache invalidation (basically, before/after-change-functions) aren't up to the job. > So the "speed up forward-comment" patch would still come out to 20 lines. Well, if you get a decent bug fix involving, say a 700 line patch which includes those 20 lines, I suppose you could still call it a 20 line patch, somehow. > > 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. Full syntax-table comparisons are slow, even when written in C. I tried it back in December. CC Mode regularly switches syntax-tables. My usual time-scroll function on xdisp.c ran at about half the speed when a comparison was done at every set-syntax-table. The results had to be cached, after which it ran at normal speed again. -- Alan Mackenzie (Nuremberg, Germany).