GNU bug report logs - #4128
too many key-bindings in ns-win.el?

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: minor; Reported by: John Prevost <prevost1@HIDDEN>; Keywords: notabug; dated Tue, 11 Aug 2009 18:10:06 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.
Added tag(s) notabug. Request was from Alan Third <alan@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 4128-quiet <at> debbugs.gnu.org:


Received: (at 4128-quiet) by debbugs.gnu.org; 17 Nov 2011 00:51:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 16 19:51:04 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1RQqBz-0003k0-RU
	for submit <at> debbugs.gnu.org; Wed, 16 Nov 2011 19:51:04 -0500
Received: from fencepost.gnu.org ([140.186.70.10] ident=Debian-exim)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <rgm@HIDDEN>) id 1RQqBx-0003jc-4T
	for 4128-quiet <at> debbugs.gnu.org; Wed, 16 Nov 2011 19:51:01 -0500
Received: from rgm by fencepost.gnu.org with local (Exim 4.71)
	(envelope-from <rgm@HIDDEN>)
	id 1RQqBA-0000qH-45; Wed, 16 Nov 2011 19:50:12 -0500
From: Glenn Morris <rgm@HIDDEN>
To: 4128-quiet <at> debbugs.gnu.org
Subject: Re: bug#4128: 23.1;
	term/ns-win.el does "too much", assumes wrong run order
References: <F15E9E43-5A4F-4738-AF13-36BCC1DE5916@HIDDEN>
	<m2ljk82tih.fsf@HIDDEN>
X-Spook: Ft. Bragg radar nuclear Sundevil Saddam Hussein PET
X-Ran: Ge03)=|.?>kk,ljK4Br%\TItfN3GT#}Q_WIN|_f/g!v9\kin3}"aPEvd2Y/V0F`D[No[RX
X-Hue: white
X-Attribution: GM
Date: Wed, 16 Nov 2011 19:50:12 -0500
In-Reply-To: <m2ljk82tih.fsf@HIDDEN> (John Prevost's message
	of "Mon, 21 Sep 2009 11:43:18 -0400")
Message-ID: <yf62ij373v.fsf@HIDDEN>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -6.4 (------)
X-Debbugs-Envelope-To: 4128-quiet
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.4 (------)


1) was a misunderstanding (ns-win is preloaded)

3) has been removed (bug#10051)

Some or all of 2) still seems to apply, although ns-win now binds fewer
keys than it used to (?).




Severity set to 'minor' from 'normal' Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Changed bug title to 'too many key-bindings in ns-win.el?' from '23.1; term/ns-win.el does "too much", assumes wrong run order' Request was from Glenn Morris <rgm@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 21 Sep 2009 15:43:21 +0000
From prevost1@HIDDEN Mon Sep 21 08:43:21 2009
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@HIDDEN>; 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 <prevost1@HIDDEN>
To: Adrian Robert <adrian.b.robert@HIDDEN>
Cc: "4128\@debbugs.gnu.org" <4128 <at> debbugs.gnu.org>
Subject: Re: 23.1; term/ns-win.el does "too much", assumes wrong run order
References: <F15E9E43-5A4F-4738-AF13-36BCC1DE5916@HIDDEN>
Date: Mon, 21 Sep 2009 11:43:18 -0400
In-Reply-To: <F15E9E43-5A4F-4738-AF13-36BCC1DE5916@HIDDEN> (Adrian Robert's
	message of "Fri, 18 Sep 2009 19:09:43 -0400")
Message-ID: <m2ljk82tih.fsf@HIDDEN>
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 <adrian.b.robert@HIDDEN> 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.



Acknowledgement sent to John Prevost <prevost1@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 18 Sep 2009 23:08:19 +0000
From adrian.b.robert@HIDDEN Fri Sep 18 16:08:18 2009
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@HIDDEN>; Fri, 18 Sep 2009 16:08:18 -0700
Received: by qw-out-2122.google.com with SMTP id 3so445827qwe.13
        for <4128@HIDDEN>; 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: <F15E9E43-5A4F-4738-AF13-36BCC1DE5916@HIDDEN>
