From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: [RFC PATCH] setting indentation styles via `c-file-style' fails to actually change indentation Date: Wed, 18 May 2011 21:28:34 +0100 Message-ID: <87pqnfu51p.fsf@spindle.srvr.nix> References: <87pqngewwp.fsf@spindle.srvr.nix> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305750533 21684 80.91.229.12 (18 May 2011 20:28:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 18 May 2011 20:28:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 18 22:28:46 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QMnMI-0008IH-6K for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 22:28:45 +0200 Original-Received: from localhost ([::1]:35306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMnMG-0006n1-U7 for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 16:28:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMnME-0006ms-7m for emacs-devel@gnu.org; Wed, 18 May 2011 16:28:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMnMD-0007Yp-6B for emacs-devel@gnu.org; Wed, 18 May 2011 16:28:38 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:38587 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMnMC-0007Yc-QR for emacs-devel@gnu.org; Wed, 18 May 2011 16:28:37 -0400 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.4/8.14.3) with ESMTP id p4IKSYWr026692; Wed, 18 May 2011 21:28:34 +0100 Original-Received: (from nix@localhost) by esperi.org.uk (8.14.4/8.12.11/Submit) id p4IKSYPC009266; Wed, 18 May 2011 21:28:34 +0100 Emacs: because extension languages should come with the editor built in. In-Reply-To: (Stefan Monnier's message of "Tue, 17 May 2011 21:17:50 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-DCC-x.dcc-servers-Metrics: spindle 104; Body=2 Fuz1=2 Fuz2=2 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 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:139492 Archived-At: On 18 May 2011, Stefan Monnier outgrape: > But I just want to take the opportunity to say that all this CC style > business is much too complex for its own sake, and as a result we've > seen and keep seeing new problems that require additional hacks on top > of hacks to try and "fix" things. Gods, yes. Most of this appears to be the interaction of backward- compatibility kludge atop backward-compatibility kludge. The indentation engine works great (the most nearly flawless I've ever seen), and the style engine needs a certain degree of complexity -- things like inherited styles are a must, because so many styles in the real world are almost like one of cc-mode's except for a couple of tiny differences. But the support for configuration through global variables *or* styles, with styles possibly taking effect by localizing variables in one buffer or possibly taking effect by making them local to all buffers... well, it's just ridiculous. Rip out all that stuff and use the recommended configuration only (style variables automatically localized to the current buffer, direct setting of style variables always overrides the style itself via 'set-from-style) and ditch all the rest. I'm fairly sure that half the configurations implied by the current set of variables are broken at any one time, because there are so many that nobody can really test them. (That's an alternative: a decent testing framework for this stuff, such that we could be sure it didn't break. Then it wouldn't matter so much how complex it got, except insofar as it bends the brains of people trying to look at the code.) -- NULL && (void)