From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: C file recoginzed as image file Date: Mon, 08 Jan 2007 17:34:12 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1168295681 13122 80.91.229.12 (8 Jan 2007 22:34:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2007 22:34:41 +0000 (UTC) Cc: dooglus@gmail.com, rms@gnu.org, lekktu@gmail.com, c.a.rendle@gmail.com, emacs-devel@gnu.org, "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 08 23:34:37 2007 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 1H434b-0007Gp-Gi for ged-emacs-devel@m.gmane.org; Mon, 08 Jan 2007 23:34:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H434a-000487-Sv for ged-emacs-devel@m.gmane.org; Mon, 08 Jan 2007 17:34:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H434P-00047N-Kj for emacs-devel@gnu.org; Mon, 08 Jan 2007 17:34:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H434O-00046m-4j for emacs-devel@gnu.org; Mon, 08 Jan 2007 17:34:21 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H434N-00046i-Rp for emacs-devel@gnu.org; Mon, 08 Jan 2007 17:34:19 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H434K-0004rd-FD; Mon, 08 Jan 2007 17:34:16 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 3F50D2CF102; Mon, 8 Jan 2007 17:34:16 -0500 (EST) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id CC71A3FE0; Mon, 8 Jan 2007 17:34:12 -0500 (EST) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 7CA244C6D25; Mon, 8 Jan 2007 17:34:12 -0500 (EST) Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Mon\, 08 Jan 2007 21\:48\:17 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:65014 Archived-At: >> > Basically, I think that determining the major mode for a given file should >> > neither give precedence to auto-mode-alist nor magic-mode-alist. Instead it >> > should consider both. Each one can associate a file with a set of possible >> > major modes (typically the set will be singleton) or say "don't know" >> > (which would be basically the set of all major modes). >> > >> > E.g. auto-mode-alist would give "don't know" for a file named "/b/c/foo" but >> > would give the set { perl-mode, prolog-mode } for a file named >> > "/b/c/foo.pl". Then magic-mode-alist would give other sets of modes (based >> > on things like the #! interpreter name, the -*- ... -*- cookie, etc...). >> > If the intersection of the two sets is a singleton, then use that >> > major-mode, otherwise query the user to decide whether to believe the file >> > name or the contents. After all, an inconsistently named file is generally >> > a sign that there's something wrong, so it's good to prompt the user >> > about it. >> >> This is definitely the best proposal I've seen so far for solving this. > But not something we should do before the release, IMO, however > tempting it may be. Obviously not. OTOH if we agree that it's the direction in which we want to go, than maybe it can give us some guidance as to which way to quickly solve the immediate problem. Stefan