Seven efficient text editing habits
If you spend a lot of time typing in plain text, writing programs, or HTML, you can save most of your time by using a good editor effectively. This article will provide guidance and tips for you to do these things more quickly and make fewer mistakes.
This article uses the Open source text editor vim (Vi improved) to demonstrate how to edit efficiently, and this method also applies to other editors. Choosing the right editor is actually the first step in efficient editing. We avoid discussing which editor is best for you because this topic takes up too much space. If you don't know which editor to choose, or if you're not satisfied with the editor you're using, try vim; you won't be disappointed.
part 1th: Editing a file
1. Fast Moving
Spend most of your time reading, checking for errors, and looking for the right place to work instead of inserting new text or modifying it. Navigating within text is very frequent, so you should learn how to do it quickly.
Many times, when you want to search for some existing text, or look for a word or phrase in all lines, you can simply use the Search command and pattern to find it. But there are more intelligent ways to do it:
- If you see a specific word and want to search elsewhere where it appears, use the command *. It locates the word from under the cursor and searches for the next one.
- If the "incsearch" option is set, VIM will display the text of the first matching pattern as you enter it. This can quickly display a pattern error.
- If the "hlsearch" option is set, VIM highlights all matching patterns with a yellow background, giving you a quick overview of the results of the search command. It can show where a variable is being used in the program code. You don't even need to move the cursor to see the matching text.
There are more possibilities for moving quickly in structured text. Vim has specific commands for C (and similar languages, such as C + + and Java) programs:
- Use% to jump from an opening parenthesis to the right parenthesis paired with it, or from a "#if" to a paired "#endif". In fact,% can jump to many different matching items. It is useful for checking the structural integrity of if () and {}.
- Use [{ ] to jump back to the beginning of the current code block.
- Use gd to jump from a variable's call to its local declaration.
Of course there are more, the point is that you need to know these commands. You might think that it's impossible to understand all of these commands--there are hundreds of different move commands, some simple, some very flexible--it takes weeks of training to learn them. However, you do not need to do this. Instead, you need to know your specific editing style and only learn the commands that will make your edits more efficient.
Three basic steps:
- When you are editing, be aware of the repetitive and/or time-consuming actions.
- Look for an editor command that will perform this action faster. You can read a document, ask a friend, or see what others are doing.
- Practice using this command until you can enter it without thinking about your finger.
Let's use an example to illustrate how this works:
- You will find that when editing a C program file, you often spend time looking for a function to be defined somewhere. Currently you use the * command to search for other locations where the function name appears, but will eventually iterate through the matches used by many functions, rather than being defined. You will think that there must be a quicker way.
- For a quick reference, you'll find comments about jumping to a tag. The documentation explains how to use it to jump to a function definition that you are looking for.
- You test it. Use the Ctags program containing vim to generate a label file. Learn to use the Ctrl] command and you'll find that you save a lot of time. An easier way is to add a few lines to your makefile to automatically generate the label file.
Here are a few things to keep in mind when using these three steps:
- "I want to do my job well, I don't have time to go through the documents looking for some new commands. "If you think so, you will stay in the calculation of the Stone Age. Some people use Notepad for everything, and then marvel at the fact that others use half the time to complete their work.
- Overkill If you are always trying to find the perfect command to do every little thing, you will have no time to think about the work you are actually going to do. Just pick out the actions that go beyond the necessary time and practice the commands until you don't have to think about them when you're using them. Then you can focus on the text.
Some of the actions that most people need to deal with are suggested in the following sections. You can be inspired to use these three basic steps in your work.
2. do not enter two times
We enter a limited set of words, even limited phrases and sentences, especially in computer programs. Obviously, you don't want to enter the same thing two times.
Many times, you want to change a word. If it is in the entire file, you can use the : S(substitute) command. If only a few places need to be modified, a quick way is to use the * command to find the next occurrence of the word, using the CW command to modify it. Then enter N to find the next word and enter a comma in English . repeat the CW command.
. command to repeat the last modification. The change here is to insert, delete, or replace text. Being able to repeat is a very powerful mechanism. If you are based on it to arrange your edits, many changes will become just knocking. Key. Keep an eye out for other changes, because it will replace the one you originally wanted to repeat. Instead, you can mark the position with the m command, continue repeating your changes, and return to this location later.
Some functions and variable names can be entered awkwardly. Can you enter "Xpmcreatepixmapfromdata" quickly, without a typo, and without querying it? Vim has a complete mechanism to make it easier. It queries the words in the file you are editing, which also includes the # include file. You can type "XPMCR" and then press Ctrl-n, VIM will extend it to "Xpmcreatepixmapfromdata". This not only saves the input time, but also avoids typos, and avoids fixing it later when the compiler makes an error.
When you enter a phrase or sentence multiple times, there is a quicker way to do it. Vim has a mechanism for recording macros. You enter the QA boot recording to register "a". Then as usual, you enter the command, and finally press Q again to terminate the recording. When you need to repeat the recorded command, enter @a. A total of 26 registers are available.
The recording function can repeat many different actions, not just inserting text. Remember this when you want to repeat something.
One thing to note is that the recorded commands will be played back exactly as you entered. You must know that the text you move may be different from the command you repeat. Moving left four characters may be appropriate for the text you are recording, but it may take five characters where you repeat the command. This often requires the use of commands to move to a text object (Word, sentence) or move to a specific character.
The more complex the commands you need to repeat, the more difficult it will be to enter them correctly at once. Instead of recording them, you should write a script or a macro. This is useful for templates that make part of your code. For example, a function header. You can do it as flexibly as you wish.
3. errors to be corrected
It is normal to enter errors, and no one can avoid them. The key is to quickly identify and correct them. The editor should be able to help you, but you have to tell it what is wrong and what is right.
Often you will make the same mistake over and over again. What you're typing is not what you're going to do with your finger. This can be corrected by abbreviations. For a few examples:
1 2 3 |
:abbr lunix Linux :abbr accross across :abbr hte the |
After you enter these words, they will be corrected automatically.
Using the same mechanism, you can enter only a few characters to get a long word. This is useful for words that are difficult to enter and avoids typing errors. Example:
1 2 |
:abbr pn Penguin :abbr MS mandrake software |
However, when you do not want to expand to the complete word, you will find it difficult to insert "MS" into the text. It's best to use short words that don't literally mean.
Vim has a flexible highlighting mechanism that finds errors in your text. This is actually highlighted as a syntax for the program, but he can also capture and highlight errors.
Syntax highlighting displays annotations in color. This doesn't sound like an important feature, but once you start using it, you'll find it helps a lot. You can quickly find text that is supposed to be a comment but not highlighted (which may make you forget the comment tag). or see the line code being highlighted as a comment (you forget to insert a "* *"). These errors are difficult to find in the B&w file and may waste a lot of time debugging the code.
Syntax highlighting can also capture mismatched parentheses. Mismatched ")" is displayed with a bright red background. You can use the% command to see how they match and insert a "(" or ")" in the appropriate location.
Other common errors can be quickly detected, such as using "#included <stdio.h>" instead of "#include <stdio.h>", which can be easily missed in the B&w file. But you will soon find that "include" is highlighted, and "included" does not.
A more complex example: Use a long list of all words in English text. Any word that is not in the list may be a typo. You can use a grammar file to highlight all the words that are not contained within this list. You can use some extra macros to add words to the thesaurus so that they are no longer flagged as errors. This is just like the word processor you expect. It is implemented in vim with scripting, and you can further adjust it as needed. For example, just check the spelling errors in the comments in the program.
Part 2nd: Editing Multiple Files
4. Only one file is in very small condition
People don't just work on a file, most of the time there will be many related files, you can edit them one by one, or several at once. You should be able to make full use of your editor, making editing several files more efficient.
The previously mentioned labeling mechanism also applies to moving between files. A common practice is to generate a label file for the entire project you are working on. You can then look for definitions of functions, institutions, types, and so on across all the files in your project. Compared to manual search, this saves time very handsomely. Creating a tag file is the first thing I want to do when I browse the program.
Another powerful mechanism is to use a set of files : the grep command finds all the locations where a name appears. Vim creates a list of all matches and jumps to the first match. : The CN Command takes you to the next match in turn. This is useful if you need to change the number of arguments for a function call.
The Include file contains useful information, but it takes time to find a declaration that contains the one you need to see. Vim knows the include files and can search for the words you are looking for in them. The most common action is to find a prototype of a function. Put the cursor in the function name in your file, enter [I:, VIM will display a list containing all the names of the functions that match the function in the include file. If you need to see more context, you can jump directly to the declaration. A similar command can be used to check if you include the correct header file.
In Vim, you can edit different files by dividing the text area into several areas. Then, you can compare the contents in two or more files and copy (paste) the text. There are many commands to open and close windows, jump between them, temporarily hide files, and so on. Again, you need to apply three basic steps to select the set of commands you intend to learn to use.
Multiple windows have more uses. The preview tag mechanism is a good example of opening a special preview window while keeping the cursor in the file you are working on. The text is displayed in the preview window, such as the function declaration for the functions name under the cursor. If you move the cursor to another name and stay for a second, the preview window will display the definition of that name. This can also be the name of a struct or function declared in the project include file.
5. Let us work together
The editor is used to edit text, the e-mail program sends and receives messages, and the operating system runs the program. Each program has its own task and is adept at it. This power stems from the collaborative work of the program.
A simple example: you need a summary of no more than 500 words. Select the current paragraph to write to the "WC" program:vip:w!wc–w. The external command "WC-W" is used to calculate the number of words. It's simple, isn't it?
There will always be some features you need that are not included in the editor. You can add features externally to allow the editor to filter text using another program. The essence of Unix has always been to use different programs to do their own work, and to collaborate on a larger task. Unfortunately, most editors don't work well with other programs-for example, you can't replace the e-mail editor in Netscape with another editor. You will terminate the use of the mutilated editor. Another trend is to include all features in the editor, and Emacs is a good example to terminate (some call it an operating system that can be used to edit text. )
Vim is trying to integrate with other programs, but this is still a challenge. Currently, it can be used as an editor for Ms-developer studio and sniff. Some e-mail programs like Mutt support external editors and can use VIM. Integration with the Sun workstation is in progress. In short, this is an area that must be strengthened in the near future. Only in this way can we get a system that is better than the simple addition of each part.
6. Text Structure
You will often encounter text with some kind of structure, but it is different from the ones supported by the existing commands. You will then have to go back to the editor's "bricks" and create your own macros and plugins to handle the text. We are here to touch more complex things.
One of the simpler things is to speed up the edit-compile-fix cycle. Vim has : make command, start compiling, catch the error it produces, and let you jump to the wrong location to fix the problem. If you use a different editor, the error message will not be recognized. You should adjust the "error format" option instead of returning to the old "write it Down" system. This tells VIM what your error looks like and how to get the file name and line number. It applies to complex GCC error messages, so you should be able to make it work with almost any editor.
Sometimes adjusting to a file just sets some options or writes some macros. For example, to jump in the manual page, you can write a macro to get the word under the cursor, clean up the buffer, and then read the word to the buffer from the manual page. This is a simple and efficient way to query cross-references.
With 23 basic steps, you can work with files of any structure in a more efficient way. Think about the action you want to make to the file, find the commands that can do it, and start using them. As you hear, it's really simple. You just have to do it.
Part 3rd: Ax
7. forming a habit
It takes effort to learn to drive. Is that why you keep riding a bike? No, you recognize the need to devote time to learning a skill. Text editing is not the same. You need to learn new commands and turn them into a habit.
On the other hand, you should not try to learn all the commands provided by the editor. That would be a complete waste of time. Most people only need to learn 10% to 20% of the order for their work. But for everyone, the order is different. It requires you to go back and think about whether there are some repetitive tasks that can be automated. If you do the task only once and do not expect to do it again, then don't try to optimize it. But you may realize that you have spent one hours repeating several times to do something, and then search the document for a command that will do it faster. or write a macro to do this. When it is a bigger task, such as selecting a special text, you can browse under newsgroups or the Internet to see if someone has solved the problem for you.
The essential basic step is the last one. You can think of a repetitive task, find a good solution, and over the weekend forget how you did it. It doesn't work. You have to repeat it to know that your fingers can automatically go about doing this. Only in this way can you achieve the efficiency you need. Don't learn too much at once, and do something at once. Record your infrequently used skills in the form for later use. Anyway, if you stick to your goals, you'll find ways to make your edits more and more efficient.
The last sentence reminds me of what happens when people overlook what is mentioned above: I still see people spend half a day on the computer screen (VDU), looking up at the screen, looking down at two finger inputs, looking up at the screen, and so on. --and then they wondered why they were so tired ... Use ten-finger input! It's not just faster, it can also reduce boredom. Using a one-hour computer program every day, it takes only a few weeks to learn to enter by fingering.
Conclusion
The idea of the title came from the successful book "Seven Habits of high-energy people" by Stephen Covey. I ask people who need to solve their personal and professional problems (who doesn't?) ) recommend this book. While some will claim it comes from Scott Adams's "Dilbert-7 years of highly flawed people" (also recommended).
Blame Miller written in November 2000
About the author
Blame Miller (Bram Moolenaar) is the main author of Vim. He wrote the VIM function core and chose to include code submitted by others. He graduated as a computer technician from the Delft University of Technology. Now, it is mainly engaged in software work, but still knows how to use a soldering iron. He is the founder and treasurer of ICCF (Netherlands), helping orphans in Uganda. He is a freelance worker working in a system architect, but spends most of his time developing vim. His email address:[email protected].
Seven efficient text editing habits (with Vim as an example)