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: The current state of the comment-cache branch Date: Sat, 24 Dec 2016 09:07:46 +0000 Message-ID: <20161224090746.GC2212@acm.fritz.box> References: <20161223215056.GA2771@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1482570538 19134 195.159.176.226 (24 Dec 2016 09:08:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Dec 2016 09:08:58 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 24 10:08:54 2016 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 1cKiJy-0004XJ-Cx for ged-emacs-devel@m.gmane.org; Sat, 24 Dec 2016 10:08:54 +0100 Original-Received: from localhost ([::1]:42765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKiK3-0006O1-2c for ged-emacs-devel@m.gmane.org; Sat, 24 Dec 2016 04:08:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKiJG-0006N0-AL for emacs-devel@gnu.org; Sat, 24 Dec 2016 04:08:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKiJD-0000R4-47 for emacs-devel@gnu.org; Sat, 24 Dec 2016 04:08:10 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:58982 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cKiJC-0000Qo-Pd for emacs-devel@gnu.org; Sat, 24 Dec 2016 04:08:07 -0500 Original-Received: (qmail 7752 invoked by uid 3782); 24 Dec 2016 09:08:05 -0000 Original-Received: from acm.muc.de (p4FC462C6.dip0.t-ipconnect.de [79.196.98.198]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 24 Dec 2016 10:08:04 +0100 Original-Received: (qmail 2357 invoked by uid 1000); 24 Dec 2016 09:07:46 -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:210777 Archived-At: Hello, Stephan. On Fri, Dec 23, 2016 at 08:32:42PM -0500, Stefan Monnier wrote: > > I would like the comment-cache code to be merged into master soon. > This message is probably redundant, but just to make it clear: > I'm opposed to this change as it is because I find its cost/benefit > tradeoff to be poor. I don't think solving some rare pathological case > of (forward-comment -1) deserves this complexity. The prime benefit is that open parens in column 0 inside comments entirely cease to be an issue. They are far from rare pathological cases. They have turned up continually in bug reports for many years, including in Paul's bug #22884, where the cause of a 10s delay in a simple edit was such a paren in column 0. > I think we'd be better off with either: > - a simpler change, to reduce the cost part of the tradeoff (such as the > one I suggested, using syntax-ppss; such a change might make extra > demands on syntax-ppss which will require further "refinement" to > syntax-ppss, but these refinements are needed in any case, so are not > an argument against that change, but only an argument to delay the > change). This would involve a substantial change to syntax-ppss. The way it is at the moment, a use of syntax-ppss involves scanning forward over, on average, 10,000 characters. This would dominate the time taken to move backwards over a small comment, slowing it down by 2 orders of magnitude. The time taken by comment-cache to do the same movement is low, and essentially independent of the size of the comment. > - a more thorough change, to improve the benefit (i.e. make your > "comment-cache" able to provide the same kind of information that we > currently get via syntax-ppss, so it can supersede syntax-ppss). I can't imagine how that could work. comment-cache, as you know, keeps the "literal state" of all positions in text properties. Were the entire parse state to be encoded thus, the number of conses involved would increase dramatically, along with the overhead on the text property system. parse-partial-sexp currently has a facility to stop at the start or end of any string or comment. This is used in comment-cache to write the text properties. There is no corresponding facility to stop after _any_ change in parse state. Maybe this could be written, but the benefit/cost ratio might be low. > Stefan -- Alan Mackenzie (Nuremberg, Germany).