On Sat, 3 Jun 2006, Ed Greshko wrote:
Matthew Saltzman wrote:
On Fri, 2 Jun 2006, Les Mikesell wrote:
On Fri, 2006-06-02 at 18:27 -0400, David Cary Hart wrote:
I would be very happy if ctrls c, x and v would work the way they are
expected to work across the board.
I expect control-c to interrupt and kill an application as it has
for decades. Why would you want to change that?
CTRL-C in a terminal window kills the running program launched from that
window. CTRL-C doesn't (and never has in my recollection) kill the
window itself.
I'm fairly sure that is what Les meant. Application="running program".
But it's not what David Cary Hart was referring to. He's talking about a
text-editor window or other GUI app, not the terminal from which it was
launched. Launch any GUI from a terminal, then type CTRL-C in the
terminal window and the app is killed (unless it handles SIGKILL). Type
CTRL-C in the window you launched and it is handled in an app-specific
way, but doesn't kill the window.
That the functionality seems to
vary among applications (along with right-click, middle-click and
shift-insert) makes life a whole lot more complicated than it should
be. Sometimes, it is rather frustrating if you are moving text
around a great deal between applications and sometimes the command
line.
Still, no one has said what doesn't work with right-mouse/copy and
paste. I use those with synergy making a single keyboard/mouse
span several machines, both Linux and windows and there are few
exceptions to right-mouse copy/paste working the same even when
the clipboard gets dragged over to a different OS.
Having to reach for the mouse is a pain in the butt. Usually, keyboard
shortcuts are much more efficient (modulo the need to learn new ones for
every damned program--the fact that CTRl-W in the location field kills
the current Firefox window is annoying as all get-out, because in most
terminals it just backward-deletes a word).
^^^^^^^^^ shells
How would "backward-deletes a word" have any meaning in the context of
running Firefox?
When I want to replace the URL in the location bar or fill in text fields
in a form, I might very well want to backard-delete-word.
Speaking of context, Ctrl-C has had meaning in the context of a hardware
terminal that predates any windows based system. I was never big on DOS
as my experience was with terminals connected to mainframe systems.
However, I don't recall that DOS had a concept of Ctrl-C being a "copy"
operation. So, maybe we have to back determine who thought Ctrl-C was a
good idea to start out?
I don't know for sure who was "first" to use CTRL-C for copy, but it's
been common (though not universal) in GUI apps on Windows since its
inception--certainly MS GUI apps such as Word. CTRL-C in DOS also killed
the running program in text mode, but may not have done in full-screen
apps.
Emacs has handled CTRL-C even in text mode since its inception. That was
in the mid to late '70's. In Emacs, CTRL-C is one form of command prefix.
Killing Emacs from within its window requires CTRL-X CTRL-C.
Whoever imagines "Ctrl-C/Ctrl-V" is universally implemented in the MS
world apparently has used a limited number of applications in that
world. (I suppose that should be applauded.) One well known terminal
emulation program uses "Ctrl-Insert/Shift-Insert" for copy/paste
operations.
Personally, I'm not bothered by the fact that methods for cut/paste (and
other things) may vary between applications. I tend to adapt and think
in the context in which I am working. I can't think of any examples,
but the only thing that would truly be annoying would be if key strokes
took on different meaning within a given application depending on what
window of that application you had open. And, I get mildly annoyed if
the methods change between versions of an application. Yet, I do adapt.
I give the developers the benefit of the doubt...I'm sure the decision
to change it wasn't taken lightly.
Generally, I agree. But
(a) It would be helpful if common tasks did have common keystrokes across
apps--having to relearn new keystrokes to accomplish the exact same simple
tasks in each new program is not an efficient use of one's time. I've
been thinking of switching from pine to mutt for e-mail, but the mutt
keystroke command reference is seven (24-line) screens long!.
(b) It is not a good idea to have keystrokes that are used commonly with
small effects (backward-kill-word) didn't suddenly have catastrophic
effects (mercilessly-kill-window-without-comfirmation-dialogue) in some
apps;
(c) Often it seems as though the decisions about what keys to use for what
purposes (and many other UI design decisions) are made by the developers
with no attention paid to context, history, or relevant standards and
guidelines.
I will say one thing....it is not helpful when folks reply with "what
nightmare?". It doesn't help to minimize someone's pain. We've all
seen parents at the doctor's office trying to comfort their screaming
child by saying..."Oh, its a small needle...it doesn't hurt". Right,
the parent feels no pain at all.
Hear, hear!
I guess the question I would have asked at the start of this thread
would have been "What applications are you trying to cut and paste
between?" and then go about trying to solve that problem.
I suppose one could insist on rejecting the resolution because it isn't
the way they want it to be. But, that would simply be a
misunderstanding of the terms: "Works as expected" and "Works as Designed".
"Works as Designed" is not necessarily a compliment. Other relevant terms
include "Well Designed", "Consistent", "Principle of Least Surprise", etc.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
