From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Removing unloaded functions from auto-mode-alist. Date: Thu, 21 Apr 2005 11:30:13 -0400 Message-ID: References: <87zmvu6ba2.fsf@xs4all.nl> <85ll7e68ei.fsf@lola.goethe.zz> <854qe2ihhi.fsf@lola.goethe.zz> <85ekd5fo8e.fsf@lola.goethe.zz> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1114098656 23674 80.91.229.2 (21 Apr 2005 15:50:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2005 15:50:56 +0000 (UTC) Cc: monnier@iro.umontreal.ca, Lute.Kamstra.lists@xs4all.nl, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 21 17:50:54 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DOdwB-0007Na-35 for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2005 17:49:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DOe0v-0003SO-1r for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2005 11:54:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DOdup-0000TT-5O for emacs-devel@gnu.org; Thu, 21 Apr 2005 11:48:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DOdun-0000Sy-WD for emacs-devel@gnu.org; Thu, 21 Apr 2005 11:48:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DOdun-0007Cw-Or for emacs-devel@gnu.org; Thu, 21 Apr 2005 11:48:29 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DOdft-0004JQ-6q for emacs-devel@gnu.org; Thu, 21 Apr 2005 11:33:05 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1DOdd7-0005k4-GK; Thu, 21 Apr 2005 11:30:13 -0400 Original-To: David Kastrup In-reply-to: <85ekd5fo8e.fsf@lola.goethe.zz> (message from David Kastrup on Wed, 20 Apr 2005 17:43:13 +0200) 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:36239 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36239 The only conceivable way they could be called unwittingly by a user is if a TeX file from somebody else contained a "mode: TeX" or "mode: LaTeX" specification. The reason they would be used if some users types M-x TeX mode. It seemed plausible to me that some users would do that. It could be that nobody ever does. In any case, it seems clear to me that AUCTeX and tex-mode.el are alternative implementations of the same feature. It is right that the same names are used to invoke them both. Some users choose AUCTeX, some choose tex-mode.el, but they all want the same set of files to be handled by their choice. So they SHOULD be invoked by the same names. I explained already why nothing else makes sense. AUCTeX makes extensive use of mode cookies in local variables, and those are only obeyed in the lowercase version. The choice of AUCTeX vs tex-mode is a user preference and should not be embedded into files. That is right. It would be feasible to set up AUCTeX and tex-mode.el so that they have no overlap except for the primary entry points, which are tex-mode etc. and TeX-mode etc. However, it makes no sense for their primary entry points to be different. Whichever primary entry points are right for one of them are right for the other. They should all invoke whichever package the user prefers. Someone has suggested a separate package that would "select" AUCTeX, and to unload it to select tex-mode.el. The goal make sense, but there should be no need to ever unload this package. Once loaded, it could select one package or the other according to one or more user option variables. To select one package or the other, you would just set the variables, so you would not need to unload it. However, this package and its user options could just as well be included in AUCTeX. I see no benefit in making it a separate file.