Cut, Copy, Paste Nightmare

[Matthew Saltzman]

On Sat, 3 Jun 2006, Ed Greshko wrote:

> Matthew Saltzman wrote:
>> 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.
>
> Ahh...you took exception to what Les said and to which I was responding.
> But, never mind....it isn't important.

OK...

>
>>
>>>
>>>>>>  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.
>
> You probably wouldn't want it in the URL location bar.  I just tested
> Ctrl-W on a URL in a bash shell and it deletes the entire URL.

That's actually what I was using it for, because classic X select/paste 
doesn't give me a way to select the text to be replaced.

>
>>
>>>
>>> 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.
>
> Right, common...not universal.  Humm...emacs uses CTRL-X combined with
> other control characters to mean something.  Yet, Ctrl-X means "cut" in
> other contexts.  So, is emacs doing something "wrong" or can one deal
> with when running in the context of emacs?

Touche.

>>
>>>
>>> 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 guess you will have to point out the standard.  What RFC is it?  Or,
> is it an ISO document?  Or, whose guideline is it?  I get the feeling
> that Ctrl-C was picked by some US company because it would be easy to
> remember because C-opy.  Wonder if the German's would rather the
> "guideline" K-opie?  :-)

Didn't have a formal standard in mind related to this discussion.  (c) is 
more of a general complaint, but I have run into exactly this sort of 
thing before in my work.

>
>>> 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.
>
> Well Designed seems subjective to me....

I can't define it but I know it when I see it 8^)

>
> FWIW, as far as my experience is cut/copy/paste is doable within and
> between applications.  It is consistent within a given application.  It
> is not consistent between applications....but doeable.
>
> There is no way to achieve nirvana, if ones definition of nirvana is
> that all keystrokes will have the same precise meaning within all
> application developed by everyone.
>
> So, unless someone can get everyone to agree on the path to nirvana or,
> if the discussion/question becomes "how to copy data between application
> X and application Y this thread is useless.

Since when have you known that to stop anyone from joining in lustily?

>
> Time to take a page from the Borg book and adapt and assimilate.

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs