Cut, Copy, Paste Nightmare

Matthew Saltzman mjs at ces.clemson.edu
Sat Jun 3 10:43:49 UTC 2006


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




More information about the fedora-list mailing list