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

Previous Next

Full log

View this message in rfc822 format

From: John Prevost <prevost1 <at> cert.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: "4128\@debbugs.gnu.org" <4128 <at> debbugs.gnu.org>
Subject: bug#4128: 23.1; term/ns-win.el does "too much", assumes wrong run order
Date: Mon, 21 Sep 2009 11:43:18 -0400

Adrian Robert <adrian.b.robert <at> gmail.com> 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.

Previous Next

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