From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: John Prevost , 4128@debbugs.gnu.org Resent-From: John Prevost Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 11 Aug 2009 18:10:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 4128 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12500137836278 (code B ref -1); Tue, 11 Aug 2009 18:10:06 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 11 Aug 2009 18:03:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.9 required=4.0 tests=AWL,FOURLA,FVGT_m_MULTI_ODD, MONEY,STOCKLIKE autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7BI3051006272 for ; Tue, 11 Aug 2009 11:03:02 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mavga-0006Wp-BI for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 14:03:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MavgV-0006UD-3W for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 14:02:59 -0400 Received: from [199.232.76.173] (port=37153 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MavgU-0006U9-V8 for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 14:02:54 -0400 Received: from telperion.wv.cc.cmu.edu ([128.237.240.133]:53577) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MavgU-0003Xw-GC for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 14:02:54 -0400 Received: by TELPERION.WV.CC.CMU.EDU (Postfix, from userid 501) id B5A374B4865; Tue, 11 Aug 2009 14:02:53 -0400 (EDT) From: John Prevost To: bug-gnu-emacs@gnu.org Date: Tue, 11 Aug 2009 14:02:53 -0400 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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: y C-x b C-c C-c n C-x C-g C-c C-c y s-x M-x r e p o r 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 From rgm@gnu.org Tue Aug 11 12:27:08 2009 Received: (at control) by emacsbugs.donarmstrong.com; 11 Aug 2009 19:27:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,ONEWORD autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7BJR7tg016020 for ; Tue, 11 Aug 2009 12:27:08 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mawzy-0002TF-IF; Tue, 11 Aug 2009 15:27:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19073.50698.463603.40432@fencepost.gnu.org> Date: Tue, 11 Aug 2009 15:27:06 -0400 From: Glenn Morris To: control Subject: control merge 4122 4125 reassign 4113 emacs,ns merge 4124 4127 reassign 4128 emacs,ns From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: Jason Rumney , 4128@debbugs.gnu.org Resent-From: Jason Rumney Original-Sender: Jason Rumney Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Wed, 12 Aug 2009 13:25:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.12500830445662 (code B ref 4128); Wed, 12 Aug 2009 13:25:07 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 13:17:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7CDHNYw005659 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 06:17:24 -0700 Received: by pzk36 with SMTP id 36so4423698pzk.13 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 06:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:message-id :date:from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6ovKCKYc8ECQwkr58zI5JL3ualWSTcLSjIlFbDd1ifk=; b=pOzmVplbWSvOz374T0HBzW+xIfF710y2WARd2sDUTXzPLDuPgMVVYTcRpHndC+rYhJ RUIJYRjjzQ7ahxP40mMeUS+SLaWwvLZc6QOL9ijSN8x5Rpao4xvKyczAf6UeCqfRHs85 TpCjwhcKtY4ByIneHP67vY0iNGdXy8W/Z3H4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=f8CHwJxN9RdybdqeNOI9RV//n/QviPVe7krzY3ftlbTird+PuskJEwsRIQ/rDSfGTb xc2dOm//vW3LZbfut4IHj/7p2FYcdgwHC4q5rCI5uBGF9i4X0Q6+9U3YyPI9zoQMmION FoyHzzXC6mzSSuVOVaPfk1G8lVBQ4Ecn7+tmw= Received: by 10.142.153.13 with SMTP id a13mr14024wfe.155.1250083037846; Wed, 12 Aug 2009 06:17:17 -0700 (PDT) Received: from wanchan.jasonrumney.net ([118.101.138.248]) by mx.google.com with ESMTPS id 22sm20168977wfd.8.2009.08.12.06.17.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 06:17:17 -0700 (PDT) Sender: Jason Rumney Received: from wanchan.jasonrumney.net (localhost [127.0.0.1]) by wanchan.jasonrumney.net (Postfix) with ESMTP id B242CB4B; Wed, 12 Aug 2009 20:58:18 +0800 (MYT) Message-ID: <4A82BC69.8050300@gnu.org> Date: Wed, 12 Aug 2009 20:58:17 +0800 From: Jason Rumney User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: John Prevost , 4128@debbugs.gnu.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: Reply-To: David Reitter , 4128@debbugs.gnu.org Resent-From: David Reitter Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Wed, 12 Aug 2009 14:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.125008697517151 (code B ref 4128); Wed, 12 Aug 2009 14:30:04 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 14:22:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=AWL,MISSING_SUBJECT,NOSUBJECT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7CEMrWk017141 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 07:22:55 -0700 Received: by qw-out-2122.google.com with SMTP id 9so15858qwb.13 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 07:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=Sw7gvSncdbM453VUaQCayJyg7KEHQymsLgMTbR7cte8=; b=jRvYUKOok3X0NcYfmYltr7h4rd7pojzU9t4YwYCj7IjcIPp225lpyHcdQbs06IDHz3 G6hqPz2qSjT1VFPSOq+mnkA362j6ZOCsYRAQXyf23tGH7dLVpw8idrjl7H7wHDR6MKGA GZRbFtyBrrIDYw39kZJsqgMZpujbii9AYnobg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=UJtIsJeTbLe0dU5L4DHb3JJXzYP/iowwDsaEpFzy5JMAsYzv7FCNLi48MFET+9XNSd 3BV84kyoEI4Ru9HJnCvAUXQZxNUJBjKVUB2jV/3Uf/EAlAZa/3c6InGmRtrvBdi145sT qeEahmwaSiEq0fOJl1vc20aKPXjRHqrGA97to= Received: by 10.224.85.80 with SMTP id n16mr124052qal.200.1250086973502; Wed, 12 Aug 2009 07:22:53 -0700 (PDT) Received: from scarlett.psy.cmu.edu (SCARLETT.PSY.CMU.EDU [128.2.249.106]) by mx.google.com with ESMTPS id 7sm5067436qwb.4.2009.08.12.07.22.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 07:22:51 -0700 (PDT) From: David Reitter Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 12 Aug 2009 10:22:50 -0400 Message-Id: <369B88AE-E03F-4934-85E7-B1A0AA408D9B@gmail.com> To: 4128@debbugs.gnu.org Mime-Version: 1.0 (Apple Message framework v1074) X-Mailer: Apple Mail (2.1074) > However, binding anything to a power-off command within Emacs sounds > like a bad idea. In the contrary, not reacting to the ns-power-off message would be a bad idea because it would stall and then cancel shutdown (and probably log out as well) on OS X. The app needs to react correctly to that, and that is to quit while asking the user whether to save unsaved buffers. There is no Super modifier on Macs, but perhaps it's not a good idea to use Super as a proxy for the Command key on pure Nextstep. I would generally be in favor for making GNU Emacs "pure", i.e. making it as compatible with GNU Emacs on other platforms, and leave the Mac- ification to distributions or contributed packages that can be enabled by the users. From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: Reply-To: Jason Rumney , 4128@debbugs.gnu.org Resent-From: Jason Rumney Original-Sender: Jason Rumney Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Wed, 12 Aug 2009 16:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.12500928961001 (code B ref 4128); Wed, 12 Aug 2009 16:10:04 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 16:01:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.9 required=4.0 tests=AWL,HAS_BUG_NUMBER,ONEWORD autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7CG1Zq5000996 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 09:01:36 -0700 Received: by pzk36 with SMTP id 36so79999pzk.13 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 09:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:message-id :date:from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mGDEVZEIaTw3nrlvqzCS6Bwi8WZVsgVu/Tll4ZvA4z0=; b=kh0s6a8X/sMQp787dFbYAnbt90MIryKqW2ZzJH5FpfiNK+/G5o5CVFtzQywTNYvwa7 qS/USS/oG3UEjj+EhvL6d70dBwcSfolekD6NhptG9xuEEG1Xam0wcg8Q5BDnh0MDZ2hv XYBjNiZ89HzH1bFVCvh4M9fjW8Uu0bkWXHI3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bF1Q8L6O2BMGdVtbitkDqhUuRe5F9JzKQVHW5623/Jz2ruc09QBYwS/nJMvzYyC3XH L8ZPdriFLC1TW3fMk2O48iCcOPfDVniVqVH/8zSQNzrVedxNQO58DyCPpXKGqaH79gld FXFHHdxlkgqeAVELlf65x7uTWXYWvpyBHh3oM= Received: by 10.115.65.39 with SMTP id s39mr172182wak.194.1250092888125; Wed, 12 Aug 2009 09:01:28 -0700 (PDT) Received: from wanchan.jasonrumney.net ([118.101.138.248]) by mx.google.com with ESMTPS id n6sm12939482wag.4.2009.08.12.09.01.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 09:01:27 -0700 (PDT) Sender: Jason Rumney Received: from wanchan.jasonrumney.net (localhost [127.0.0.1]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 34EFB745; Thu, 13 Aug 2009 00:01:23 +0800 (MYT) Message-ID: <4A82E752.6050502@gnu.org> Date: Thu, 13 Aug 2009 00:01:22 +0800 From: Jason Rumney User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: David Reitter , 4128@debbugs.gnu.org References: <369B88AE-E03F-4934-85E7-B1A0AA408D9B@gmail.com> In-Reply-To: <369B88AE-E03F-4934-85E7-B1A0AA408D9B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Reitter wrote: >> However, binding anything to a power-off command within Emacs sounds >> like a bad idea. > > In the contrary, not reacting to the ns-power-off message would be a > bad idea because it would stall and then cancel shutdown (and probably > log out as well) on OS X. The app needs to react correctly to that, > and that is to quit while asking the user whether to save unsaved > buffers. The impression I got from the bug report was that a command `ns-power-off' was being bound to a key in Emacs. But it sounds dangerous to make such an event a lisp level event and allow arbitrary user code to delay or prevent shutdown of the system. On Windows, the equivalent event auto-saves all buffers and exits, in a way that is not held up by an infinite lisp loop in user code. From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: John Prevost , 4128@debbugs.gnu.org Resent-From: John Prevost Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Wed, 12 Aug 2009 16:45:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.12500949587372 (code B ref 4128); Wed, 12 Aug 2009 16:45:04 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 16:35:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,FVGT_m_MULTI_ODD, HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from TELPERION.WV.CC.CMU.EDU (TELPERION.WV.CC.CMU.EDU [128.237.240.133]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7CGZukV007369 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 09:35:58 -0700 Received: by TELPERION.WV.CC.CMU.EDU (Postfix, from userid 501) id 47B1F4B82D2; Wed, 12 Aug 2009 12:35:56 -0400 (EDT) From: John Prevost To: Jason Rumney Cc: "4128\@debbugs.gnu.org" <4128@debbugs.gnu.org> References: <4A82BC69.8050300@gnu.org> Date: Wed, 12 Aug 2009 12:35:56 -0400 In-Reply-To: <4A82BC69.8050300@gnu.org> (Jason Rumney's message of "Wed, 12 Aug 2009 08:58:17 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.3 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jason Rumney 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. From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: Dan Nicolaescu , 4128@debbugs.gnu.org Resent-From: Dan Nicolaescu Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Thu, 13 Aug 2009 03:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.125013375513668 (code B ref 4128); Thu, 13 Aug 2009 03:30:03 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 13 Aug 2009 03:22:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.8 required=4.0 tests=AWL,FOURLA,FVGT_m_MULTI_ODD, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from sallyv2.ics.uci.edu (sallyv2.ics.uci.edu [128.195.1.120]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7D3MX8G013665 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 20:22:34 -0700 Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by sallyv2.ics.uci.edu (8.13.8+Sun/8.13.8) with ESMTP id n7D3MF6C010642; Wed, 12 Aug 2009 20:22:15 -0700 (PDT) Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id n7D3MEMx008772; Wed, 12 Aug 2009 20:22:14 -0700 (PDT) Date: Wed, 12 Aug 2009 20:22:14 -0700 (PDT) Message-Id: <200908130322.n7D3MEMx008772@godzilla.ics.uci.edu> From: Dan Nicolaescu To: John Prevost Cc: 4128@debbugs.gnu.org, Jason Rumney References: <4A82BC69.8050300@gnu.org> In-Reply-To: (John Prevost's message of "Wed, 12 Aug 2009 12:35:56 -0400") Lines: 112 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: n7D3MF6C010642 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.34, required 5, autolearn=disabled, ALL_TRUSTED -1.44, FM_MULTI_ODD2 1.10) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu John Prevost writes: > Jason Rumney 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. nsterm.m:ns_set_default_prefs > Please do let me know if I should submit all or part of this message as > separate bug reports. IMHO that would be a good idea. Even better, submit it together with patches that fix the problems that you found, that would make it much more likely to get things going. There are a lot of bugs filed for the NS port and very few people work on fixing them... From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: Eli Zaretskii , 4128@debbugs.gnu.org Resent-From: Eli Zaretskii Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org Resent-Date: Thu, 13 Aug 2009 04:55:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.125013884226998 (code B ref 4128); Thu, 13 Aug 2009 04:55:04 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 13 Aug 2009 04:47:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7D4lKZi026995 for <4128@emacsbugs.donarmstrong.com>; Wed, 12 Aug 2009 21:47:21 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MbSDf-0002FL-NV; Thu, 13 Aug 2009 00:47:19 -0400 From: Eli Zaretskii To: John Prevost , 4128@debbugs.gnu.org CC: jasonr@gnu.org In-reply-to: (message from John Prevost on Wed, 12 Aug 2009 12:35:56 -0400) References: <4A82BC69.8050300@gnu.org> Message-Id: Date: Thu, 13 Aug 2009 00:47:19 -0400 > From: John Prevost > Date: Wed, 12 Aug 2009 12:35:56 -0400 > Cc: "4128@emacsbugs.donarmstrong.com" <4128@emacsbugs.donarmstrong.com> > Reply-To: John Prevost , 4128@emacsbugs.donarmstrong.com > > Is it only the term/*-win.el files that are so pre-loaded? No, there are many more. See the file lisp/loadup.el for the full list of Lisp packages that are preloaded. > 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. It would be a maintenance nightmare, IMO, to document each file that is preloaded, because these things change over time. And I don't think it should matter, anyway. If there are specific problems with the fact that they are preloaded, they might be bugs or misfeatures that need to be fixed, rather than relying on documentation of what is preloaded and letting users figure out what that means. (I suspect that most users don't understand the subtleties of this, nor do I think they need to.) From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: Adrian Robert , 4128@debbugs.gnu.org Resent-From: Adrian Robert Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org 2Resent-Date: Fri, 18 Sep 2009 23:15:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.125331529923341 (code B ref 4128); Fri, 18 Sep 2009 23:15:05 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 18 Sep 2009 23:08:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.4 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8IN8Hhb023338 for <4128@emacsbugs.donarmstrong.com>; Fri, 18 Sep 2009 16:08:18 -0700 Received: by qw-out-2122.google.com with SMTP id 3so445827qwe.13 for <4128@emacsbugs.donarmstrong.com>; Fri, 18 Sep 2009 16:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-type :message-id:cc:content-transfer-encoding:from:subject:date:to :x-mailer; bh=lhGgUjwviJXXpF8nL8d/+NL/kfJNNS1aAH+oeRrfE2g=; b=VLfFvHjlIyYFJ4wFJdNGjO3+7GQYEr1MX/7G6jShlygb+WWjDK1KzLRoiGTj+wgySp SvIZ+muEQOR52M2YFXfbsynUi9UQLrp/ffNMHVKxE+pG1Xd0RbFa/iHrtESYB0C+3Gyg Jogt872pUd4Enp+wCURXIC/SKmv0tW+5hevgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; b=tIiKDwPCy1y4+T8HzR+3qL5bE277iiFrBD3//LNdDkOcBuL3dwu7uMkvGTerz6drYq FXZticwprKnX+21Is2UFlq0qYDf9VNR7BrLoCsT2a0rvlsQjDTc9vQ30d6ssLpEwSZKf RdpIAgz2/MT73xPC3fWa/LeuJKummnsAp9hUE= Received: by 10.224.96.207 with SMTP id i15mr1922021qan.179.1253315297002; Fri, 18 Sep 2009 16:08:17 -0700 (PDT) Received: from ?10.0.1.3? (dpc6745214221.direcpc.com [67.45.214.221]) by mx.google.com with ESMTPS id 6sm806146qwd.23.2009.09.18.16.08.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Sep 2009 16:08:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: John Prevost Content-Transfer-Encoding: 7bit From: Adrian Robert Date: Fri, 18 Sep 2009 19:09:43 -0400 To: 4128@debbugs.gnu.org X-Mailer: Apple Mail (2.753.1) Hello, Thanks for this report. > (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. Can you be more specific? Are you talking about Home/End = beginning/ end of line? Which other applications on a "popular modern nextstep- derived system" are doing this? I haven't found any, whereas browsers, Terminal, iWork at least go to beginning/end of document. But perhaps we should make this change anyway to accomodate those coming from a Windows background. > ;;; 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" While the name sounds odd, the primary behavior is to create/extend the selection, which is common with other apps. This IS different from putting up a font menu on other platforms, but this is a tough call since the font panel is accessible via the tools menu and Cmd-t already, and the shift-extend-selection behavior is one of the oldest / most basic / most common gestures in non-X11 environments. Regarding ns-power-off, there is some confusion about these bindings; they are strictly internally used for passing information between the C and lisp levels and don't relate to the power button on some keyboards, or to events passed by the OS itself. The daemon situation IS problematic. At least the aliases can be worked around by using the ns- equivalents. You can put code in .emacs conditional on windowing-system = 'ns or 'mac (or emacs- major-version 22/23) to use under multiple emacsen. From unknown Sun Aug 10 12:54:33 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order Reply-To: John Prevost , 4128@debbugs.gnu.org Resent-From: John Prevost Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs , owner@debbugs.gnu.org 2Resent-Date: Mon, 21 Sep 2009 15:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4128 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Received: via spool by 4128-submit@emacsbugs.donarmstrong.com id=B4128.12535478011486 (code B ref 4128); Mon, 21 Sep 2009 15:50:04 +0000 Received: (at 4128) by emacsbugs.donarmstrong.com; 21 Sep 2009 15:43:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=AWL,GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from TELPERION.WV.CC.CMU.EDU (TELPERION.WV.CC.CMU.EDU [128.237.239.129]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8LFhJbO001483 for <4128@emacsbugs.donarmstrong.com>; Mon, 21 Sep 2009 08:43:20 -0700 Received: by TELPERION.WV.CC.CMU.EDU (Postfix, from userid 501) id D7EB25570AE; Mon, 21 Sep 2009 11:43:18 -0400 (EDT) From: John Prevost To: Adrian Robert Cc: "4128\@debbugs.gnu.org" <4128@debbugs.gnu.org> References: Date: Mon, 21 Sep 2009 11:43:18 -0400 In-Reply-To: (Adrian Robert's message of "Fri, 18 Sep 2009 19:09:43 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian Robert writes: > I haven't found any, whereas browsers, Terminal, iWork at least go to > beginning/end of document. But perhaps we should make this change > anyway to accomodate those coming from a Windows background. You are correct--I must have tested against a Microsoft app I was running at the time, which is of course a questionable source for "how should things work on a Mac?" Everything else I've tried treats home/end consistently as beginning/end-of-file. The only question, then, would be "is it better to be consistent with other applications on this OS, or to to be consistent with Emacs on other OSs?" >> ;;; 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" > > While the name sounds odd, the primary behavior is to create/extend > the selection, which is common with other apps. This IS different > from putting up a font menu on other platforms, but this is a tough > call since the font panel is accessible via the tools menu and Cmd-t > already, and the shift-extend-selection behavior is one of the > oldest / most basic / most common gestures in non-X11 environments. Uh. That's not the behavior I was talking about. The behavior I'm concerned about is what happens when you shift-double-click with the above definition in force. That is very much *not* normal for any system I'm familiar with. And again, the question here is: Is it better to be consistent with other applications on the host OS, or to be consistent with Emacs on other OSs? At the very least, the choice of whether OS trumps Emacs tradition or Emacs tradition trumps OS should be consistent from OS to OS. Historically, the "normal" Emacs distribution on MacOS has always preferred to behave like Emacs on other systems, and the "change everything to make it more Mac-like and friendly" solution was Aquamacs (which is why everybody I know avoids it.) John. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 16 19:44:00 2011 Received: (at control) by debbugs.gnu.org; 17 Nov 2011 00:44:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RQq59-0002ou-Jm for submit@debbugs.gnu.org; Wed, 16 Nov 2011 19:44:00 -0500 Received: from fencepost.gnu.org ([140.186.70.10] ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RQq57-0002on-EC for control@debbugs.gnu.org; Wed, 16 Nov 2011 19:43:58 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RQq4L-0000ON-E3 for control@debbugs.gnu.org; Wed, 16 Nov 2011 19:43:09 -0500 Date: Wed, 16 Nov 2011 19:43:09 -0500 Message-Id: Subject: control message for bug 4128 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) retitle 4128 too many key-bindings in ns-win.el? severity 4128 minor From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 25 11:56:59 2017 Received: (at control) by debbugs.gnu.org; 25 Sep 2017 15:56:59 +0000 Received: from localhost ([127.0.0.1]:58689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dwVkh-0001m4-4I for submit@debbugs.gnu.org; Mon, 25 Sep 2017 11:56:59 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:43649) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dwVkf-0001lr-Fa for control@debbugs.gnu.org; Mon, 25 Sep 2017 11:56:57 -0400 Received: by mail-wm0-f49.google.com with SMTP id m72so11527546wmc.0 for ; Mon, 25 Sep 2017 08:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:message-id:to:from:subject; bh=wvk/+gfHdm8fUxOmgBeRKn1LPsvbyPVsmlM/4clsUTo=; b=JstriPNkhD2wH832SAuI6wf9j4pBqS/DoOQaP3fIILpWgkmAd3+oqIKimzE213+Brx 2Kvk8OIn1dhbRLuHiD7K1Hu0Sz4xaNTThpckn0foyVRrvX7MAgRI6zb4HiS7Bpn2NJZH 7N/stbqoJIJdU3Vj0pvl+DkCiy2yzSpR8VW/VsOIayXb82qN0lKIos8qqInMHAcmsU0A Kk/oqanpwnkzQmyUrollzGMt0yByNRlrQ2qTGtOmlG5jM5uML4SzIIr7grKkjJXjyPYV lqV38JeLScxyepLGATPyG5DAHLlnn9c3nIuvYdzgGDMCbEAcfe7VV+ERj3siZOYpzn0X xsLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:message-id:to:from:subject; bh=wvk/+gfHdm8fUxOmgBeRKn1LPsvbyPVsmlM/4clsUTo=; b=psQrFsQ4kIBNZNwl27UhpNJKvj1Ib4WFfUn8wEhjelAiVmk3u0ELaAO9sEZrWLQkOJ XrIhw5TNsar0UKQkNO2AjgFbofSEFZ+f3MVDgHzDLDyMazVUs8gugguC2kjSWZ4XahsI JFlsSXgoD6pt4MyH6EuW2EinGIA9lnL6pZifn7vPgKEVLfWQHAFTK9s5H7epASFikdCB CMmPxBnCFfnOZfTN0lhj3Z5WNVBKnCS1gV3o1yMK57gXMTg8cJ01z9Y/1vW/7Y3/Iwin relM9X44/SVDBuUTD36Q4WXUYydj0W1z4KsuDE7oyPnRCmQ30SUKvKoJsCfH9YBg3m/F ALKQ== X-Gm-Message-State: AHPjjUgUbK4I+J15mqCMkXHdaOcKGQ779gncU/7QIAUKxp6Dd7gVAtio 0NfFSAn+wFEpS0Xqx+63nCDIqf68g+o= X-Google-Smtp-Source: AOwi7QCKWG5hVyABodj6MM04ftXwaUOghj2WO5L0G+ak26AuGFnt4t5aC0uaIIW0q+v7/BouqlKHAw== X-Received: by 10.28.27.87 with SMTP id b84mr804264wmb.71.1506355011564; Mon, 25 Sep 2017 08:56:51 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-b188-2706-1206-0eea.holly.idiocy.org. [2001:8b0:3f8:8129:b188:2706:1206:eea]) by smtp.gmail.com with ESMTPSA id l15sm7156030wrl.47.2017.09.25.08.56.50 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Sep 2017 08:56:51 -0700 (PDT) Date: Mon, 25 Sep 2017 16:56:50 +0100 Message-Id: To: control@debbugs.gnu.org From: Alan Third Subject: control message for bug #4128 X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) tags 4128 notabug From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 02 14:53:11 2019 Received: (at control) by debbugs.gnu.org; 2 Aug 2019 18:53:11 +0000 Received: from localhost ([127.0.0.1]:57706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htcfv-0004gF-Bx for submit@debbugs.gnu.org; Fri, 02 Aug 2019 14:53:11 -0400 Received: from quimby.gnus.org ([80.91.231.51]:34128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htcft-0004g5-Gk for control@debbugs.gnu.org; Fri, 02 Aug 2019 14:53:09 -0400 Received: from 77.18.62.220.tmi.telenormobil.no ([77.18.62.220] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1htcfq-00050D-6s for control@debbugs.gnu.org; Fri, 02 Aug 2019 20:53:08 +0200 Date: Fri, 02 Aug 2019 20:53:05 +0200 Message-Id: <87lfwbo0vi.fsf@mouse.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #4128 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 4128 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 4128 quit