bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order

[Dan Nicolaescu]

John Prevost <prevost1@cert.org> writes:

  > Jason Rumney <jasonr@gnu.org> writes:
  > 
  > > The term/*-win.el files are preloaded in Emacs 23 on the platforms they 
  > > are appropriate for.
  > > So they are certainly loaded before the user's init file.
  > 
  > Hmm.  This does seem to be correct--I was using a pre-release version at
  > one point while trying to get this going, and that may have confused
  > me, if things behaved differently.
  > 
  > The keybindings can be overridden, which I've just tested, although
  > there's still something weird going on (see below).
  > 
  > Is it only the term/*-win.el files that are so pre-loaded?  It might be
  > good to document the fact in the info documentation for
  > Terminal-specific Initialization ((emacs) Terminal Init) that these
  > files are special and therefore cannot be bypassed by -q or setting
  > term-file-prefix in your .emacs file.  (I must admit I was somewhat
  > confused when I was trying to figure out what was happening where and
  > when and modified the term/ns-win.el file... which had no effect.  Now
  > it is more clear.)
  > 
  > >>   1) ns-win.el contains a number of defvaralias declarations intended to
  > >>      make transition from the old "mac-X" variables to the new "ns-X"
  > >>      variables (e.g. mac-command-modifier -> ns-command-modifier)
  > >>      easier.  These defvaraliases run after the user's startup file,
  > >>      which means that they are not in effect when the user sets the
  > >>      old-style "mac-X" variables.
  > >>   
  > >
  > > Is this something you have actually seen happening, or are you 
  > > extrapolating based on your assumption above?
  > 
  > My apologies.  This is not exactly what is happening, as I've determined
  > after I went back to reproduce the problem.  Please let me know if I
  > should make a fresh bug report for this problem:
  > 
  > The problem it only appears to happen if emacs is started in --daemon
  > mode.  So my suppositions about what exactly is happening are clearly
  > wrong.  It does not matter if mac-command-modifier or
  > ns-command-modifier is used, the problem happens either way.
  > 
  > Here's some test code:
  > 
  > (setq mac-command-modifier 'meta)
  > 
  > (message (symbol-name mac-command-modifier))
  > 
  > (defun after-term-test ()
  >   (message (symbol-name mac-command-modifier))
  >   (message "Terminal setup done"))
  > 
  > (add-hook 'term-setup-hook 'after-term-test)
  > 
  > If the above is the .emacs file, and the NS version of emacs is started
  > normally, it results in the following in *Messages* after normal
  > startup:
  > 
  > meta
  > For information about GNU Emacs and the GNU system, type C-h C-a.
  > meta
  > Terminal setup done
  > 
  > If I then do C-h k (command)-x, I get:
  > 
  > M-x runs the command execute-extended-command, which is an interactive
  > 
  > If I run in daemon mode, I get the same messages as above output to
  > stdout, but when I then use emacsclient to create a window and do C-h k
  > (command)-x, I get:
  > 
  > s-x runs the command kill-region, which is an interactive compiled
  > 
  > If I then set mac-command-modifier to meta in that session, command is
  > interpreted as meta, and it continues to be interpreted that way after I
  > have closed the emacsclient session and started a new one.
  > 
  > If after starting the daemon I run emacsclient, I can see that the
  > setting is in place:
  > 
  > $ emacsclient -e 'ns-command-modifier'
  > meta
  > 
  > And then if I immediately check again after creating my first windowed
  > session:
  > 
  > $ emacsclient -e 'ns-command-modifier'
  > super
  > 
  > If I instead create a TTY terminal, the value of ns-command-modifier
  > does not change.  It is only the first time I create a windowed terminal
  > that it changes.
  > 
  > So the defvaraliases are just fine, but something else is resetting the
  > value of ns-command-modifier (and friends) in --daemon mode only, after
  > the startup file has been run, when the first nextstep windowed terminal
  > is created.


nsterm.m:ns_set_default_prefs


  > Please do let me know if I should submit all or part of this message as
  > separate bug reports.

IMHO that would be a good idea.
Even better, submit it together with patches that fix the problems that
you found, that would make it much more likely to get things going.
There are a lot of bugs filed for the NS port and very few people work
on fixing them...