bug#6997: Loading w32-fns under X11 signals an error

bug#6997: Loading w32-fns under X11 signals an error

[Stefan Monnier]

Package: Emacs
Version: 24.0.50

The title says it.  It probably also messes with things, additionally to
signalling an error.  Of course, you will say "don't do that", but
remember that files may be loaded for all kinds of reasons, so they
should be harmless.


        Stefan

PS: I bumped into the problem while experimenting with a system that
lets completion work on *all* Emacs variables and functions, including
those defined in files not-yet loaded.




In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2010-09-04 on ceviche
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
configured using `configure  'CFLAGS=-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DSYNC_INPUT -DENABLE_CHECKING -DXASSERTS -DFONTSET_DEBUG -g -O1 -I/usr/include/GNUstep' 'LDFLAGS=-L/home/monnier/src/Xaw3d' 'CPPFLAGS=-I/home/monnier/src/Xaw3d' '--enable-maintainer-mode''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_CH.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Minibuffer-Area

Minor modes in effect:
  diff-auto-refine-mode: t
  electric-pair-mode: t
  electric-indent-mode: t
  url-handler-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <help-echo> 
<switch-frame> <select-window> <switch-frame> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
C-h v k e y - t r a <tab> <return> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> C-h f 
w 3 2 - f n C-a C-k M-x f i - l i b <tab> <return> 
C-y <return> q <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> M-x M-p <return> M-p 
C-e <tab> <return> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <select-window> <switch-frame> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <select-window> <switch-frame> <select-window> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
<select-window> <switch-frame> <select-window> <switch-frame> 
<switch-frame> <switch-frame> <select-window> <switch-frame> 
M-x r e p o <tab> - e m <tab> <return>

Recent messages:
Hunk already applied
Mark saved where search started
Hunk already applied
Saving file /home/monnier/src/emacs/work/lisp/progmodes/cfengine.el...
Wrote /home/monnier/src/emacs/work/lisp/progmodes/cfengine.el
Mark saved where search started
Quit [3 times]
Entering debugger...
Back to top level.
Making completion list...

Load-path shadows:
/usr/share/emacs23/site-lisp/bbdb/bbdb-migrate hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-migrate
/usr/share/emacs23/site-lisp/bbdb/bbdb hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb
/usr/share/emacs23/site-lisp/bbdb/bbdb-rmail hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-rmail
/usr/share/emacs23/site-lisp/bbdb/bbdb-gnus hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gnus
/usr/share/emacs23/site-lisp/bbdb/bbdb-w3 hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-w3
/usr/share/emacs23/site-lisp/bbdb/bbdb-com hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-com
/usr/share/emacs23/site-lisp/bbdb/bbdb-merge hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-merge
/usr/share/emacs23/site-lisp/bbdb/bbdb-ftp hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-ftp
/usr/share/emacs23/site-lisp/bbdb/bbdb-sc hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-sc
/usr/share/emacs23/site-lisp/bbdb/bbdb-vm hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-vm
/usr/share/emacs23/site-lisp/bbdb/bbdb-gui hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gui
/usr/share/emacs23/site-lisp/bbdb/bbdb-print hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-print
/usr/share/emacs23/site-lisp/bbdb/bbdb-hooks hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-hooks
/usr/share/emacs23/site-lisp/bbdb/bbdb-mhe hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-mhe
/usr/share/emacs23/site-lisp/bbdb/bbdb-whois hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-whois
/usr/share/emacs23/site-lisp/bbdb/bbdb-snarf hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-snarf

Features:
(mail-extr message sendmail rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
mail-utils mailheader emacsbug sort mpc pcase macroexp hideif cpp
cmacexp cc-mode cc-fonts cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs rx which-func imenu align find-file sml-proc sml-mode
sml-move sml-defs sml-util grep skeleton derived smie cl-specs
whitespace dabbrev vc-annotate cal-china lunar solar cal-dst cal-bahai
cal-islam cal-hebrew holidays hol-loaddefs cal-french diary-lib
diary-loaddefs mule-util cal-move cal-menu calendar cal-loaddefs debug
log-edit pcvs-util smerge-mode add-log diff-mode multi-isearch informat
info texinfo vc-sccs vc-svn vc-cvs vc-rcs vc-dir ewoc vc vc-dispatcher
executable copyright compile xscheme warnings trace testcover scheme
byte-opt unsafep re-builder shadow inf-lisp ielm pp comint ring
gmm-utils find-func elp edebug cust-print bytecomp byte-compile cus-edit
cus-start cus-load wid-edit vc-bzr sha1 hex-util filecache server
noutline outline easy-mmode flyspell ispell eldoc checkdoc regexp-opt
thingatpt help-mode easymenu view prog-mode finder-inf package electric
url-handlers url-parse auth-source gnus-util url-vars mm-util mail-prsvr
reveal autoinsert uniquify advice help-fns advice-preload savehist
minibuf-eldef cl cl-19 cl-loaddefs proof-site proof-autoloads pg-vars
bbdb-autoloads agda2 tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page
newcomment menu-bar rfn-eshadow timer select scroll-bar mldrag mouse
jit-lock font-lock syntax font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

bug#6997: Loading w32-fns under X11 signals an error

[Juanma Barranquero]

> The title says it.  It probably also messes with things, additionally to
> signalling an error.  Of course, you will say "don't do that", but
> remember that files may be loaded for all kinds of reasons, so they
> should be harmless.

You can avoid the warning with judicious application of

  (when (fboundp 'set-message-beep)
    ...)

and

 (when (boundp 'w32-charset-info-alist)
  ...)

but making the loading harmless will likely need some more uglifying
of the code.

Perhaps these really-specific modules should just have protection guards:

(when (eq system-type 'windows-nt)
  ;;; rest of the file
  )
(provide 'xxx)

    Juanma

bug#6997: Loading w32-fns under X11 signals an error

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 08 Sep 2010 11:33:09 +0200
> Cc: 
> 
> The title says it.  It probably also messes with things, additionally to
> signalling an error.  Of course, you will say "don't do that", but
> remember that files may be loaded for all kinds of reasons, so they
> should be harmless.

"Harmless" in what sense?  Should they do nothing at all?  Probably
not, or else you wouldn't be loading them, right?

Even in your specific use-case, did you want the w32-fns functions to
end up in the obarray or not?

IOW, can you come up with a general enough definition of the reason(s)
for loading w32-fns on non-w32 systems?  Without such a definition, I
don't see how can we do anything except making the entire file be
ignored on any system but w32.

bug#6997: Loading w32-fns under X11 signals an error

[Stefan Monnier]

>> The title says it.  It probably also messes with things, additionally to
>> signalling an error.  Of course, you will say "don't do that", but
>> remember that files may be loaded for all kinds of reasons, so they
>> should be harmless.

> "Harmless" in what sense?

That Emacs works as well after loading the file than before.
You know, like language extensions: 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.

> Should they do nothing at all?  Probably
> not, or else you wouldn't be loading them, right?

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.

> Even in your specific use-case, did you want the w32-fns functions to
> end up in the obarray or not?

Of course, that was the whole point since I wanted to complete on
function names.

> 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, ...


        Stefan

bug#6997: Loading w32-fns under X11 signals an error

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 6997@debbugs.gnu.org
> Date: Mon, 13 Sep 2010 11:27:30 +0200
> 
> 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?

Let's take a practical example: w32-convert-standard-filename.  Do you
want it to become effective or not?

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?

> > 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-'?).

bug#6997: Loading w32-fns under X11 signals an error

[Stefan Monnier]

>> 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

bug#6997: Loading w32-fns under X11 signals an error

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 6997@debbugs.gnu.org
> Date: Mon, 13 Sep 2010 16:51:20 +0200
> 
> I'm not sure exactly what you're trying to argue here.

I'm not trying to argue at all, just trying to understand what you
want to be done about w32-fns.el.

> 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.

But many .el files have top-level expressions other than defun and
defvar.  These don't just define functions and variables, they
actually change the behavior.  w32-fns.el does that as well, but it is
not the only one.  I understand that you want all these top-level
expressions be conditioned by w32?

> > 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-".

How about teaching your code not to load any file that has w32 (or
dos, or ns, for that matter) in its name?  Or perhaps we should have a
list of platform-specific .el files that are not "safe" for loading on
other platforms?  Maybe that will be easier than modifying all those
to make them "Stefan-harmless"?

bug#6997: Loading w32-fns under X11 signals an error

[Stefan Monnier]

>> I'm not sure exactly what you're trying to argue here.
> I'm not trying to argue at all, just trying to understand what you
> want to be done about w32-fns.el.

I'd like w32-fns.el to be harmless even on platforms where it's normally
not loaded.  I understand it's not a very high priority item.

> But many .el files have top-level expressions other than defun and
> defvar.  These don't just define functions and variables, they
> actually change the behavior.

Actually, very few have toplevel expressions that modify the behavior,
nowadays.  The main remaining ones are the preloaded files, so the real
problematic ones are most likely the files that are preloaded on some
configs and not on others.

> w32-fns.el does that as well, but it is not the only one.
> I understand that you want all these top-level expressions be
> conditioned by w32?

They can be conditioned on system-type, yes, tho it doesn't have to be
a toplevel test: the way w32-convert-standard-filename does it is fine
as well.

> How about teaching your code not to load any file that has w32 (or
> dos, or ns, for that matter) in its name?

Of course, that's pretty much the workaround I'm using right now, but
it's still just a workaround.  I may very well want to complete w32-*
names under GNU/Linux after all.

> Or perhaps we should have a list of platform-specific .el files that
> are not "safe" for loading on other platforms?

Actually, we should be aiming towards a code-base where Emacs can be
built with w32 and X11 and ns backends at the same time (after all w32
platforms can run X11 apps as well and GNUstep works on top of X11).
This is longish term and I don't necessarily want you to start working
on it, but rather it should be used as a guide for how best to solve
problems we encounter.


        Stefan

bug#6997: Loading w32-fns under X11 signals an error

[Juanma Barranquero]

On Tue, Sep 14, 2010 at 11:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Actually, very few have toplevel expressions that modify the behavior,
> nowadays.

But the simple fact of defining w32-* functions and variables can
modify behavior. Searching for "f?boundp 'w32-" gets hits on
non-w32-specific files: comint, facemenu, isearch, ls-lisp,
international/mule-cmds, mail/mailclient and net/tramp-compat.

> Actually, we should be aiming towards a code-base where Emacs can be
> built with w32 and X11 and ns backends at the same time

That'd be the day.

    Juanma

bug#6997: Loading w32-fns under X11 signals an error

[Glenn Morris]

Version: 27.1

Fixed in 109a3bf.