Maybe the problem is in KDE. Sometimes ctrl-c works; sometimes it does not. Sometimes highlight->right-click->copy works.
But the biggest problem is with paste. ctrl-v never works. Shift-insert works but I never know what it will paste. Similarly, the middle button of my mouse works but I never know what I will get and it is different from the results of shift-insert.
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
On Tue, 2006-05-30 at 13:56 -0400, David Cary Hart wrote:
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
Middle-mouse should paste what is currently highlighted (without needing an extra copy step), right-mouse/paste or the keyboard equivalent should paste whatever you last right-mouse/copied. Usually application menu edit/copy edit/paste are the same as the right-mouse versions but sometimes they go their own way.
On Tue, 30 May 2006 13:13:12 -0500, Les Mikesell lesmikesell@gmail.com opined:
On Tue, 2006-05-30 at 13:56 -0400, David Cary Hart wrote:
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
Middle-mouse should paste what is currently highlighted (without needing an extra copy step), right-mouse/paste or the keyboard equivalent should paste whatever you last right-mouse/copied. Usually application menu edit/copy edit/paste are the same as the right-mouse versions but sometimes they go their own way.
That's actually a huge help. I have been highlighting + ctrl-c and THAT is what creates the problem.
Thanks MUCH!
On Tue, 30 May 2006 13:56:44 -0400 David Cary Hart Fedora@TQMcube.com wrote:
Maybe the problem is in KDE. Sometimes ctrl-c works; sometimes it does not. Sometimes highlight->right-click->copy works.
But the biggest problem is with paste. ctrl-v never works. Shift-insert works but I never know what it will paste. Similarly, the middle button of my mouse works but I never know what I will get and it is different from the results of shift-insert.
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
David, I am using Gnome and I am not having any problems with those keyboard shortcuts.
Hope that helps.
I would try to login to Gnome and see if it works.
Will
On Tuesday 30 May 2006 10:56, David Cary Hart wrote:
Maybe the problem is in KDE. Sometimes ctrl-c works; sometimes it does not. Sometimes highlight->right-click->copy works.
But the biggest problem is with paste. ctrl-v never works. Shift-insert works but I never know what it will paste. Similarly, the middle button of my mouse works but I never know what I will get and it is different from the results of shift-insert.
Anything you highlight will be copied into the clipboard. Shift-insert will paste the last thing you selected from the clipboard. That means you have to look at the clipboard and select it. This works great for copying a URL from an email in kmail into Firefox in a different desktop.
The standard ctrl-c, ctrl-v and ctrl-x work fine within most KDE programs but not all; it also works fine in Abiword.
HTH, Tom
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
On Tue, 2006-05-30 at 13:56 -0400, David Cary Hart wrote:
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
Using Oracle and Netscape we had to use Abiword in-between to cut & paste at all. Copy from Netscape, paste to Abiword, copy from Abiword, paste to Oracle. What a royal pain. It was explained to me, but I have forgotten the reason. Linux will never make it to Joe Lunchbucket's computer until it becomes resolved, and this problem goes back a LONG way. It was 6 years ago when we were doing that procedure to copy, cut & paste. I feel your pain. :) Ric
On Wed, 2006-05-31 at 07:34, Rickey Moore wrote:
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
Using Oracle and Netscape we had to use Abiword in-between to cut & paste at all. Copy from Netscape, paste to Abiword, copy from Abiword, paste to Oracle. What a royal pain. It was explained to me, but I have forgotten the reason. Linux will never make it to Joe Lunchbucket's computer until it becomes resolved, and this problem goes back a LONG way. It was 6 years ago when we were doing that procedure to copy, cut & paste. I feel your pain. :) Ric
Things really have to go out of their way to break the basic X mechanism of highlight/middle-mouse to snarf and barf. Unfortunately, a few things do - and it isn't that great if you only have a 2-button mouse. The additional clipboard mechanisms added by desktop environments and applications aren't always compatible but you only have to use them in situations where you can't keep the source highlighted or you want to select an area on the target to be replaced by the paste operation without losing the copied section.
Once you get used to using the middle-mouse method, having to do an extra step to copy becomes really annoying.
On Wed, 2006-05-31 at 07:52 -0500, Les Mikesell wrote:
Things really have to go out of their way to break the basic X mechanism of highlight/middle-mouse to snarf and barf. Unfortunately, a few things do
Pan and Evolution are two things that come to mind.
On Wed, 2006-05-31 at 22:41 +0930, Tim wrote:
On Wed, 2006-05-31 at 07:52 -0500, Les Mikesell wrote:
Things really have to go out of their way to break the basic X mechanism of highlight/middle-mouse to snarf and barf. Unfortunately, a few things do
Pan and Evolution are two things that come to mind.
What doesn't work as expected in evolution?
Les Mikesell:
Things really have to go out of their way to break the basic X mechanism of highlight/middle-mouse to snarf and barf. Unfortunately, a few things do
Tim:
Pan and Evolution are two things that come to mind.
Les Mikesell:
What doesn't work as expected in evolution?
Frequently, when trying to middle-mouse paste something that you've highlighted, nothing gets pasted. Particularly when trying to work between two Evolution windows (e.g. an editor as well as the reader).
Pan just won't do it, at all.
From: "Rickey Moore" wayward4now@gmail.com
On Tue, 2006-05-30 at 13:56 -0400, David Cary Hart wrote:
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
Using Oracle and Netscape we had to use Abiword in-between to cut & paste at all. Copy from Netscape, paste to Abiword, copy from Abiword, paste to Oracle. What a royal pain. It was explained to me, but I have forgotten the reason. Linux will never make it to Joe Lunchbucket's computer until it becomes resolved, and this problem goes back a LONG way. It was 6 years ago when we were doing that procedure to copy, cut & paste. I feel your pain. :) Ric
Cut and paste in Linux is the single most frequent cause for me lapsing into extremely unladylike language. I've had to replace dozens of melted keyboards. And the melt ripples on the face of my monitor are annoying. It may be time to get a replacement. Cut and Paste in Linux stinks on hydrogen ice.
{^_^}
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
jdow wrote:
Cut and paste in Linux is the single most frequent cause for me lapsing into extremely unladylike language.
In some circles unladylike language is considered a plus. :)
I've had to replace dozens of melted keyboards. And the melt ripples on the face of my monitor are annoying. It may be time to get a replacement. Cut and Paste in Linux stinks on hydrogen ice.
Oddly enough, I've always found it to be a plus and when I get on a windows box it drives me nuts that I have to actually do something other than select the text to get it to the clipboard. I use X's highlight select for text all the time.
So it all depends on your usage patterns really. I avoid office apps like the plague on the theory that if I am using them, I'm doing office work. I'd much rather do the sysadmin voodoo so that other people have systems they can do actual work on. ;-)
- -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== You can't depend on the man who made the mess to clean it up. -- Richard Nixon, 1952
On Wed, 2006-05-31 at 13:57 -0400, Todd Zullinger wrote:
Oddly enough, I've always found it to be a plus and when I get on a windows box it drives me nuts that I have to actually do something other than select the text to get it to the clipboard. I use X's highlight select for text all the time.
I find the Linux way of doing it a right pain in the bum. Two typical scenarios:
First ----- Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Windows: Highlight the word to be replaced, and paste the new word over the top of it. I can do this multiple times, just with new pastes. I don't have to delete + copy + paste ad nauseum. And, no, sometimes doing a search and replace through an editor function isn't always doable. What I put in the copy buffer stays there until I want rid of it.
Second: Linux: I've highlighted some details from an e-mail that I want to put into the email configuration. I open up the configuration, and the first editable data in it is already highlighted by the application. It's now in the copy buffer, and I can't paste what *I* had previously copied. I can't go back to the other window and copy again, because operations with it are blocked. I can't even see the other window, because two other windows are on top of it, and only one of them can be moved. I have to close one window, move the middle one, re-open the one I want to edit.
This is a HELL of a lot of mucking around.
Tim wrote:
I find the Linux way of doing it a right pain in the bum.
There's no "linux way". X offers you the flexibility to use multiple clipboards, but doesn't force you to use any one, particularly not one that's a pain.
First
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Windows: Highlight the word to be replaced, and paste the new word over the top of it.
Yeah, you can do that in X, too. Use the clipboard (ctrl+c or "copy" menu item) instead of the primary selection. If you behave like you're using Windows, you'll get the results that you want.
Second: Linux: I've highlighted some details from an e-mail that I want to put into the email configuration. I open up the configuration, and the first editable data in it is already highlighted by the application. It's now in the copy buffer, and I can't paste what *I* had previously copied.
If that's true, it's a bug in the application. The primary selection is only supposed to be replaced if the user selects something. If you open a window and something is automatically highlighted, it does not also magically replace the primary selection.
Since I don't know of any application that does that, I'll note that if, in Firefox, you press "Ctrl+l", the location bar's contents are highlighted, but the primary selection is not replaced. If you try to paste the primary selection, you'll get whatever was selected before you pressed "Ctrl+l".
Even if the application that you're using *is* buggy, you should still be able to copy text to the clipboard (rather than the primary selection) before you open the configuration, and paste the text.
From: "Gordon Messmer" yinyang@eburg.com
Tim wrote:
I find the Linux way of doing it a right pain in the bum.
There's no "linux way".
Stop typing right there. You have it exactly.
X offers you the flexibility to use multiple clipboards, but doesn't force you to use any one, particularly not one that's a pain.
Now you went and spoiled your simple exposition with fantasy. That's a crying shame. Ah well.
First
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Windows: Highlight the word to be replaced, and paste the new word over the top of it.
Yeah, you can do that in X, too. Use the clipboard (ctrl+c or "copy" menu item) instead of the primary selection. If you behave like you're using Windows, you'll get the results that you want.
That works so little percentage of the time for me that it's worthless advice. Worse it seems to be utterly unpredictable when it will and will not work.
Second: Linux: I've highlighted some details from an e-mail that I want to put into the email configuration. I open up the configuration, and the first editable data in it is already highlighted by the application. It's now in the copy buffer, and I can't paste what *I* had previously copied.
If that's true, it's a bug in the application. The primary selection is only supposed to be replaced if the user selects something. If you open a window and something is automatically highlighted, it does not also magically replace the primary selection.
X-Windows is one huge bug. I prefer consoles for Linux.
{^_^}
On Thu, 2006-06-01 at 00:10, jdow wrote:
Yeah, you can do that in X, too. Use the clipboard (ctrl+c or "copy" menu item) instead of the primary selection. If you behave like you're using Windows, you'll get the results that you want.
That works so little percentage of the time for me that it's worthless advice. Worse it seems to be utterly unpredictable when it will and will not work.
Can you list a few things where the right-mouse/copy paste functions don't work predictably?
X-Windows is one huge bug. I prefer consoles for Linux.
Real consoles are painful. Xterms (gnome-terminals, etc.) give you everything you can do in a console plus more of them and cut/paste between them - even when some of the windows are remote machines.
On Wed, 2006-05-31 at 22:33, Tim wrote:
Oddly enough, I've always found it to be a plus and when I get on a windows box it drives me nuts that I have to actually do something other than select the text to get it to the clipboard. I use X's highlight select for text all the time.
I find the Linux way of doing it a right pain in the bum. Two typical scenarios:
First
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
You get your choice: highlight the source, middle-mouse to paste, then select and delete the previous (which is no harder than selecting ahead of the paste), or select and right-mouse/copy the source, select the target and right-mouse/paste to replace it. I tend to do the latter in places like a browser URL window or other cramped places where having 2 copies pushes one out of sight and the former in free-form areas where there is room to see what you are doing because it tends to be faster and you may just be doing an insert, not a replace.
Windows: Highlight the word to be replaced, and paste the new word over the top of it.
You forgot to mention the extra step necessary here. After you highlight the selection to copy you must do an extra step to copy it to the clipboard.
I can do this multiple times, just with new pastes. I don't have to delete + copy + paste ad nauseum. And, no, sometimes doing a search and replace through an editor function isn't always doable. What I put in the copy buffer stays there until I want rid of it.
No difference there if you used the right-mouse copy/paste method.
Second: Linux: I've highlighted some details from an e-mail that I want to put into the email configuration. I open up the configuration, and the first editable data in it is already highlighted by the application.
If you don't want to copy to the clipboard, do it the other way around. That is, open the thing that does the silly auto-select first, then go select the text you want.
It's now in the copy buffer, and I can't paste what *I* had previously copied. I can't go back to the other window and copy again, because operations with it are blocked.
Huh?
I can't even see the other window, because two other windows are on top of it, and only one of them can be moved. I have to close one window, move the middle one, re-open the one I want to edit.
I think you need a different application if it won't let you put whatever window you want on top. I've never understood why applications that run under a perfectly good windowing system try to manage multiple windows themselves and do it badly.
This is a HELL of a lot of mucking around.
Agreed, but it's not necessary.
On Thu, 2006-06-01 at 13:03 +0930, Tim wrote:
I find the Linux way of doing it a right pain in the bum. Two typical scenarios:
There isn't "a Linux way of doing it". There is an explicit copy/cut/paste mechanism using ^C, ^X and ^V, and there is the X11 "mouse select and paste" mechanism. Only the first one works in Windows, both work in Linux (at the same time). Yes, under X11 in Linux (both Gnome and KDE) you have two independent clipboards.
First
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Windows: Highlight the word to be replaced, and paste the new word over the top of it. I can do this multiple times, just with new pastes. I don't have to delete + copy + paste ad nauseum. And, no, sometimes doing a search and replace through an editor function isn't always doable. What I put in the copy buffer stays there until I want rid of it.
Guess what, it works exactly that way in Linux, too. Just tried it in gedit and ooo.
Second: Linux: I've highlighted some details from an e-mail that I want to put into the email configuration. I open up the configuration, and the first editable data in it is already highlighted by the application. It's now in the copy buffer, and I can't paste what *I* had previously copied. I can't go back to the other window and copy again, because operations with it are blocked. I can't even see the other window, because two other windows are on top of it, and only one of them can be moved. I have to close one window, move the middle one, re-open the one I want to edit.
This is a HELL of a lot of mucking around.
Just do it the ^C/^V way then. Works just like in Windows. It is amazing you parade your lack of skill and/or knowledge and try to palm it off as some sort of Linux shortcomings.
All the best Steffen.
On Thu, 2006-06-01 at 14:00 +1000, Steffen Kluge wrote:
Just do it the ^C/^V way then. Works just like in Windows. It is amazing you parade your lack of skill and/or knowledge and try to palm it off as some sort of Linux shortcomings.
Nice try with the insults, jackass, but CTRL + C or V doesn't work in *all* applications, neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click pasting work in *all* applications. You *have* to do combinations, some of which have really annoying effects.
On Thu, 2006-06-01 at 16:21 +0930, Tim wrote:
Nice try with the insults, jackass, but CTRL + C or V doesn't work in *all* applications,
That's right, and your point is? On the bash command line ^C does something quite different, and vi implements it paste buffers in another way again. Bloody xeyes doesn't even blink when I use ^C or ^V...
neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click pasting work in *all* applications.
It is obviously up to the application developers to decide which key bindings they want to support in which context. It is up to the desktop style guides to define what should work. The Gnome apps I'm using behave as expected, and support both clipboards. In some cases, alternative keyboard shortcuts must be used (like SHIFT-^C), e.g. in a terminal window running a shell - for obvious reasons.
There are a few broken apps, like gcalctool (the Gnome calculator). It supports ^C/^V/right-click just fine, but also does a ^V on middle-click. That's a bug, IMO.
You *have* to do combinations, some of which have really annoying effects.
What combinations? You use one or the other, even simultaneously, but not in combination (like gcalctool does). Keeping that in mind, copy&paste works very well on all my boxes, even across vmware, vnc or citrix sessions.
As for the insults, I suppose I overreacted a bit, and apologise for that. I just had to vent some frustration that's been building up for a while. I'm getting increasingly annoyed with a trend I'm seeing in this forum. Where are the times when people described their problems with adequate detail and asked for help? Nowadays, throwing tantrums and stomping feet seems more fashionable. This being a very friendly forum people get away with that. In other places (such as misc@openbsd) they would have been larted so badly that they wouldn't dare asking another question for 6 months...
"Cut, Copy, Paste Nightmare"? Give me a break!
Cheers Steffen.
On Thu, 2006-06-01 at 17:54 +1000, Steffen Kluge wrote:
On Thu, 2006-06-01 at 16:21 +0930, Tim wrote:
neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click
pasting
work in *all* applications.
It is obviously up to the application developers to decide which key bindings they want to support in which context. It is up to the desktop style guides to define what should work. The Gnome apps I'm using behave as expected, and support both clipboards. In some cases, alternative keyboard shortcuts must be used (like SHIFT-^C), e.g. in a terminal window running a shell - for obvious reasons.
Well, there you go. With better standards that are recognized and honored, a developer won't be in the position of power and authority to 'decide' which keybindings they use. It would be a standard, with no deviations.
You *have* to do combinations, some of which have really annoying effects.
What combinations? You use one or the other, even simultaneously, but not in combination (like gcalctool does). Keeping that in mind, copy&paste works very well on all my boxes, even across vmware, vnc or citrix sessions.
Obviously your experiece says one thing and Tim has experienced something different. This is allowed and considered 'normal' in the course of human events. :)
As for the insults, I suppose I overreacted a bit, and apologise for that. I just had to vent some frustration that's been building up for a while. I'm getting increasingly annoyed with a trend I'm seeing in this forum. Where are the times when people described their problems with adequate detail and asked for help?
"Failure of others to meet our expectations"
Nowadays, throwing tantrums and stomping feet seems more fashionable. This being a very friendly forum people get away with that. In other places (such as misc@openbsd) they would have been larted so badly that they wouldn't dare asking another question for 6 months...
Well, Gee! That would take care of the problem! <smirk> Lot's of aggression there, from a pack of (label removed) letter-bomb writers who wouldn't dare make the confrontation up close and personal. There's no 'getting away with' anything here, according to my perspectives. We have developers and we have users. All with varying degrees of savvy. Look at jdow's stats... you think one of those openbsd folks are going to tangle with her? Yet, she aired her complaint. Would you go as far as to say that she was throwing a tantrum and stomping feet? I'd bet you wouldn't. She's paid more dues than -anyone- on this list, and then some. Airing problems is considered "properly assertive" and "compromise' is the goal. So is "teamwork", which is hard as hell to arrive at when many coder-heads lack empathy and social skills. Linus calls ithe experience "herding cats".
"Cut, Copy, Paste Nightmare"? Give me a break!
And, as has been posted, it -is- a nightmare for some, including the likes of jdow, Tim, myself and others. As I posted previously, it was a nightmare in the hallowed halls of RedHat with the CRM system the entire operation depended on... for customer support, development, sales / marketing and administration. The entire Research Triangle Park group, here in North Carolina, was running a work-around, as I detailed, just to cut & paste between CRM and other applications, with all of the brainpower at their disposal. Please accept my perspective from my experience. I was there in 1999-2000 and that was a large problem then. Maybe Rahul will clarify if the problem is fixed in 2006. If not, then wouldn't it be a good thing for people to air their complaints just a little louder, to get heard? And, quite possibly, someone with the power and authority to set a standard into stone, for all applications, will set resolution to this problem into motion. That is a goal wished for by many user members of the linux community, and reasonable assertive goals are considered good, within a "polite society". The antithesis of this is naked aggression; no compromise, no teamwork, "my way or the highway", objectification, and a pile of other "elements of criminal behavior". From what I gathered from your post, the BSD crowd has "Offenders" that abuse others. I got something for them. <cackles> Ric
A: Because it's annoying to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
On Fri, 2006-06-02 at 11:53 -0400, Rickey Moore wrote:
It is obviously up to the application developers to decide which key bindings they want to support in which context. It is up to the desktop style guides to define what should work. The Gnome apps I'm using behave as expected, and support both clipboards. In some cases, alternative keyboard shortcuts must be used (like SHIFT-^C), e.g. in a terminal window running a shell - for obvious reasons.
Well, there you go. With better standards that are recognized and honored, a developer won't be in the position of power and authority to 'decide' which keybindings they use. It would be a standard, with no deviations.
What? What does a new standard mean to something you've already been using for the last 30 years? For me, it would mean that the new standard would be ignored.
"Cut, Copy, Paste Nightmare"? Give me a break!
And, as has been posted, it -is- a nightmare for some, including the likes of jdow, Tim, myself and others.
Yet, none of them have bothered to post where the right-mouse cut/paste menu choices fail to work as expected.
-- Les Mikesell lesmikesell@gmail.com
On Fri, 02 Jun 2006 14:02:20 -0500, Les Mikesell lesmikesell@gmail.com opined:
On Fri, 2006-06-02 at 11:53 -0400, Rickey Moore wrote:
It is obviously up to the application developers to decide which key bindings they want to support in which context. It is up to the desktop style guides to define what should work. The Gnome apps I'm using behave as expected, and support both clipboards. In some cases, alternative keyboard shortcuts must be used (like SHIFT-^C), e.g. in a terminal window running a shell - for obvious reasons.
Well, there you go. With better standards that are recognized and honored, a developer won't be in the position of power and authority to 'decide' which keybindings they use. It would be a standard, with no deviations.
What? What does a new standard mean to something you've already been using for the last 30 years? For me, it would mean that the new standard would be ignored.
"Cut, Copy, Paste Nightmare"? Give me a break!
And, as has been posted, it -is- a nightmare for some, including the likes of jdow, Tim, myself and others.
Yet, none of them have bothered to post where the right-mouse cut/paste menu choices fail to work as expected.
This issue is most troublesome because select is captured. Therefore, in some applications, you cannot select what you want to replace because the selected text-to-be replaced becomes the text-that-you-want-to-replace-it-with. -;) In some applications neither ctrl-c nor ctrl-v work at all.
I would be very happy if ctrls c, x and v would work the way they are expected to work across the board. 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.
On Fri, 2006-06-02 at 18:27 -0400, David Cary Hart wrote:
Yet, none of them have bothered to post where the right-mouse cut/paste menu choices fail to work as expected.
This issue is most troublesome because select is captured. Therefore, in some applications, you cannot select what you want to replace because the selected text-to-be replaced becomes the text-that-you-want-to-replace-it-with. -;)
Is that the already-fixed KDE bug? Where does a simple select replace what you right-mouse/copied?
In some applications neither ctrl-c nor ctrl-v work at all.
And right-mouse/copy?
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?
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.
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.
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).
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".
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).
How would "backward-deletes a word" have any meaning in the context of running Firefox?
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?
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.
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.
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".
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matt,
Matthew Saltzman wrote:
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!.
If it helps (and in case you haven't seen this already), there is a Pine.rc in the mutt package that sets up the keybindings in mutt to be similar to those of Pine 3.95. As I've never used pine more than a few minutes I couldn't tell you how close these are to the pine one's you are used to, but they might make it easier for you to try out mutt.
The Pine.rc is installed in /usr/share/doc/mutt-*/Pine.rc.
- -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== You have to be 100% behind someone, before you can stab them in the back.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I wrote:
Matt,
Matthew Saltzman wrote:
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!.
If it helps (and in case you haven't seen this already), there is a Pine.rc in the mutt package that sets up the keybindings in mutt to be similar to those of Pine 3.95. As I've never used pine more than a few minutes I couldn't tell you how close these are to the pine one's you are used to, but they might make it easier for you to try out mutt.
The Pine.rc is installed in /usr/share/doc/mutt-*/Pine.rc.
Oh, and perhaps I should have mentioned that the simplest way to use them is to add a line like this to ~/.muttrc:
source /usr/share/doc/mutt-1.4.2.1/Pine.rc
HTH,
- -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== I could never recommend the use of drugs or alcohol to anyone, but they've always worked for me. -- Hunter S. Thompson
On Sat, 3 Jun 2006, Todd Zullinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I wrote:
Matt,
Matthew Saltzman wrote:
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!.
If it helps (and in case you haven't seen this already), there is a Pine.rc in the mutt package that sets up the keybindings in mutt to be similar to those of Pine 3.95. As I've never used pine more than a few minutes I couldn't tell you how close these are to the pine one's you are used to, but they might make it easier for you to try out mutt.
The Pine.rc is installed in /usr/share/doc/mutt-*/Pine.rc.
Oh, and perhaps I should have mentioned that the simplest way to use them is to add a line like this to ~/.muttrc:
source /usr/share/doc/mutt-1.4.2.1/Pine.rc
HTH,
Interesting idea. I might try that, although it seems like a crutch. If I'm going to change, it seems like I ought to just dive in.
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matthew Saltzman wrote:
Interesting idea. I might try that, although it seems like a crutch. If I'm going to change, it seems like I ought to just dive in.
I never used pine so I can't make any great comparison, but I've been a happy mutt user for many years now. Should you decide to dive in (with or without using the pine keybindings), the mutt-users list is a very helpful place.
Cheers,
- -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Let them call me rebel and welcome, I feel no concern from it; but I should suffer the misery of devils, were I to make a whore of my soul.... --Thomas Paine
On 04Jun2006 19:26, Todd Zullinger tmz@pobox.com wrote: | Matthew Saltzman wrote: | I never used pine so I can't make any great comparison, but I've been | a happy mutt user for many years now. Should you decide to dive in | (with or without using the pine keybindings), the mutt-users list is a | very helpful place.
I'll second that. I've also been a happy mutt user for years and can confirm that the mutt-users list is a very helpful place.
On Mon, Jun 05, 2006 at 09:41:59AM +1000, Cameron Simpson wrote:
On 04Jun2006 19:26, Todd Zullinger tmz@pobox.com wrote: | Matthew Saltzman wrote: | I never used pine so I can't make any great comparison, but I've been | a happy mutt user for many years now. Should you decide to dive in | (with or without using the pine keybindings), the mutt-users list is a | very helpful place.
I'll second that. I've also been a happy mutt user for years and can confirm that the mutt-users list is a very helpful place.
There's also mutt-ng, which I am running (after many years of happy mutt use).
---Kayvan
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.
On Sat, 2006-06-03 at 20:46 +0800, Ed Greshko wrote:
Matthew Saltzman wrote:
On Sat, 3 Jun 2006, Ed Greshko wrote:
Matthew Saltzman wrote:
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.
---- I remember this on a Macintosh pre-dating Windows and any Microsoft acceptance of this.
It was the 'Apple' modifier and the bottom row, left to right... Z = Undo X = Cut C = Copy V = Paste
'twas always thus but Apple had some power to make it stick because of the single menu design and the Apple Uniform Interface Guidelines published very early on. Microsoft saw the wisdom of this and has implemented it across their applications. GUI applications tend to leverage this to provide for user familiarity.
Obviously an application such as emacs which has roots which never anticipated a GUI interface doesn't conform to this familiarity.
Craig
On Sat, 2006-06-03 at 08:11, Craig White wrote:
I remember this on a Macintosh pre-dating Windows and any Microsoft acceptance of this.
It was the 'Apple' modifier and the bottom row, left to right... Z = Undo X = Cut C = Copy V = Paste
'twas always thus but Apple had some power to make it stick because of the single menu design and the Apple Uniform Interface Guidelines published very early on. Microsoft saw the wisdom of this and has implemented it across their applications. GUI applications tend to leverage this to provide for user familiarity.
Obviously an application such as emacs which has roots which never anticipated a GUI interface doesn't conform to this familiarity.
Don't forget that apple also had the power to supply a keyboard with the same key set with its machines. Back in the day when our most useful programs were written (pre-dating the IBM PC by many years), terminals were connected by serial lines, had no alt key, few or no function keys, and had no standard for what the arrow keys sent if they had any. That's why the control keys are so overloaded and why vi has modes to use normal keys for commands. There are many side effects to this ancient history, including the fact that you can have canned complex vi edit command sequences stored in a text file so you can simply paste them into an open edit window using the standard paste mechanism where doing the same with GUI editor usually means learning yet another different macro language and yet another way to save and invoke them.
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.
On Sat, 2006-06-03 at 05:43, Matthew Saltzman wrote:
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.
Emacs is it's own world. I don't think it is reasonable to compare its command set to anything else.
(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.
Except that many of the decisions predate the history and context you expect them to follow. Most of what we expect these days is at least slightly related to IBM's CDE work and motif circa 1989 but motif's licensing kept it from being used in the early open source work. I don't think MS Windows follows it strictly either.
On Sat, 3 Jun 2006, Les Mikesell wrote:
On Sat, 2006-06-03 at 05:43, Matthew Saltzman wrote:
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.
Emacs is it's own world. I don't think it is reasonable to compare its command set to anything else.
Fair enough. Try CTRL-C in a Firefox window and see that nothing happens. If you want to kill Firefox started from a terminal window, CTRL-C in the terminal window is needed (or you can apply the usual exit methods--click on the window bar, use the menu, or use a keyboard shortcut). To kill Firefox started from the menu, there is nothing you can do with CTRL-C. An unresponsive Firefox must be killed with xkill or the GNOME app-killer.
(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.
Except that many of the decisions predate the history and context you expect them to follow. Most of what we expect these days is at least slightly related to IBM's CDE work and motif circa 1989 but motif's licensing kept it from being used in the early open source work. I don't think MS Windows follows it strictly either.
Also a fair point, but the problems crop up often enough with new software as well. I commend the GNOME folks for trying to standardize the behavior of GNOME apps, though I occasionally think they carry the idea too far. (It seems they can't win, though. If they push standards too hard, folks bitch about lack of flexibility. If they don't push hard enough, we get threads like this one. It's a delicate balance, and we will know they've achieved it when nobody is entirely happy.)
On Sat, 2006-06-03 at 15:54, Matthew Saltzman wrote:
I commend the GNOME folks for trying to standardize the behavior of GNOME apps, though I occasionally think they carry the idea too far. (It seems they can't win, though. If they push standards too hard, folks bitch about lack of flexibility. If they don't push hard enough, we get threads like this one. It's a delicate balance, and we will know they've achieved it when nobody is entirely happy.)
Isn't that the whole point of having standards committees?
On Sat, 2006-06-03 at 17:04 -0500, Les Mikesell wrote:
On Sat, 2006-06-03 at 15:54, Matthew Saltzman wrote:
I commend the GNOME folks for trying to standardize the behavior of GNOME apps, though I occasionally think they carry the idea too far. (It seems they can't win, though. If they push standards too hard, folks bitch about lack of flexibility. If they don't push hard enough, we get threads like this one. It's a delicate balance, and we will know they've achieved it when nobody is entirely happy.)
Isn't that the whole point of having standards committees?
---- or marriage?
;-)
Craig
I have been fighting with this cut, copy and paste problem for ages as well. One example where it hasnt worked for me is if I cut and paste between.
Openoffice spreadsheet -> VNC (Windows Machine)
it does work if I do
Openoffice spreadsheet - gedit (gnome text editor) -> vnc.
Reading this thread I started looking around again and found this nifty program, thank goodness it works! Maybe it will work for you.
http://www.lepton.fr/tools/autocutsel/
Cheers,
Roy.
On Sat, 2006-06-03 at 15:11 -0700, Craig White wrote:
On Sat, 2006-06-03 at 17:04 -0500, Les Mikesell wrote:
On Sat, 2006-06-03 at 15:54, Matthew Saltzman wrote:
I commend the GNOME folks for trying to standardize the behavior of GNOME apps, though I occasionally think they carry the idea too far. (It seems they can't win, though. If they push standards too hard, folks bitch about lack of flexibility. If they don't push hard enough, we get threads like this one. It's a delicate balance, and we will know they've achieved it when nobody is entirely happy.)
Isn't that the whole point of having standards committees?
or marriage?
;-)
Craig
On Thu, 2006-06-01 at 16:21 +0930, Tim wrote:
On Thu, 2006-06-01 at 14:00 +1000, Steffen Kluge wrote:
Just do it the ^C/^V way then. Works just like in Windows. It is amazing you parade your lack of skill and/or knowledge and try to palm it off as some sort of Linux shortcomings.
Nice try with the insults, jackass, but CTRL + C or V doesn't work in *all* applications, neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click pasting work in *all* applications. You *have* to do combinations, some of which have really annoying effects.
-- (Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
Hi All
Through out this thread I have not read any SPECIFICS, which applications don't work? which window manager are you using? which application won't let you switch windows?
It seems to me that there is a lot of calling of the "system" without the detail to back it up, is it the "system" or a few buggy/misbehaving applications?
If the applications don't work the way you think they should, have you:- a) checked that you are allowed to do what you want, some applications won't let you copy data for security reasons, putting data in pictures on web pages for instance. b) reported the bug/feature to the application developers/supporters. c) checked your configuration to make sure you don't have something that is inhibiting the action. d) checked that something you have done has stopped it working. One of my programs has to use CTRL + C to close files cos thats what the user wanted. Another user had used CTRL + v to trigger their own macro (in Excel!). e) have you documented the precis actions that work/don't work so we can look at the problem
Thank you for your time
Laurence
p.s. and we are not kids, so PLEASE lets not get into name calling and play nice!
From: "Laurence Orchard" laurence@orchards.org.uk
On Thu, 2006-06-01 at 16:21 +0930, Tim wrote:
On Thu, 2006-06-01 at 14:00 +1000, Steffen Kluge wrote:
Just do it the ^C/^V way then. Works just like in Windows. It is amazing you parade your lack of skill and/or knowledge and try to palm it off as some sort of Linux shortcomings.
Nice try with the insults, jackass, but CTRL + C or V doesn't work in *all* applications, neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click pasting work in *all* applications. You *have* to do combinations, some of which have really annoying effects.
-- (Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
Hi All
Through out this thread I have not read any SPECIFICS, which applications don't work? which window manager are you using? which application won't let you switch windows?
It seems to me that there is a lot of calling of the "system" without the detail to back it up, is it the "system" or a few buggy/misbehaving applications?
If the applications don't work the way you think they should, have you:- a) checked that you are allowed to do what you want, some applications won't let you copy data for security reasons, putting data in pictures on web pages for instance. b) reported the bug/feature to the application developers/supporters. c) checked your configuration to make sure you don't have something that is inhibiting the action. d) checked that something you have done has stopped it working. One of my programs has to use CTRL + C to close files cos thats what the user wanted. Another user had used CTRL + v to trigger their own macro (in Excel!). e) have you documented the precis actions that work/don't work so we can look at the problem
Thank you for your time
1) When these problems bite I do NOT have time to debug them, create a fix, or even send a message to bugfart that there is a problem. I have my OWN problem to fix. 2) The problem with the program and X-Windows should not exist in the first place.
Laurence
p.s. and we are not kids, so PLEASE lets not get into name calling and play nice!
3) This is a Fedora Core mailinglist. What's this play nice and no name calling nonsense? (Of course, for an average "ix-ish" mailing list this one is modestly polite.)
{^_^} Joanne
On Thu, 2006-06-01 at 02:18 -0700, jdow wrote:
From: "Laurence Orchard" laurence@orchards.org.uk
On Thu, 2006-06-01 at 16:21 +0930, Tim wrote:
On Thu, 2006-06-01 at 14:00 +1000, Steffen Kluge wrote:
Just do it the ^C/^V way then. Works just like in Windows. It is amazing you parade your lack of skill and/or knowledge and try to palm it off as some sort of Linux shortcomings.
Nice try with the insults, jackass, but CTRL + C or V doesn't work in *all* applications, neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click pasting work in *all* applications. You *have* to do combinations, some of which have really annoying effects.
-- (Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
Hi All
Through out this thread I have not read any SPECIFICS, which applications don't work? which window manager are you using? which application won't let you switch windows?
It seems to me that there is a lot of calling of the "system" without the detail to back it up, is it the "system" or a few buggy/misbehaving applications?
If the applications don't work the way you think they should, have you:- a) checked that you are allowed to do what you want, some applications won't let you copy data for security reasons, putting data in pictures on web pages for instance. b) reported the bug/feature to the application developers/supporters. c) checked your configuration to make sure you don't have something that is inhibiting the action. d) checked that something you have done has stopped it working. One of my programs has to use CTRL + C to close files cos thats what the user wanted. Another user had used CTRL + v to trigger their own macro (in Excel!). e) have you documented the precis actions that work/don't work so we can look at the problem
Thank you for your time
- When these problems bite I do NOT have time to debug them, create a fix, or even send a message to bugfart that there is a problem. I have my OWN problem to fix.
Can I ask what you do when Windows crashes or one of Microsoft's applications doesn't work the way you think it should?
- The problem with the program and X-Windows should not exist in the first place.
I agree that problems shouldn't exist, but as far as I know only Buddha has reached Nirvana.
I think you will find more problems elsewhere, with fewer people willing to listen, do something about it or suggest an alternative.
Laurence
p.s. and we are not kids, so PLEASE lets not get into name calling and play nice!
- This is a Fedora Core mailinglist. What's this play nice and no name calling nonsense? (Of course, for an average "ix-ish" mailing list this one is modestly polite.)
End of the day, no-one is saying you have to use Fedora, if you prefer other offerings, go use them, stop whining, be constructive.
{^_^} Joanne
From: "Laurence Orchard" laurence@orchards.org.uk
On Thu, 2006-06-01 at 02:18 -0700, jdow wrote:
From: "Laurence Orchard" laurence@orchards.org.uk
On Thu, 2006-06-01 at 16:21 +0930, Tim wrote:
On Thu, 2006-06-01 at 14:00 +1000, Steffen Kluge wrote:
Just do it the ^C/^V way then. Works just like in Windows. It is amazing you parade your lack of skill and/or knowledge and try to palm it off as some sort of Linux shortcomings.
Nice try with the insults, jackass, but CTRL + C or V doesn't work in *all* applications, neither *do* all applications have right-click copy and paste options, and neither does highlight and middle-click pasting work in *all* applications. You *have* to do combinations, some of which have really annoying effects.
-- (Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
Hi All
Through out this thread I have not read any SPECIFICS, which applications don't work? which window manager are you using? which application won't let you switch windows?
It seems to me that there is a lot of calling of the "system" without the detail to back it up, is it the "system" or a few buggy/misbehaving applications?
If the applications don't work the way you think they should, have you:- a) checked that you are allowed to do what you want, some applications won't let you copy data for security reasons, putting data in pictures on web pages for instance. b) reported the bug/feature to the application developers/supporters. c) checked your configuration to make sure you don't have something that is inhibiting the action. d) checked that something you have done has stopped it working. One of my programs has to use CTRL + C to close files cos thats what the user wanted. Another user had used CTRL + v to trigger their own macro (in Excel!). e) have you documented the precis actions that work/don't work so we can look at the problem
Thank you for your time
- When these problems bite I do NOT have time to debug them, create a fix, or even send a message to bugfart that there is a problem. I have my OWN problem to fix.
Can I ask what you do when Windows crashes or one of Microsoft's applications doesn't work the way you think it should?
Windows crashes? Could fool me. Do you still run that pseudo-windows called SE?
- The problem with the program and X-Windows should not exist in the first place.
I agree that problems shouldn't exist, but as far as I know only Buddha has reached Nirvana.
I think you will find more problems elsewhere, with fewer people willing to listen, do something about it or suggest an alternative.
Laurence
p.s. and we are not kids, so PLEASE lets not get into name calling and play nice!
- This is a Fedora Core mailinglist. What's this play nice and no name calling nonsense? (Of course, for an average "ix-ish" mailing list this one is modestly polite.)
End of the day, no-one is saying you have to use Fedora, if you prefer other offerings, go use them, stop whining, be constructive.
That was humor, although I expect the humor impaired not to notice.
{^_-} (I will note that the old Amigas had nicer cut and paste and clipboard behavior than I find in X applications.)
On 6/1/06, jdow jdow@earthlink.net wrote:
- When these problems bite I do NOT have time to debug them, create a fix, or even send a message to bugfart that there is a problem. I have my OWN problem to fix.
We can't help much with YOUR problems, which is all you've seemed to mention so far.
- The problem with the program and X-Windows should not exist in the first place.
Perhaps you are running character based apps inside xterm windows. I do that so much that I take the quirks for granted but I can see how it would be confusing if you don't realize that the terninal window provides cut/paste, but the app knows nothing about it and the paste operation gets pushed through the keyboard input. That is, before you paste you have to get the app cursor positioned appropriately and in a mode to accept the input.
The only other quirk I ever see is that once in a while the primary selection disappears when bringing the target window to the front but I think it is from double-clicking or some other mouse action that I've done accidentally. It never happens with the right-mouse/copy method.
Other than that, if there is a bug it isn't going to get fixed unless someone reports the specific details.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim wrote:
I find the Linux way of doing it a right pain in the bum. Two typical scenarios:
We have different usage patterns, and I can see how the copy/paste behavior would rightfully drive you batty. I'll secretly hope that any fix for your use patterns don't break mine. :)
First
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
For me, this would be done in vim with a search and replace.
:%s/old/new/g
Done. All occurrences of old word are replaced with new word. And I can use a regex on the match and parts of the match for the replacement.
I'd use perl to do this to multiple documents at a time like so:
$ perl -pi -e 's/old/new/g' /path/to/docs/*
And I could replace /path/to/docs/ with something like:
$(grep -rl 'old' /path)
which will search recursively for all files containing the old word and feed them to perl to be replaced.
Second: Linux: I've highlighted some details from an e-mail that I want to put into the email configuration. I open up the configuration, and the first editable data in it is already highlighted by the application. It's now in the copy buffer, and I can't paste what *I* had previously copied.
Yeah, I've had this one happen to me occasionally. When dealing with things like that I do a real copy (ctrl-c) instead of just selecting the text. That way the new text that's selected won't wipe out what I want to past over it. In this case, I'm still no worse off than I'd have been if I used windows, as far as I'm concerned.
I also don't ever have this issue with email, since I can edit my mutt config with good old vim. :-)
There is no doubt room for improvement, mostly in making things consistent and fixing badly designed user interfaces. Hopefully folks that run into those problems will file bugs at the right places and get those things fixed.
But I do understand where you're coming from Tim. It took me some getting used to after leaving windows, but now when I get stuck in front of a windows box I'm cursing like jdow at the copy/paste behavior because I always forget that I have to do more than just select the text.
- -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== I believe in the noble, aristocratic art of doing absolutely nothing. And someday, I hope to be in a position where I can do even less.
Tim:
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Todd Zullinger:
For me, this would be done in vim with a search and replace.
:%s/old/new/g
Sometimes you don't want to replace every instance, that's where copy and paste would (otherwise) be more useful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim wrote:
Tim:
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Todd Zullinger:
For me, this would be done in vim with a search and replace.
:%s/old/new/gSometimes you don't want to replace every instance, that's where copy and paste would (otherwise) be more useful.
Nah, that's where a range would be useful. ;-)
Just replace old with new between lines 35 and 40:
:35,40 s/old/new/g
Or you can just replace the current line by leaving off the % (for all lines) or the 35,40. Then hit n to get to the next occurrence of old, and if it's one you want to skip, hit n again. It's pretty fast for me to do this sort of thing. And as I said, you can use regex's in there as well, which is something I simply couldn't give up.
You can even select a block of text and then apply the replacements to just that block. I learned a good many tricks like this by using gvim and watching what commands it ran when I used the graphical search and replace. That was enough to make me think learning more about it was worth my time. And for me, it's proved invaluable.
But I also do my best to not use formats like .doc or .odt. For those, a nice search and replace in the interface is very nice. Does copy/paste not work properly using ctrl-c/ctrl-v on linux just as it would on windows?
It seems (from what others have said in this thread) like it is supposed to work better than it often does in practice, but that it's a bug in the applications when it doesn't, rather than a flaw in the way X works. I don't test this all that often so I can't speak to what apps work well and which don't in this respect.
I'm not trying to argue that the way I do things is the only right way to do them. Hopefully it doesn't come out that way. ;-)
- -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke
On Thu, 2006-06-01 at 16:19 +0930, Tim wrote:
Tim:
Linux: I have some document with a word I'd like to replace. I *have* to delete the word, find and highlight its new replacement, paste it into the document.
Todd Zullinger:
For me, this would be done in vim with a search and replace.
:%s/old/new/gSometimes you don't want to replace every instance, that's where copy and paste would (otherwise) be more useful.
Errr... %s/old/new/gc ^confirm Or for a more interactive feel: /old<enter> <-position to 1st instance cw <-change word new<escape> <-type the replacement n <-move to next instance of 'old' . <-repeat last command n.n.n. (etc., just skip the . if you don't want to replace)
Basically any command can be repeated with the '.' and it even spans multiple files if you put them all on the vi command line and move through them with :n.
Visual cut/paste is most useful in very short items where you can easily see the relevant section. If any parts are out of sight or take significant navigation to reach, commands that act directly are much faster.
Rickey Moore wrote:
On Tue, 2006-05-30 at 13:56 -0400, David Cary Hart wrote:
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Using Oracle and Netscape we had to use Abiword in-between to cut & paste at all. Copy from Netscape, paste to Abiword, copy from Abiword, paste to Oracle. What a royal pain. It was explained to me, but I have forgotten the reason. Linux will never make it to Joe Lunchbucket's computer until it becomes resolved, and this problem goes back a LONG way. It was 6 years ago when we were doing that procedure to copy, cut & paste. I feel your pain. :) Ric
The problem was mostly solved years ago. The biggest amount of confusion came from the fact that KDE 2 used the wrong X selection for copy/paste, and therefore didn't interoperate with anything non-KDE.
And here's a statement that you probably never thought you'd see: The best explanation of this that I've seen was a slashdot comment. http://ask.slashdot.org/comments.pl?sid=109755&cid=9319130
So, basically, there are two clipboards in X. If you select text with the mouse, you can paste it with the middle button. If you use the "copy" menu item (or ctrl+c), you can paste it with the "paste" menu item (or ctrl+v). As long as you don't try to mix the two, like expecting "paste" to insert something that you selected with the mouse, you should be fine.
Ctrl+Ins and Shift+Ins aren't real consistent, though. Terminal applications tend to insert the contents of the primary selection on Shift+Ins, where other applications will insert the contents of the clipboard selection.
From the original post, it's not clear where he's trying to copy from or too. Clarification on that may help us explain why a particular application isn't behaving the way you'd expect. However, there's nothing wrong or broken about X or its copy mechanisms.
On Wed, 2006-05-31 at 11:54 -0700, Gordon Messmer wrote:
And here's a statement that you probably never thought you'd see: The best explanation of this that I've seen was a slashdot comment. http://ask.slashdot.org/comments.pl?sid=109755&cid=9319130
So, basically, there are two clipboards in X. If you select text with the mouse, you can paste it with the middle button. If you use the "copy" menu item (or ctrl+c), you can paste it with the "paste" menu item (or ctrl+v). As long as you don't try to mix the two, like expecting "paste" to insert something that you selected with the mouse, you should be fine.
That's a little confusing. Almost everywhere the keyboard versions of copy/paste work there is also a right-mouse menu that works the same way as the keyboard, so the distinction isn't between using the mouse and the keyboard, it is between using the clipboard or the selection. That is, anything selected will paste with the middle mouse (and I disagree with the slashdot article calling this the 'advanced' way - it is the basic X way), and things copied to the clipboard with either the right-mouse menu copy or the keyboard equivalent will paste with either the right-mouse menu or the keyboard equivalent. Since many applications need the keystrokes for something else, you'll have a lot fewer surprises if you use the right-mouse method most places. Also, if you use 'synergy' to let a single keyboard/mouse access multiple computers running different OS's, the right-mouse action usually work no matter where you are.
On Wed, 31 May 2006 14:36:55 -0500, Les Mikesell lesmikesell@gmail.com opined:
On Wed, 2006-05-31 at 11:54 -0700, Gordon Messmer wrote:
And here's a statement that you probably never thought you'd see: The best explanation of this that I've seen was a slashdot comment. http://ask.slashdot.org/comments.pl?sid=109755&cid=9319130
So, basically, there are two clipboards in X. If you select text with the mouse, you can paste it with the middle button. If you use the "copy" menu item (or ctrl+c), you can paste it with the "paste" menu item (or ctrl+v). As long as you don't try to mix the two, like expecting "paste" to insert something that you selected with the mouse, you should be fine.
That's a little confusing. Almost everywhere the keyboard versions of copy/paste work there is also a right-mouse menu that works the same way as the keyboard, so the distinction isn't between using the mouse and the keyboard, it is between using the clipboard or the selection. That is, anything selected will paste with the middle mouse (and I disagree with the slashdot article calling this the 'advanced' way - it is the basic X way), and things copied to the clipboard with either the right-mouse menu copy or the keyboard equivalent will paste with either the right-mouse menu or the keyboard equivalent. Since many applications need the keystrokes for something else, you'll have a lot fewer surprises if you use the right-mouse method most places. Also, if you use 'synergy' to let a single keyboard/mouse access multiple computers running different OS's, the right-mouse action usually work no matter where you are.
Add to that KDE's intervention with Klipper which can be configured to synchronize the contents of the clipboard and selection or provide a separate clipboard and selection. Neither provides results exactly as expected.
Les Mikesell wrote:
On Wed, 2006-05-31 at 11:54 -0700, Gordon Messmer wrote:
So, basically, there are two clipboards in X. If you select text with the mouse, you can paste it with the middle button. If you use the "copy" menu item (or ctrl+c), you can paste it with the "paste" menu item (or ctrl+v). As long as you don't try to mix the two, like expecting "paste" to insert something that you selected with the mouse, you should be fine.
That's a little confusing. Almost everywhere the keyboard versions of copy/paste work there is also a right-mouse menu that works the same way as the keyboard
That's what I said.
, so the distinction isn't between using the mouse and the keyboard
That's not what I said.
Since many applications need the keystrokes for something else, you'll have a lot fewer surprises if you use the right-mouse method most places.
No, "many" applications don't use Ctrl+c/v or Ctrl/Shift+Ins for something other than copy and paste. For the most part, only terminal applications do that.
On Wed, 2006-05-31 at 11:54 -0700, Gordon Messmer wrote:
Rickey Moore wrote:
Using Oracle and Netscape we had to use Abiword in-between to cut & paste at all. Copy from Netscape, paste to Abiword, copy from
Abiword,
paste to Oracle. What a royal pain. It was explained to me, but I
have
forgotten the reason. Linux will never make it to Joe Lunchbucket's computer until it becomes resolved, and this problem goes back a
LONG
way. It was 6 years ago when we were doing that procedure to copy,
cut &
paste. I feel your pain. :) Ric
From the original post, it's not clear where he's trying to copy from or too. Clarification on that may help us explain why a particular application isn't behaving the way you'd expect. However, there's nothing wrong or broken about X or its copy mechanisms.
The Oracle front-end used java, I think. One of the RedHat guys can tell us what the deal was with Oracle as that was the app we had problems with. Ahha! I remember!! The Oracle app was called CRM that we had to use to do installation support with. I disliked it immensely. Rahul, have they finally got the kinks out of that old hack? The only good thing about it was that you could be at home, open an ssh session and then init cipe to tunnel to your RedHat machine at work, and have your CRM screen right there at home. I thought it was clunky, as my screen at home over a 56k modem refreshed almost as quick as it did at the office. <chuckles> It was a pantload and cursed daily while juggling Netscape to find the answers the support users could have found, copying and pasting to Abiword then copying and pasting to the CRM system, and looking so knowledgable to warrent the support costs. Google was just starting up then. Who knew? <chuckles> Ric
A: Because it's annoying to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
David Cary Hart <Fedora <at> TQMcube.com> writes:
Maybe the problem is in KDE. Sometimes ctrl-c works; sometimes it does not. Sometimes highlight->right-click-≥copy works.
But the biggest problem is with paste. ctrl-v never works. Shift-insert works but I never know what it will paste. Similarly, the middle button of my mouse works but I never know what I will get and it is different from the results of shift-insert.
So in summary after copy or cut, I am never sure whether shift-insert or the mouse-middle-button will paste the just cut text. Frequently, neither works properly.
Anyone else? Any suggestions? This is one of those minor annoyances that is extremely frustrating at times.
Keep in my mind that there are two different mechanisms. The selection is the currently highlighted text and it is pasted by the middle-mouse button. It is lost when something else is selected or the highlighting is lost.
The clipboard is explicitly copied or cut from the selection. Ctrl-C, Ctrl-X, and Ctrl-V are supposed to be the standard keyboard shortcuts for those. The older shortcuts, Shift-Ins, Ctrl-Ins also work in many apps. Gnome Terminal, for example, is different so it doesn't interfere with normal terminal keyboards; it uses Shift-Ctrl-C, etc.
My impression is that KDE was one of the last systems to change to the standard clipboard scheme and shortcuts. There are still a few applications which do things differently; Emacs is the most annoying one to me.
- Ian
-
Cameron Simpson -
CodeHeads -
Craig White -
David Cary Hart -
Ed Greshko -
Gordon Messmer -
Ian Burrell -
jdow -
Kayvan A. Sylvan -
laurence orchard -
Les Mikesell -
Matthew Saltzman -
Ric Moore -
Roy Tischer -
Steffen Kluge -
Thomas Taylor -
Tim -
Todd Zullinger