[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jason Rumney
Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order
Date: Wed, 12 Aug 2009 20:58:17 +0800
User-agent: Mozilla-Thunderbird (X11/20090103)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]