From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long Date: Thu, 3 Mar 2016 19:23:30 +0000 Message-ID: <20160303192330.GA3822@acm.fritz.box> References: <56D72C35.4090708@cs.ucla.edu> <20160303124910.GA2852@acm.fritz.box> <56D87A6E.8090202@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457032947 19589 80.91.229.3 (3 Mar 2016 19:22:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Mar 2016 19:22:27 +0000 (UTC) Cc: 22884@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 03 20:22:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1abYpD-00067S-B5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Mar 2016 20:22:15 +0100 Original-Received: from localhost ([::1]:36964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abYpC-0003VU-Kr for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Mar 2016 14:22:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abYp7-0003VP-VC for bug-gnu-emacs@gnu.org; Thu, 03 Mar 2016 14:22:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abYp3-0004DS-Mz for bug-gnu-emacs@gnu.org; Thu, 03 Mar 2016 14:22:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abYoz-00048U-NO; Thu, 03 Mar 2016 14:22:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1abYoz-0007zy-Ji; Thu, 03 Mar 2016 14:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 03 Mar 2016 19:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22884 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 22884-submit@debbugs.gnu.org id=B22884.145703286230665 (code B ref 22884); Thu, 03 Mar 2016 19:22:01 +0000 Original-Received: (at 22884) by debbugs.gnu.org; 3 Mar 2016 19:21:02 +0000 Original-Received: from localhost ([127.0.0.1]:60467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1abYo2-0007yT-Df for submit@debbugs.gnu.org; Thu, 03 Mar 2016 14:21:02 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:15443) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1abYo0-0007xm-7F for 22884@debbugs.gnu.org; Thu, 03 Mar 2016 14:21:00 -0500 Original-Received: (qmail 80679 invoked by uid 3782); 3 Mar 2016 19:20:59 -0000 Original-Received: from acm.muc.de (p579E89EE.dip0.t-ipconnect.de [87.158.137.238]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Mar 2016 20:20:57 +0100 Original-Received: (qmail 486 invoked by uid 1000); 3 Mar 2016 19:23:30 -0000 Content-Disposition: inline In-Reply-To: <56D87A6E.8090202@cs.ucla.edu> User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114358 Archived-At: Hello, Paul. First of all, congratulations on getting such a long patch prepared by 10 o'clock in the morning. :-) On Thu, Mar 03, 2016 at 09:54:54AM -0800, Paul Eggert wrote: > On 03/03/2016 04:49 AM, Alan Mackenzie wrote: > > Inserting a backslash at the beginning of L14 solves the problem, as > > does setting open-paren-in-column-0-is-defun-start to nil. > I presume the latter is not really on the table. No, indeed not. > We can't put a backslash there, as it's license text and shouldn't be > fiddled with in that way. We could fold it differently (as in the > attached proposed patch, which does this only for config.h and > friends). Why only for the one file? The performance hit comes from the amount of contiguous syntactic whitespace following the "failed" comment. Have you checked this is the only file with so much SWS? The effect of of these "failed" comments on CC Mode is as follows: c-beginning-of-statement-1 uses c-backward-syntactic-ws. The latter goes back to just before the ostensible "//" comment marker in the GNU URL, that is, just after "http:". c-beginning-of-statement-1 then moves back over the "label", then moves back one sexp at a time, looking for statement boundaries, keywords, etc. It recognises "for" in "for more details" as a C keyword, assumes that "more" is the parenthetical expression and that "details" is the beginning of the substatement. Although this (probably) won't hit the performance in most files, it is going to throw out the syntactic analysis sometimes. Is there any chance you could put in the refolding of the copyright message into all the files, to avoid this? By the way, I've tried out your patch. It applies fine to the emacs-25 branch, it builds OK, and the new Emacs seems to start and run OK. > > The next problem is that there are around 324 occurrences of "(" at > > column zero in the src directory, and quite a few in lib and lib-src. > > Most of them are in comments, some of them are parameter lists, and > > some of them (e.g. in lisp.h) are wierd constructs of some sort. These > > contravene GNU coding standards and really need sorting out. > The lisp.h constructs are weird, but they don't violate the GNU coding > standards as the parens at the start of a line do indeed mark the start > of a function definition. OK. Could you give me a clue as to what they mean, please? For example, in INLINE EMACS_INT (XLI) (Lisp_Object o) { return lisp_h_XLI (o); } , what does "(XLI)" do? It looks like a cast, but it's in the wrong place to be a cast. It can't be an expansion of the CPP macro "XLI", surely, lacking, as it does, an argument. What is this thing? > Do these parens break cc-mode somehow? If so, what's the breakage? and > how would you suggest reformatting lisp.h (and/or fixing cc-mode)? No, they don't cause breakage. > The attached proposed patch fixes all the problems I found, except (1) > it leaves license wording alone for the most part (config.h excepted, > since the performance disaster is there), and (2) it leaves the weird > lisp.h constructs alone as per the above paragraph. Is this the sort of > thing you had in mind (except I guess we need to fix (1) too?). Yes. I was half way through constructing such a patch myself, but you beat me to it. :-) As I said above, I'd be happier if you could fix the license text in all the files. It cannot be too much work (a short sed script, or something similar). [ .... ] -- Alan Mackenzie (Nuremberg, Germany).