From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.bugs Subject: bug#8158: Definition of auto-mode-alist Date: Wed, 2 Mar 2011 23:30:33 +0100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1299105460 22564 80.91.229.12 (2 Mar 2011 22:37:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2011 22:37:40 +0000 (UTC) Cc: 8158@debbugs.gnu.org To: Reuben Thomas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 02 23:37:35 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Puufk-0007IL-LU for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Mar 2011 23:37:32 +0100 Original-Received: from localhost ([127.0.0.1]:57514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Puufj-0002NJ-Vr for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Mar 2011 17:37:32 -0500 Original-Received: from [140.186.70.92] (port=36964 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuufA-00025U-Nb for bug-gnu-emacs@gnu.org; Wed, 02 Mar 2011 17:36:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Puuf8-0005GE-EJ for bug-gnu-emacs@gnu.org; Wed, 02 Mar 2011 17:36:56 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Puuf8-0005G6-CK for bug-gnu-emacs@gnu.org; Wed, 02 Mar 2011 17:36:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PuuZS-0005QA-6I; Wed, 02 Mar 2011 17:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Mar 2011 22:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8158 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 8158-submit@debbugs.gnu.org id=B8158.129910506120832 (code B ref 8158); Wed, 02 Mar 2011 22:31:02 +0000 Original-Received: (at 8158) by debbugs.gnu.org; 2 Mar 2011 22:31:01 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PuuZR-0005Pw-AL for submit@debbugs.gnu.org; Wed, 02 Mar 2011 17:31:01 -0500 Original-Received: from mail-ew0-f44.google.com ([209.85.215.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PuuZP-0005Pg-3P for 8158@debbugs.gnu.org; Wed, 02 Mar 2011 17:30:59 -0500 Original-Received: by ewy9 with SMTP id 9so165639ewy.3 for <8158@debbugs.gnu.org>; Wed, 02 Mar 2011 14:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=z4rug7Ai2xk2jN4kxww/6e0ng5K5l4RMlp/fzvXtolo=; b=iDsxJMnc9HwSCLHK4u2ZYiL9Ynl7f92IdXXALMuyXfUwK3ORwBMZRBxJcaSh0Z2hkb gSAadVGm9hxMgjDx1YSu30orDSkkIsK1Yh3BevDSu90G3ZMEJCu39pBLxwOnrhfaUf30 INc8Nuue23epYlP4lD4gvM57izVCFJsJJ9C3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=FuHZDEGqP9S1P6k/q0jGOcvHopLv7lpXdHKIE8R+kudR8zzAqIANt/+nWWJTnw5SkD STCgsthlG9xhuvNxKtQdYN8D3mo+xPOzR0c6Sx3Kfdhr97Pqd+1cfRsnClx5+jS+IhqD f4cmv0Jlh+USW1KouPs0uLU2nXeJsmKNILlbM= Original-Received: by 10.213.2.204 with SMTP id 12mr578766ebk.94.1299105053221; Wed, 02 Mar 2011 14:30:53 -0800 (PST) Original-Received: by 10.213.108.136 with HTTP; Wed, 2 Mar 2011 14:30:33 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 02 Mar 2011 17:31:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:44529 Archived-At: On Wed, Mar 2, 2011 at 11:22 PM, Reuben Thomas wrote: > On 2 March 2011 22:18, Lennart Borgman wrote: >> On Wed, Mar 2, 2011 at 11:02 PM, Reuben Thomas wrote: >>> A comment in files.el says: >>> >>> =C2=A0;; Note: The entries for the modes defined in cc-mode.el (c-mode, >>> =C2=A0;; c++-mode, java-mode and more) are added through autoload >>> =C2=A0;; directives in that file. =C2=A0That way is discouraged since i= t >>> =C2=A0;; spreads out the definition of the initial value. >>> >>> Isn't this a bit unmodular as Emacs continues to grow, and given loadde= fs.el? >>> >>> If the maintainers agree, then the last sentence should be changed to >>> encourage the removal of the initial values back into the relevant >>> mode files. >> >> I think I disagree. This sort of information must be coordinated so it >> need to be in a central place. > > Why does it have to be coordinated? The most obvious reason seems to > me "to avoid clashes", but this is detectable by parsing > auto-mode-alist. Generating a warning when there are clashing settings > for the same suffix would also be handy for 3rd party modes, which > cannot integrate their information in this way. There are not only file extension clashes (which I suppose is what you think of), but also mode selection clashes. I think the control of this must be given to the user and that requires a central system. The current system is not optimal however. I have tried to implement an addition to it in majmodpri.el in nXhtml. "majmodpri" stands for "major modes priorities" and that is just what it implements. (The implementation is not as easy to use as I would like it to be. Customization features for lists in Emacs is lacking a lot of functionalities IMO.) > For modes that are part of Emacs, this system is fragile, as it's easy > to forget that part of the mode is in files.el. This is true and perhaps part of the implementation should actually be distributed. However it must then be implemented in a way that still leaves control to the user. Just loading a new elisp file should not override old choices. (See above for clarification.)