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

From: Jason Rumney <[email-masked]>
Date: Wed, 12 Aug 2009 20:58:17 +0800

John Prevost wrote:
> The term/ns-win.el terminal init file does a lot of questionable things,
> and more importantly, it seems to assume the wrong run order.
> Specifically, a lot of the items in the file assume that they're run
> before the user's startup file is loaded, when in fact this file is run
> after the user's startup file.
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.

> Specifically problemmatic:
>
>   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?

>   2) ns-win.el contains a number of rather questionable keyboard
>      bindings on the global-map.  Some of these are nextstep-specific
>      events (ns-power-off, ns-open-file, etc.).  More upsetting is a
>      wholesale slaughter of the super- modifier, with some 44
>      keybindings set for "compatibility" bindings for that modifier.
>      Extremely troubling is the binding for S-mouse-1 to
>      'mouse-save-then-kill by default, which may be a standard nextstep
>      behavior, but is definitely not a standard mac behavior.
>   

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.