bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22884: 25.0.92; C/l mode editing takes waaaayy too long


From: Paul Eggert
Subject: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Thu, 3 Mar 2016 09:54:54 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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. 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).

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. 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)?

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?).

Attachment: emacs.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]