Cc: John Prevost <prevost1@HIDDEN>
Content-Transfer-Encoding: 7bit
From: Adrian Robert <adrian.b.robert@HIDDEN>
Subject: Re: 23.1; term/ns-win.el does "too much", assumes wrong run order
Date: Fri, 18 Sep 2009 19:09:43 -0400
To: 4128 <at> 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.




Acknowledgement sent to Adrian Robert <adrian.b.robert@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 13 Aug 2009 04:47:22 +0000
From eliz@HIDDEN Wed Aug 12 21:47:21 2009
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@HIDDEN>; Wed, 12 Aug 2009 21:47:21 -0700
Received: from eliz by fencepost.gnu.org with local (Exim 4.67)
	(envelope-from <eliz@HIDDEN>)
	id 1MbSDf-0002FL-NV; Thu, 13 Aug 2009 00:47:19 -0400
From: Eli Zaretskii <eliz@HIDDEN>
To: John Prevost <prevost1@HIDDEN>, 4128 <at> debbugs.gnu.org
CC: jasonr@HIDDEN
In-reply-to: <m2bpmlj8gj.fsf@HIDDEN> (message from John
	Prevost on Wed, 12 Aug 2009 12:35:56 -0400)
Subject: Re: bug#4128: 23.1;
	term/ns-win.el does "too much", assumes wrong run order
Reply-to: Eli Zaretskii <eliz@HIDDEN>
References: <m2zla6jkj6.fsf@HIDDEN> <4A82BC69.8050300@HIDDEN> <m2bpmlj8gj.fsf@HIDDEN>
Message-Id: <E1MbSDf-0002FL-NV@HIDDEN>
Date: Thu, 13 Aug 2009 00:47:19 -0400

> From: John Prevost <prevost1@HIDDEN>
> Date: Wed, 12 Aug 2009 12:35:56 -0400
> Cc: "4128@HIDDEN" <4128@HIDDEN>
> Reply-To: John Prevost <prevost1@HIDDEN>, 4128@HIDDEN
> 
> 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.)



Acknowledgement sent to Eli Zaretskii <eliz@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 13 Aug 2009 03:22:35 +0000
From dann@HIDDEN Wed Aug 12 20:22:34 2009
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@HIDDEN>; 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@HIDDEN>
From: Dan Nicolaescu <dann@HIDDEN>
To: John Prevost <prevost1@HIDDEN>
Cc: 4128 <at> debbugs.gnu.org, Jason Rumney <jasonr@HIDDEN>
Subject: Re: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order
References: <m2zla6jkj6.fsf@HIDDEN>
	<4A82BC69.8050300@HIDDEN> <m2bpmlj8gj.fsf@HIDDEN>
