From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: POC: customizable cc-mode keywords Date: Sun, 18 May 2014 15:28:50 -0700 Message-ID: <53793422.3070406@dancol.org> References: <53632C6F.5070903@dancol.org> <20140511211351.GC2759@acm.acm> <536FEA43.5090402@dancol.org> <20140516175226.GB3267@acm.acm> <537653A0.2070109@dancol.org> <20140518213331.GB2577@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HT1Pre1xXNE4fIQTDBn14R4aO0cc0t9Ei" X-Trace: ger.gmane.org 1400452152 11710 80.91.229.3 (18 May 2014 22:29:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 May 2014 22:29:12 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 19 00:29:07 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Wm9Zq-0003Q8-8s for ged-emacs-devel@m.gmane.org; Mon, 19 May 2014 00:29:06 +0200 Original-Received: from localhost ([::1]:44797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wm9Zp-0002Xg-Q2 for ged-emacs-devel@m.gmane.org; Sun, 18 May 2014 18:29:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wm9Zm-0002Wk-DN for emacs-devel@gnu.org; Sun, 18 May 2014 18:29:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wm9Zk-0002Da-Un for emacs-devel@gnu.org; Sun, 18 May 2014 18:29:02 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wm9Zk-0002DH-H7 for emacs-devel@gnu.org; Sun, 18 May 2014 18:29:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Qoq7MPC5CBGsZSam0KET/KpUedT1j3wZU5zERLx015g=; b=ZsURjYDwW+eNASwAFOTSY8KYd1WaSA2jaWugssDeE5v4DRE/NLs4rGCCDYHhrVcmucStp8LH0tIZZzbLQ3SFo0w/AygNG2nXbalP5UMDg2bP2JbeLw5sDojr8jMWzSqvC76ItGI8+kcHgEKpfzRmeDM1WfahBBs6oLow/unwjgJUz2grekUXH6UDoX/QrxmB5YIUKkWzwxYOUkqcsGOgtqNkfQAefkh0sAwhcAKG9UotPZx0zf2DfqmsW1tCDCwGdI6BbdHi31VbFov1kCN/h2qOFwssaZpQHqaSrH4ZFXMi1LwZ01apZUtpLLI3qwRvVEt3N6wo1v+NxFrwSQVI7w==; Original-Received: from [2601:8:b240:264::e5a] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Wm9Zc-0003db-RJ; Sun, 18 May 2014 15:28:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <20140518213331.GB2577@acm.acm> X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171929 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HT1Pre1xXNE4fIQTDBn14R4aO0cc0t9Ei Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/18/2014 02:33 PM, Alan Mackenzie wrote: > On Fri, May 16, 2014 at 11:06:24AM -0700, Daniel Colascione wrote: >> On 05/16/2014 10:52 AM, Alan Mackenzie wrote: >>>>>> Today, we use clever macros to hard-code the values of all cc-mode= >>>>>> language variables into the mode functions of each cc-mode major m= ode >>>>>> function or into c-init-language-vars-for, but in order to allow u= sers >>>>>> to customize cc-mode syntax, we have to be able to recompute langu= age >>>>>> constants and variables at runtime. >=20 >>>>> Do we, now? You can imagine I've one or two reservations about thi= s >>>>> idea.=20 >=20 >>>> What's your alternative? >=20 >>> Turning the pertinent c-lang-defvars, and only these, into configurab= le >>> variables in cc-vars.el. >=20 >> Have you looked into what task actually involves? >=20 > No I hadn't. =20 >=20 >> You need to modify c-decl-hangon-kwds, and as a result, >> c-prefix-spec-kwds, c-postfix-spec-kwds, c-keywords, >> c-keywords-regexp, c-keywords-obarray, c-nonlabel-token-key, and >> c-regular-keywords-regexp. >=20 > OK. Then another alternative is to use `or' forms in the appropriate > places, of which there are several rather than many, the extra arm of > the `or' looking something like "(looking-at c-noise-macro-re)". Did y= ou > consider this at all? If so, why do you prefer the solution you now > propose? Doing it that way further increases the amount of work needed at parse time, and cc-mode isn't a speed demon already. Your proposal also introduces much-increased for complexity in the core and creates a risk of "missing a spot" and introducing a bug where we check the primary keywords but not the user-customized ones. (And what about the checking we do after calling intern-soft on the symbol obarray?) cc-engine is very difficult to follow as it is. I'd rather gracefully extend the existing functionality than add yet another set of special cases. Another approach I was considering was to change cc-mode to always skip over regions marked with a certain text properly. Then a minor mode could independently parse and fontify the buffer, marking regions it wanted cc-mode to ignore with this property. This approach is more flexible, but I don't think the complexity is worth it when a simple extension to cc-mode is within reach. >> It's easier and more flexible to simply allow the entire set of >> c-lang-defconst values to change. >=20 > It's the flexibility that worries me. Flexibility means complexity (of= > which there's already too much in CC Mode), and might open up a larger > "attack surface" for future bugs. >=20 > I've spent a lot of time trying to pin down exactly what your proposed > change does and how it does it, but amn't there yet. I only have the > before and after versions, not a detailed description of the change. I'd hoped my initial message clearly explained the overall approach. Briefly, we want to allow users to tell cc-mode to ignore "noise macros" when parsing. IMHO, the best way to do that is to let user customizations augment the existing set of "noise macro" keywords cc-mode defines for each language. Today, cc-mode builds various data structures from these keyword sets at compile time. In order for user customizations to have any effect, we have to build these data structures at runtime instead. Doing that has no perceivable effect on mode initialization performance and lets user customizations have an effe= ct. >> You claim that there is a great risk of negative side effects resultin= g >> from this change. >=20 > No. I've said there is a risk, without quantifying it. >=20 > One question which you haven't addressed yet is does the changed code > work properly on modes derived from a CC Mode mode? How easy is it to > create a `foo-extra-keywords' for such a mode? Trivial --- just include the variable in the c-lang-defconst calculation for the derived mode. > Another is does the change work properly under XEmacs? I don't see why it wouldn't. > What is the purpose of {java,idl,pike}-extra-keywords, given that these= > three languages don't have #defines? Consistency with the type defcustoms? Accommodations for weird custom preprocessors? Why not? >> I don't agree, and I don't see anyone else proposing, much less >> implementing, a solution to this problem, ..... >=20 > :-) This problem was first highlighted as such, by you, this month, no= t > several years ago. There's been a TODO in the code to this effect since 2005 in the definition of c-decl-hangon-kwds; my patch removes this TODO. > Your patch is complicated, it's disruptive, yet you > seem put out that I want to discuss it and understand it, rather than > just blindly applying it as it is. It seems your use of "You need to" > and "we have to" weren't mere hyperbole as I first thought. Forgive me= , > but I'm always suspicious when somebody tells me "there's no > alternative". There are always alternatives. The question is why is > your patch, which is not a straightforward or obvious change, the best > solution to the problem. What are the tradeoffs? I discussed some of them above. The chief risk is that users might customize cc-mode by altering its language constants. I strongly discount this risk, especially since users can *already* do that by creating derived modes. >> .... and cc-mode's being developed outside the tree makes it >> frustratingly slow and difficult to get much-needed fixes into core >> where users can see them. >=20 > Would it really be much faster if CC Mode were integrated? Not really.= > What makes things slow is the small number of people working on CC Mode= , > i.e. one, with occasional help from people like yourself. >=20 >>> As I said, I'm not at all happy at making such a massive change to CC= >>> Mode's architecture. There would surely be unforeseen consequences, = some >>> of which might well be negative. >=20 >> It's not a massive change in architecture. >=20 > As I said, I don't fully understand the change, yet. But moving > calculations from compile time to run time _is_ a change of > architecture, and it seems to me not to be small. All the cc-defvar variables get the same values they did before, by default. cc-engine parses text the same way it always has. All the cc-mode customization remains. My patch merely lets users customize some existing cc-mode constants, then makes these customizations have runtime effect by removing some unnecessary old optimizations in cc-mode initialization. If you call that a massive change in architecture, then what I call architecture might as well be plate tectonics. > It seems to me > that the rigid separation between language (e.g. C) and user > configuration is being broken down. How much easier will it be for a > user mistakenly to attempt to configure her CC Mode by messing around > with the c-lang-consts? Much easier --- but it's never been a priority in Emacs to prevent users from hanging themselves. Users should be drawn to the customization settings we provide, and if they choose to bypass them, they probably know well enough what they're doing. As I mentioned, determined users can already derived from cc-mode built-in modes. >> cc-mode can already evaluate these variables at runtime in the case of= >> a version mismatch. >=20 > That's a feature intended purely for CC Mode developers. Or for people who upgrade without recompiling derived modes. But it doesn't matter --- the dynamic-computation code is there and works fine. My change just uses it all the time instead of going down a different path involving dubious compile-time optimizations. --HT1Pre1xXNE4fIQTDBn14R4aO0cc0t9Ei Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTeTQiAAoJEMAaIROpHW7Ikm8P/iddZVTOJAHl3Cw/aqN0yrjz kfbzs8Kg+uJHotgU/CCL+oSTt0YURzc1bqqE45mfmcFhlHOnQOSv3Ly7tMpVD3LP lfR+nxHmT7w7GaOJAk07InHo95tuIwgongq9nx9r40Dhis4L+BhngNIY1Lg3bd+9 5GGYh4zE5Fr4v4PE284t8ny+x09BMtDpZ2d294zwHm84EC4nzPcT9gahS7Z0ylCe LvTzvmKgq5bkEdw9IDVB8BJ28bxWNLNXyTJIufwi+ffzqSpNlJgViOdRIcfSHZeq OSgQonSlJSHl/lsdba1LSM2Ux7zh6Za1A+kuPLIWHdrGOCYYJorq2YJjDj/WkhZ0 30jQfgvVi8H2RoPFkbQvO79K8kp8b5xrBOgSSk9fNkG8uFN5xnlS0QJ6T4Y+aC7N tfhgo8AVkj3C3BoZ8Q+k4uLfJz3nFihWzK14CpQNQMyOHO27nyUqwnBBdrJHvxCo kggCfe7kDJA5WN53I7IakDo5F4WswrJvIlBMwEFgPCGLqPtGZ0Wv/8+tUwb8OC3Z 22Ch/rsLNLoKKZ2EBQa+CM+zAqELPuFEB0xzQ2ChzFi/PdRWq23+tEeV9Eh6VuTU XjyPyguDF4KivudcfTZBjJ7wvb7k8hTqWyZvQ0QoroXx7o0lEPje2ltloM8GdyHT 2yB9AlbxCL+Vx0hGQNnP =RZSl -----END PGP SIGNATURE----- --HT1Pre1xXNE4fIQTDBn14R4aO0cc0t9Ei--