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. > >> >>>>> 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. > >> >> 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? > >> >> 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? :-) >> 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.... 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. Time to take a page from the Borg book and adapt and assimilate. -- Who's on first?
