From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.bugs Subject: Re: bug#1756: awk-mode: An empty line is not a paragraph separator (should be) Date: Thu, 8 Jan 2009 16:25:51 +0000 Message-ID: <20090108162551.GB5284@muc.de> References: <87sko35t3u.fsf@iki.fi> <20090105183502.GC2501@muc.de> <87hc4dbnua.fsf@iki.fi> <20090106161541.GB5612@muc.de> <87fxjvt6tj.fsf@iki.fi> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1231430975 15438 80.91.229.12 (8 Jan 2009 16:09:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Jan 2009 16:09:35 +0000 (UTC) Cc: bug-cc-mode@gnu.org, bug-gnu-emacs@gnu.org, 1756@emacsbugs.donarmstrong.com To: Teemu Likonen Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Thu Jan 08 17:10:44 2009 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by lo.gmane.org with esmtp (Exim 4.50) id 1LKxSz-0006p5-RL for sf-cc-mode-help@m.gmane.org; Thu, 08 Jan 2009 17:10:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by 3yr0jf1.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1LKxRj-0005JY-Gx; Thu, 08 Jan 2009 16:09:23 +0000 Original-Received: from sfi-mx-3.v28.ch3.sourceforge.com ([172.29.28.123] helo=mx.sourceforge.net) by 3yr0jf1.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1LKxRi-0005JI-19 for cc-mode-help@lists.sourceforge.net; Thu, 08 Jan 2009 16:09:22 +0000 Received-SPF: neutral (3b2kzd1.ch3.sourceforge.com: 140.186.70.10 is neither permitted nor denied by domain of muc.de) client-ip=140.186.70.10; envelope-from=acm@muc.de; helo=fencepost.gnu.org; Original-Received: from fencepost.gnu.org ([140.186.70.10]) by 3b2kzd1.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) id 1LKxRe-0007NB-VT for cc-mode-help@lists.sourceforge.net; Thu, 08 Jan 2009 16:09:21 +0000 Original-Received: from mail.gnu.org ([199.232.76.166]:56979 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKxQG-0001NK-9s for bug-cc-mode@gnu.org; Thu, 08 Jan 2009 11:07:52 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKxRN-0006rQ-Lp for bug-cc-mode@gnu.org; Thu, 08 Jan 2009 11:09:04 -0500 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0 Original-Received: from colin.muc.de ([193.149.48.1]:2604 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKxRM-0006ql-AY for bug-cc-mode@gnu.org; Thu, 08 Jan 2009 11:09:00 -0500 Original-Received: (qmail 67159 invoked by uid 3782); 8 Jan 2009 16:08:57 -0000 Original-Received: from acm.muc.de (pD9E23A4C.dip.t-dialin.net [217.226.58.76]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 08 Jan 2009 17:08:48 +0100 Original-Received: (qmail 8194 invoked by uid 1000); 8 Jan 2009 16:25:51 -0000 Content-Disposition: inline In-Reply-To: <87fxjvt6tj.fsf@iki.fi> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-Spam-Score: -2.8 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -4.0 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [140.186.70.10 listed in list.dnswl.org] 1.2 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) X-Headers-End: 1LKxRe-0007NB-VT X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:5286 gmane.emacs.bugs:23920 Archived-At: Hi, Teemu, On Wed, Jan 07, 2009 at 06:32:56PM +0200, Teemu Likonen wrote: > Alan Mackenzie (2009-01-06 16:15 +0000) wrote: > >> After "C-c . awk RET" it changes to this: > >> "[ \t]*\\(\\(#+\\)[ \t]*\\)?$\\|^\f" > > ^^ > >> Even though I chose to override the style settings "#*" changes to "#+". > > I don't think this is a bug. You asked for "awk" style to be set on > > the buffer, and this is exactly what you got. > Well, I asked that, but I had also explicitly asked to override style > settings (through the customize interface). My opinion is that the > current behavior is so confusing that it's either a bug or simply wrong > design decision. It's very confusing. I get confused, even though I maintain it and I wrote the bit of the manual that describes it. I honestly believe the current functionality is "over-engineered", simply too feature-rich for the job it does. However, it's there and (?lots of) people would complain loudly if any features were abolished. The style-variables each have a global default, a value in the current style and a buffer local value in each buffer (which could be either of the two previous values). In turn, the style is either an explicitly selected style or the default style. Additionally, this all interacts with the customisation facility, which has no notion of buffer local variables. I admit, starting from scratch, nobody would design it this way. The other thing, I don't think it matters too much exactly how the style system works. What is bad is when it confuses people, or creates expectations which won't be satisfied. (See below.) > I don't mean to complain too loudly, though. See below. Complaining loudly is OK on this mailing list. :-) > > I am guessing that the cause is in the fine CC Mode manual, [...] > > [...] perhaps it would be better if amended something like this: > > When you initialize the buffer, the settings are made in the > > following order. So if you make conflicting settings in several of > > these ways, the way that takes precedence is the one that appears > > latest in the list(2): > > Style > > Top-level command or "customization interface" > > Hook > > File Style > > ---------- Footnotes ---------- > > (2) If you later call `c-set-style' (C-c .), all the style variables > > will get set to the style you select. > > What do you think? > Well, my real opinion first: User's explicit "override style settings" > setting should just do that: override style settings no matter what > style changes the user does while editing the buffer. OK, this is the text in the M-x customize-variable screen. > For example, user may want to choose certain custom comment prefix > settings and, while editing the code, she may want to experiment with > different style settings or convert the code from one style to another. > Logically, if she wants to get comment prefix settings from a > pre-defined style she chooses "Use style settings" > (c-comment-prefix-regexp). If she wants to use her own comment prefix > she chooses "Override style settings". I think this is the most > intuitive behaviour. Currently user can only override style settings > for the initial style state. This could be implemented in `c-set-style', [by looking at the global value of c-comment-prefix-regexp, and using this value rather than the style's value if the global value isn't 'set-from-style]. Feel free to ignore the bit in the brackets if it doesn't make much sense! But this would mean that c-set-style would not do exactly what it says. With all due respect, I think this would be at least as un-intuitive as the current mechanism. Of course, I could create a new option saying which of these is to be preferred, but that would add even more confusion into the mix. > But if you choose to maintain the current behaviour anyway, then I'd say > that the changes you suggested for the documentation are very good. I'd > also suggest to change the documentation of c-comment-prefix-regexp > variable so that it tells how the variable effects in the practice. Agreed. This also applies to the other style variables. What I think is buggy at the moment is that: o - `customize-variable' doesn't say "Global default value" anywhere. o - "Override style settings" is confusing. Maybe "Set explicit value" would be better. > Anyway, the empty-line bug is the main thing. If that bug in Awk mode > gets fixed (you already did with that patch) then there shouldn't be > much need for changing comment prefixes in the first place. So I'm > really more on the "thank you" side than on "complaining" side. :-) Cheers! I've committed the patch to the Emacs repostory (which will become the future Emacs-23). But it would still be nice to get `customize-variable' working nicely with CC Mode. -- Alan Mackenzie (Nuremberg, Germany). ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB