From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: next bugfix release? Date: Thu, 20 Aug 2009 15:13:55 +0000 Message-ID: <20090820151355.GA6695@muc.de> References: <87praszybe.fsf@stupidchicken.com> <838whgik6y.fsf@gnu.org> <87prardif2.fsf@cyd.mit.edu> <200908191946.n7JJkpAm001304@godzilla.ics.uci.edu> <87vdkjsecq.fsf@stupidchicken.com> <20090819225645.GA2813@muc.de> <19084.34754.29507.98620@totara.tehura.co.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250781114 2669 80.91.229.12 (20 Aug 2009 15:11:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2009 15:11:54 +0000 (UTC) Cc: Chong Yidong , joakim@verona.se, emacs-devel@gnu.org, Dan Nicolaescu , Stefan Monnier , Eli Zaretskii To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 20 17:11:43 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Me9Ij-0008Ba-45 for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 17:11:42 +0200 Original-Received: from localhost ([127.0.0.1]:41557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me9Ii-0006wc-Id for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2009 11:11:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Me9IF-0006lL-9Z for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:11:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Me9IA-0006ix-Ez for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:11:10 -0400 Original-Received: from [199.232.76.173] (port=41310 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me9IA-0006il-6l for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:11:06 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:4562 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 1Me9I8-0007me-Fd for emacs-devel@gnu.org; Thu, 20 Aug 2009 11:11:04 -0400 Original-Received: (qmail 93480 invoked by uid 3782); 20 Aug 2009 15:11:02 -0000 Original-Received: from acm.muc.de (pD9E23E65.dip.t-dialin.net [217.226.62.101]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 20 Aug 2009 17:10:58 +0200 Original-Received: (qmail 6985 invoked by uid 1000); 20 Aug 2009 15:13:55 -0000 Content-Disposition: inline In-Reply-To: <19084.34754.29507.98620@totara.tehura.co.nz> 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114446 Archived-At: Hi, Nick, On Thu, Aug 20, 2009 at 11:16:18AM +1200, Nick Roberts wrote: > > Yes. It's one of these @dfn{wallpaper paste} bugs, where when you > > press an area of wallpaper firmly to the wall, the paste under it > > pops up another bit of wallpaper somewhere else. It's going to be > > a horrible bug to fix. Indeed, it may not be fixable, in the sense > > of doing the Right Thing under every reasonable circumstance. > Such 'bubbles', usually called regressions, .... No, that's not what I meant (although it is also a regression). I was talking about the high complexity caused by the number of things that all have to work right at the same time. The "fix" I made to cc-mode.el in July fixed one problem but created another. Getting them all working simultaneously is going to be hard. This complexity has increased recently due to the new feature "directory locals". I didn't become aware of this when it was introduced (my bad), and the person who wrote it wasn't aware of the trouble it would cause CC Mode (why should he be?). The trouble is, there are too many ways of setting a CC Mode "style variable" (such as c-basic-offset), @xref{Config Basics,,, ccmode}. It is not always the last setting which should prevail over previous ones. It is a complexity which nobody would design; it has emerged as such over CC Mode's lifetime, and is now a mess. the .dir-locals feature may have pushed the complexity over the edge of what is manageable. > ...., might be less likely to appear if, as Cyd suggested, there was a > CC mode equivalent of compilation.txt. Er, what's .../etc/compilation.txt about? It has an alleged explanation at the top, but that only makes sense if you already have some context. For example, you need to know why you'd "need matchers", and what sort of "matchers" they are. > I can't find this post now, so apologies if it reached a logical > conclusion. It might also be harder to implement than > compilation.txt, as expressions are probably not as self contained, > but some kind of testuite seems essential to prevent these issues from > recurring. CC Mode has an extensive test suite for (static) indentation and fontification. It doesn't have any such tests for things like initialisation of the mode, execution of CC Mode commands, or for indentation/fontification after buffer changes. I would very much welcome anybody stepping forward who had the time and energy to write these tests. > Nick -- Alan Mackenzie (Nuremberg, Germany).