From: John Prevost <prevost1@cert.org>
To: bug-gnu-emacs@gnu.org
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 [thread overview]
Message-ID: <m2zla6jkj6.fsf@TELPERION.WV.CC.CMU.EDU> (raw)
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
next reply other threads:[~2009-08-11 18:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-11 18:02 John Prevost [this message]
2009-08-12 12:58 ` bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Jason Rumney
2009-08-12 16:35 ` John Prevost
2009-08-13 3:22 ` Dan Nicolaescu
2009-08-13 4:47 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2009-09-18 23:09 Adrian Robert
2009-09-21 15:43 ` John Prevost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2zla6jkj6.fsf@TELPERION.WV.CC.CMU.EDU \
--to=prevost1@cert.org \
--cc=4128@emacsbugs.donarmstrong.com \
--cc=bug-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.