bug-gnu-emacs
[Top][All Lists]
Advanced

[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: John Prevost
Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order
Date: Tue, 11 Aug 2009 14:02:53 -0400
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (darwin)

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

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.  (First: "(emacs) Terminal Init" says
that the .emacs file can prevent loading of this by setting
term-file-prefix to nil.  Second: When run in --daemon mode, term init
files appear to be loaded once when the first terminal of that type is
created.)

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.

  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.

     The real problem with these keybindings is that they are set when
     the term/ns-win.el term init file is loaded, which as I noted above
     is *after* the user's startup file.  That means that in order to
     replace any bindings in this set (for example, if the user has his
     own super- bindings, or if he wants to replace S-mouse-1 with
     something a bit less strange, or even if he wants to replace the
     default behavior of dropping a file inserting its contents in the
     current buffer with the older behavior of dropping a file visiting
     that file), then the user *must* use term-setup-hook to run the
     appropriate commands after the term is loaded.

     For reference:

         $ gzip -dc ns-win.el.gz | grep key | grep global | wc -l
         83
         $ gzip -dc w32-win.el.gz | grep key | grep global | wc -l
         3
         $ gzip -dc x-win.el.gz | grep key | grep global | wc -l
         1

     And specifically:

          $ gzip -dc w32-win.el.gz | grep key | grep global
          (global-set-key [drag-n-drop] 'w32-drag-n-drop)
          (global-set-key [C-drag-n-drop] 'w32-drag-n-drop-other-frame)
          (global-set-key [language-change] 'ignore)

          $ gzip -dc x-win.el.gz | grep key | grep global
          ;;     (global-set-key [f10] 'ignore))

          whereas the ns-win.el bindings are all rather substantive.

  3) Another example of something the term/ns-win.el file really
     shouldn't be mucking with is:

          ;; Don't show the frame name; that's redundant with Nextstep.
          (setq-default mode-line-frame-identification '("  "))

     This does nothing to the display of windowed frames, but makes tty
     frames *fail* to display the frame number once the ns-win.el
     terminal init has been loaded.


A number of these features really need to be moved elsewhere, although I
can't say exactly where.  Some of them need to be turned off by default
(for example, the 44 super-based nextstep compatibility keybindings) or
at the very least configurable by use of a variable to select whether
they're desired.



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/Users/prevost1/Documents/src/emacs-23.1/nextstep/Emacs.app/Contents/Resources/etc/DEBUG
 for instructions.


In GNU Emacs 23.1.1 (i386-apple-darwin9.7.0, NS apple-appkit-949.46)
 of 2009-08-07 on TELPERION.WV.CC.CMU.EDU
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--prefix=/opt/emacs-23.1' '--with-ns''

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: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> y <down> <down> <down> <down> C-x b <return> 
C-c C-c n C-x C-g <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-1> C-c C-c y <help-echo> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-1> <down-mouse-1> 
<mouse-1> s-x M-x r e p o r <tab> <return>

Recent messages:
Checking new news...done
Auto-saving...
Sending...
Already sent message via mail; resend? (y or n) 
message-send: No methods specified to send by
Auto-saving...
Sending...
Already sent message via mail; resend? (y or n) 
Sending via mail...
Sending...done
kill-region: The mark is not set now, so there is no region






reply via email to

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