I often encounter such a situation: I write myself calmly
in some text (say, a letter in the web interface of a gmail), and suddenly, at some point, there is a need to remake something ... and
irritation happens. It happens from the fact that editing in the browser (and much more where it is) does not imply some of the usual programmer conveniences, 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 do not want to break away from the context and make some gestures that distract from the current task ... And now , I already indent (I number the list, replace the word, ...) manually - the result is achieved, and not much time was spent, but the sediment remained ...
Common situation? If the answer is "yes", bash works in your operating system and your first association to the word "editor" is not "Microsoft Office", so we have something to discuss under the cat :)
So, I assume that if you have already mastered - and even more so are used to - some advanced features of your editor, then you need to try to make these possibilities as accessible as possible so that no matter where you work with the 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 from time to time without changes. We have two such sequences: one at the beginning of the transition to an external editor -
select, copy to clipboard, open external editor, paste; the second at the end -
copy the edited to the buffer, close the external editor, paste the text on the old place.But for a start, due to the fact that we are going to automate work with the clipboard ...
A few notes about the clipboard in the X Window System.
(At first, I mentioned that any system in which bash works will fit, and this is true. So, if you have a Mac and the X Window System features are parallel to you, feel free to skip this part)First, remember that the clipboard in the X Window is very specific. We have at least 3 clipboards - primary, secondary and clipboard itself. Everything that you select with the mouse gets into the primary, and it “drops out” when you press the middle mouse button, the clipboard is
usually Ctrl-V / Ctrl-C. Why secondary is needed
nobody knows .
(It is rumored that, in fact, X Windows is so steep that it can contain as many buffers as possible, and the secondary one is just one of an infinite series. I find it difficult even to guess why.)Secondly, it is useful to understand that at each 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 possibilities, 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.
Taking into account 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 Gnome parcellite utility (people still praise diodon, especially those who have Ubuntu + Unity, but I have not tried it). Whichever manager you use, it is very useful to get used to calling up the clipboard history by pressing Ctrl-Alt-C or another shortcut. Yes, and by the way, be careful with the option to “synchronize clipboards” - after it is turned on, any text selection will “overwrite” the current contents of the clipboard, even if you consciously and explicitly added something to it using Ctrl-C.
Actually, the recipe
So, to achieve our goals, we will need: (1) a tool that allows you to globally link the execution of an arbitrary command to the magic button and (2) a small script of his own.
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 attach the event, may look like this:
- #! / bin / bash
- tmp = " $ (mktemp) " # create temporary file
- xclip -sel clip -o > " $ tmp " # copy the contents of the clipboard into the created file
- gvim -f " $ tmp " # open the file in the desired editor (as an example gvim)
- cat " $ tmp " | xclip -sel clip # copy the contents of the file back to the clipboard
- rm " $ tmp " # delete temporary file
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, but if you have a Mac and OS X, then there are pbcopy / pbpaste commands.
Now it's easy - save the script in ~ / bin / editclip, bind it to pressing F12 (or any other shortcut key) - that's it! 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 which, it will be enough to press
Ctrl-V and the edited text will fall into place.
Lastly, another little tip regarding the X Window. Unfortunately, the selection of the text is not here an internal affair of the program. If you selected the text in one window, and then switched to another and selected the text again, the selection in the initial window may fly off (
upd: or may not fly off - in the comments they suggest that gtk programs are especially affected). This is very unpleasant, because we have to either avoid editing a selection (which is unnatural) by editing the text in the external editor, or accept the fact that simply pressing Ctrl-V will not always replace the old fragment with the edited one.
To get around this inconvenience, I usually call the external editor with the help of
“Ctrl- X , F12” - while 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 is useful to someone.