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

[John Prevost]

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.


> These sound problematic, as does 3 (not quoted). S-mouse-1 is bound to 
> the buffer font menu on other platforms, and we don't generally bind 
> keys with the super modifier, but if they are bound to functions that 
> the user would expect on nextstep derived platforms, then that might be 
> OK. However, binding anything to a power-off command within Emacs sounds 
> like a bad idea.

Well, the "power off" command in this case is a window event saying "Hi,
I am politely shutting down now", which is bound to
save-buffers-kill-emacs.  This is an example of something pretty
sensible.

I'm really not sure I think the large collection of "compatibility"
keybindings being activated by default is really a good idea, but now
that I've determined what's actually mucking with things (only the weird
behavior of ns-command-modifier as described above), it's a bit easier
to stomach.

That really leaves the only super troubling binding as:

;;; Allow shift-clicks to work similarly to under Nextstep
(define-key global-map [S-mouse-1] 'mouse-save-then-kill)
(global-unset-key [S-down-mouse-1])

which provides a very surprising behavior that is unlike any modern
computer that runs something "nextstep derived"

and the less troubling but rather irking:

(define-key global-map [home] 'beginning-of-buffer)
(define-key global-map [end] 'end-of-buffer)
(define-key global-map [kp-home] 'beginning-of-buffer)
(define-key global-map [kp-end] 'end-of-buffer)

which does change the behavior of the keys to a behavior common on a
popular modern nextstep-derived system, but with the addendum that it's
just as common for individual applications to treat those keys in the
fashion emacs treats them on other platforms.


Anyway, sorry for wasting your time with my mis-interpretation of what
was going on in the keybindings.  I'll try to verify future reports in
more depth before making them.


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

John.