X-Debbugs-No-Ack: yes
In-Reply-To: <m2bpmlj8gj.fsf@HIDDEN> (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@HIDDEN

John Prevost <prevost1@HIDDEN> writes:

  > Jason Rumney <jasonr@HIDDEN> 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...



Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 16:35:58 +0000
From prevost1@HIDDEN Wed Aug 12 09:35:58 2009
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@HIDDEN>; 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 <prevost1@HIDDEN>
To: Jason Rumney <jasonr@HIDDEN>
Cc: "4128\@debbugs.gnu.org" <4128 <at> debbugs.gnu.org>
Subject: Re: bug#4128: 23.1;	term/ns-win.el does "too much", assumes wrong run order
References: <m2zla6jkj6.fsf@HIDDEN>
	<4A82BC69.8050300@HIDDEN>
Date: Wed, 12 Aug 2009 12:35:56 -0400
In-Reply-To: <4A82BC69.8050300@HIDDEN> (Jason Rumney's message of "Wed, 12
	Aug 2009 08:58:17 -0400")
Message-ID: <m2bpmlj8gj.fsf@HIDDEN>
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 <jasonr@HIDDEN> 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.



Acknowledgement sent to John Prevost <prevost1@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 16:01:36 +0000
From jasonrumney@HIDDEN Wed Aug 12 09:01:36 2009
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@HIDDEN>; Wed, 12 Aug 2009 09:01:36 -0700
Received: by pzk36 with SMTP id 36so79999pzk.13
        for <4128@HIDDEN>; 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 <jasonrumney@HIDDEN>
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@HIDDEN>
Date: Thu, 13 Aug 2009 00:01:22 +0800
From: Jason Rumney <jasonr@HIDDEN>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: David Reitter <david.reitter@HIDDEN>, 4128 <at> debbugs.gnu.org
Subject: Re: bug#4128:
References: <369B88AE-E03F-4934-85E7-B1A0AA408D9B@HIDDEN>
In-Reply-To: <369B88AE-E03F-4934-85E7-B1A0AA408D9B@HIDDEN>
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.



Acknowledgement sent to Jason Rumney <jasonr@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 14:22:55 +0000
From david.reitter@HIDDEN Wed Aug 12 07:22:55 2009
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@HIDDEN>; Wed, 12 Aug 2009 07:22:55 -0700
Received: by qw-out-2122.google.com with SMTP id 9so15858qwb.13
        for <4128@HIDDEN>; 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 <david.reitter@HIDDEN>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Subject: 
Date: Wed, 12 Aug 2009 10:22:50 -0400
Message-Id: <369B88AE-E03F-4934-85E7-B1A0AA408D9B@HIDDEN>
To: 4128 <at> 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.




Acknowledgement sent to David Reitter <david.reitter@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.

Message received at 4128@HIDDEN:


Received: (at 4128) by emacsbugs.donarmstrong.com; 12 Aug 2009 13:17:24 +0000
From jasonrumney@HIDDEN Wed Aug 12 06:17:24 2009
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@HIDDEN>; Wed, 12 Aug 2009 06:17:24 -0700
Received: by pzk36 with SMTP id 36so4423698pzk.13
        for <4128@HIDDEN>; 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 <jasonrumney@HIDDEN>
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@HIDDEN>
Date: Wed, 12 Aug 2009 20:58:17 +0800
From: Jason Rumney <jasonr@HIDDEN>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: John Prevost <prevost1@HIDDEN>, 4128 <at> debbugs.gnu.org
Subject: Re: bug#4128: 23.1;	term/ns-win.el does "too much", assumes wrong
 run order
References: <m2zla6jkj6.fsf@HIDDEN>
In-Reply-To: <m2zla6jkj6.fsf@HIDDEN>
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.





Acknowledgement sent to Jason Rumney <jasonr@HIDDEN>:
Extra info received and forwarded to list. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN. Full text available.
Information forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>, owner@HIDDEN:
bug#4128; Package emacs,ns. Full text available.
bug reassigned from package `emacs' to `emacs,ns'. Request was from Glenn Morris <rgm@HIDDEN> to control@HIDDEN. Full text available.

Message received at submit@HIDDEN:


Received: (at submit) by emacsbugs.donarmstrong.com; 11 Aug 2009 18:03:03 +0000
From prevost1@HIDDEN Tue Aug 11 11:03:02 2009
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 <submit@HIDDEN>; 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@HIDDEN; 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@HIDDEN; 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@HIDDEN; 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 <prevost1@HIDDEN>)
	id 1MavgU-0003Xw-GC
	for bug-gnu-emacs@HIDDEN; 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 <prevost1@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 23.1; term/ns-win.el does "too much", assumes wrong run order
Date: Tue, 11 Aug 2009 14:02:53 -0400
Message-ID: <m2zla6jkj6.fsf@HIDDEN>
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@HIDDEN 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




Acknowledgement sent to John Prevost <prevost1@HIDDEN>:
New bug report received and forwarded. Copy sent to Emacs Bugs <bug-gnu-emacs@HIDDEN>. Full text available.
Report forwarded to bug-submit-list@HIDDEN, Emacs Bugs <bug-gnu-emacs@HIDDEN>:
bug#4128; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Sep 2017 16:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.