January 23, 2012 at 21:38Small life hack with clipboard editing
I often encounter this situation: I’m writing myself a text in something (say, a letter in the web interface of the email), and suddenly, at some point, there is a need to redo something ... and irritation occurs . It happens because editing in the browser (and many more) does not imply some conveniences familiar to the programmer, such as automatic replacement, regular expressions and macros. At the same time, it seems to be not difficult to copy the text to the buffer and edit it in the correct editor(Vim, Emacs, ...), but I really don’t want to get out of context and make any kind of gestures that distract from the current task ... And now, I already indent (number the list, replace the word, ...) manually - the result is achieved, and time was spent quite a bit, but the sediment remained ...
A familiar situation? If the answer is yes, bash works on your operating system and your first association to the word “editor” is not “Microsoft Office”, so we have something to discuss under the cut :)
So, I assume that if you already mastered it, all the more accustomed to some advanced features of your editor, you need to try to make these features as accessible as possible so that wherever you work with text, you can effectively apply your skills.
The most obvious way to solve this problem is to simply automate that part of the sequence of actions that is repeated without changes from time to time. We have two such sequences: one at the beginning of the transition to an external editor - select, copy to clipboard, open an external editor, paste; the second at the end - copy the edited into the buffer, close the external editor, paste the text to the old place.
But for starters, due to the fact that we are going to automate the work with the clipboard ...
(At the beginning I mentioned that any system where bash works will work, and that's true. So, if you have a poppy and the features of the X Window System parallel to you, feel free to skip this part)
First, remember that the clipboard in X Window is implemented very specifically . We have at least 3 clipboards - primary, secondary and actually clipboard. Everything that you select with the mouse gets into primary and “falls out” by pressing the middle mouse button, clipboard is usually Ctrl-V / Ctrl-C. Why do we need secondary, no one knows .
(Rumor has it that, in fact, X Windows is so cool that it can have as many clipboards as you like, and secondary is just another endless series. I find it difficult to even guess why this is necessary.)
Secondly, it is useful to understand that at every moment in time the contents of the clipboard are tied to the window from which it was extracted. Surely, this binding opens up many wonderful opportunities, but all of them, in my opinion, are nullified by one disgusting inconvenience: the contents of the clipboard disappear if you close the program from which it was copied.
Given these features, for stable and predictable work with the clipboard in Linux, I highly recommend using some kind of “clipboard manager”. KDE includes a completely usable klipper, and I would advise users of the Dwarf the utility parcellite (people still praise diodon, especially those who have Ubuntu + Unity, but I have not tried it myself). Whatever manager you use, it’s very useful to get used to invoking the clipboard history by pressing Ctrl-Alt-C or another key combination. Yes, and by the way, be careful with the option “synchronize clipboards” - after its inclusion, any selection of text will “overwrite” the current contents of the clipboard, even if you consciously and explicitly added something there using Ctrl-C.
So, to achieve our goals we will need: (1) a tool that allows you to globally bind the execution of an arbitrary command to pressing a magic button and (2) a small script of your own composition.
As for binding to keyboard events, there are many solutions, but I see no reason not to use the tools built into the system (both KDE and Gnome offer their own shortcut editors).
The script itself, to which we will bind the event, may look like this:
Now it's up to the little thing - save the script in ~ / bin / editclip, bind it to pressing F12 (or any other keyboard shortcut) - you're done! We can at any time, in any "left" editor, select the desired fragment, press "Ctrl-C, F12" and the fragment will open in the desired program, after closing it, it will be enough to press Ctrl-V and the edited text will fall into place.
Lastly, one more little tip regarding the X Window. Unfortunately, text selection is not an internal matter of the program. If you selected the text in one window, and then switched to another and selected the text again, then the selection may fly off in the original window ( upd: or it may not fly off - in the comments they suggest that gtk programs are especially prone to this effect). This is very unpleasant, because we either have to edit the text in an external editor in every way to avoid selection (which is unnatural), or to accept that just pressing Ctrl-V at the end will not always replace the old fragment with the edited one.
To get around this inconvenience, I usually invoke an external editor using “Ctrl- X , F12”- in this case, the original text fragment is immediately deleted and pressing Ctrl-V in the final inserts the edited version in its place.
That's all. I hope this trick comes in handy for someone.
A familiar situation? If the answer is yes, bash works on your operating system and your first association to the word “editor” is not “Microsoft Office”, so we have something to discuss under the cut :)
So, I assume that if you already mastered it, all the more accustomed to some advanced features of your editor, you need to try to make these features as accessible as possible so that wherever you work with text, you can effectively apply your skills.
The most obvious way to solve this problem is to simply automate that part of the sequence of actions that is repeated without changes from time to time. We have two such sequences: one at the beginning of the transition to an external editor - select, copy to clipboard, open an external editor, paste; the second at the end - copy the edited into the buffer, close the external editor, paste the text to the old place.
But for starters, due to the fact that we are going to automate the work with the clipboard ...
A few notes about the clipboard in the X Window System.
(At the beginning I mentioned that any system where bash works will work, and that's true. So, if you have a poppy and the features of the X Window System parallel to you, feel free to skip this part)
First, remember that the clipboard in X Window is implemented very specifically . We have at least 3 clipboards - primary, secondary and actually clipboard. Everything that you select with the mouse gets into primary and “falls out” by pressing the middle mouse button, clipboard is usually Ctrl-V / Ctrl-C. Why do we need secondary, no one knows .
(Rumor has it that, in fact, X Windows is so cool that it can have as many clipboards as you like, and secondary is just another endless series. I find it difficult to even guess why this is necessary.)
Secondly, it is useful to understand that at every moment in time the contents of the clipboard are tied to the window from which it was extracted. Surely, this binding opens up many wonderful opportunities, but all of them, in my opinion, are nullified by one disgusting inconvenience: the contents of the clipboard disappear if you close the program from which it was copied.
Given these features, for stable and predictable work with the clipboard in Linux, I highly recommend using some kind of “clipboard manager”. KDE includes a completely usable klipper, and I would advise users of the Dwarf the utility parcellite (people still praise diodon, especially those who have Ubuntu + Unity, but I have not tried it myself). Whatever manager you use, it’s very useful to get used to invoking the clipboard history by pressing Ctrl-Alt-C or another key combination. Yes, and by the way, be careful with the option “synchronize clipboards” - after its inclusion, any selection of text will “overwrite” the current contents of the clipboard, even if you consciously and explicitly added something there using Ctrl-C.
Actually, the recipe
So, to achieve our goals we will need: (1) a tool that allows you to globally bind the execution of an arbitrary command to pressing a magic button and (2) a small script of your own composition.
As for binding to keyboard events, there are many solutions, but I see no reason not to use the tools built into the system (both KDE and Gnome offer their own shortcut editors).
The script itself, to which we will bind the event, may look like this:
At the same time, the choice of specific utilities, of course, may differ. For example, not only xclip can work with the clipboard from the command line - instead of xclip, you can use the xsel utility or the clipboard manager, and if you have a poppy and OS X, then there are pbcopy / pbpaste commands.
- #! / bin / bash
- tmp = "$ (mktemp)" # create a temporary file
- xclip -sel clip -o> "$ tmp" # copy clipboard contents to the created file
- gvim -f "$ tmp" # open the file in the desired editor (gvim - as an example)
- cat "$ tmp" | xclip -sel clip # copy file contents back to clipboard
- rm "$ tmp" # delete temporary file
Now it's up to the little thing - save the script in ~ / bin / editclip, bind it to pressing F12 (or any other keyboard shortcut) - you're done! We can at any time, in any "left" editor, select the desired fragment, press "Ctrl-C, F12" and the fragment will open in the desired program, after closing it, it will be enough to press Ctrl-V and the edited text will fall into place.
Lastly, one more little tip regarding the X Window. Unfortunately, text selection is not an internal matter of the program. If you selected the text in one window, and then switched to another and selected the text again, then the selection may fly off in the original window ( upd: or it may not fly off - in the comments they suggest that gtk programs are especially prone to this effect). This is very unpleasant, because we either have to edit the text in an external editor in every way to avoid selection (which is unnatural), or to accept that just pressing Ctrl-V at the end will not always replace the old fragment with the edited one.
To get around this inconvenience, I usually invoke an external editor using “Ctrl- X , F12”- in this case, the original text fragment is immediately deleted and pressing Ctrl-V in the final inserts the edited version in its place.
That's all. I hope this trick comes in handy for someone.