From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#6997: Loading w32-fns under X11 signals an error Date: Mon, 13 Sep 2010 16:51:20 +0200 Message-ID: References: <8362ya5cwu.fsf@gnu.org> <831v8x6fb2.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1284390642 27088 80.91.229.12 (13 Sep 2010 15:10:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Sep 2010 15:10:42 +0000 (UTC) Cc: 6997@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 13 17:10:40 2010 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 1OvAg3-00025T-Dl for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Sep 2010 17:10:40 +0200 Original-Received: from localhost ([127.0.0.1]:35016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvAg2-0005tj-C3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Sep 2010 11:10:38 -0400 Original-Received: from [140.186.70.92] (port=41891 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvAfs-0005sj-TM for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2010 11:10:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvAfr-0002Eh-KC for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2010 11:10:28 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35905) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvAfr-0002Ed-HW for bug-gnu-emacs@gnu.org; Mon, 13 Sep 2010 11:10:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OvAM6-0004ez-TU; Mon, 13 Sep 2010 10:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2010 14:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6997 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6997-submit@debbugs.gnu.org id=B6997.128438936017902 (code B ref 6997); Mon, 13 Sep 2010 14:50:02 +0000 Original-Received: (at 6997) by debbugs.gnu.org; 13 Sep 2010 14:49:20 +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 1OvALQ-0004eh-I4 for submit@debbugs.gnu.org; Mon, 13 Sep 2010 10:49:20 -0400 Original-Received: from impaqm3.telefonica.net ([213.4.138.3]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvALN-0004eb-Ek for 6997@debbugs.gnu.org; Mon, 13 Sep 2010 10:49:18 -0400 Original-Received: from IMPmailhost5.adm.correo ([10.20.102.126]) by IMPaqm3.telefonica.net with bizsmtp id 6EAH1f00M2jdgqJ3PErUDi; Mon, 13 Sep 2010 16:51:28 +0200 Original-Received: from ceviche.home ([83.46.195.89]) by IMPmailhost5.adm.correo with BIZ IMP id 6ErR1f00b1wC3DP1lErSbD; Mon, 13 Sep 2010 16:51:28 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id B1D266637B; Mon, 13 Sep 2010 16:51:20 +0200 (CEST) In-Reply-To: <831v8x6fb2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Sep 2010 13:41:53 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 13 Sep 2010 10:50:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:40131 Archived-At: >> They can define new functions and variables, as well as load other >> files, and even set a few things up but only to *add* behavior, not to >> *change* behavior. > Not sure how instrumental that definition is. Doesn't addition > constitute a change? I already mentioned this loop-hole: they do change the semantics of the language but in a way that's usually accepted as "harmless": it only gives meaning to things which earlier were errors. I'm not sure exactly what you're trying to argue here. It's been policy for a long time now that loading files should be harmless, so many files were changed so that (load "foo") doesn't enable foo-mode any more, but instead just defines foo-mode (and then foo-mode is marked auto-loaded so the user can just call (foo-mode 1) rather than (load "foo") in his .emacs). Clearly, load foo.el will make changes in that it will define new functions and variables, may add things to debug-ignored-errors and whatnot. I can't believe you really don't know what I mean by "harmless". > Let's take a practical example: w32-convert-standard-filename. Do you > want it to become effective or not? What means "effective"? Do I want it to be defined just by loading w32-fns.el? Very much so, yes. Do I want convert-standard-filename to use it just because I've loaded w32-fns.el? Well, no since it would then change the behavior of Emacs. And indeed the current code behaves correctly in this respect, AFAICT. > If your answer is NO, then what about someone (not called Stefan) who > wants to test some issue for which w32-convert-standard-filename must > be in effect? He'll have to weak the code/variables that decide whether to call w32-convert-standard-filename or not. >> > IOW, can you come up with a general enough definition of the reason(s) >> > for loading w32-fns on non-w32 systems? >> The same reason why I might want to load diff-mode.el without ever >> wanting to use that mode. >> E.g. to complete function/variable names, or to browse customize data, ... > That's rather a narrow need. Sounds like lots of labor to gain very > little (why does it matter to have symbols that begin with a `w32-'?). Yes, it's a lot of work for fairly little gain. Note that I bumped into it because my code couldn't care less that "w32-" is special, not because I specifically wanted to have symbols starting with "w32-". Stefan