That's Vimprovement! A Better vi
When you jump to a tag using the CTRL-] command, the entire screen jumps. If you use the command CTRL-W CTRL-], the current window is split and you do a tag jump in the new window.
Suppose you have five or six small programs in a directory, and you want to jump to the definition of one of the main functions. If you do a:
command, the editor will jump to the first definition of main that it can find. This may or may not be the one you want.
The :tselect command displays all the tags that match a given name and lets you select the one you want. For example:
:tselect main # pri kind tag file > 1 F C f main a_test.cpp int main( int argc, char* argv ) 2 F f main acp.cpp int main( int argc, char* argv ) 3 F f main add.cpp int main(int argc, char* argv) Enter nr of choice (<CR> to abort): 3
What if you only know part of a name? In other words, you want to go to the function whose name is “something- process-something-data”. The :tags command can take a regular expression. In this case the command:
:tag /process.*datagoes to the first tag matching this expression. If several functions match the expression, you can use :tselect to go to the right one.
Programs contain code and comments. Code has its own structure. You do not want an editor that line wraps when you write code. But comments are merely text and it's okay to wrap text. In fact in most cases, it is highly desirable to have an editor that wraps long text lines.
The Vim editor understands the difference between commands and code. It can be configured to wrap comments and leave the code alone. This is done by putting the following lines in our .vimrc file:
:autocmd FileType c,cpp \ set formatoptions=croql cindent \ comments=sr:/*,mb:*,ex:*/,://
(Note: continuation lines in *begin* with \.)
The :autocmd command tells Vim that these commands are to be executed whenever it determines that it is working on a C or C++ file. (File names ends in .c or .cpp.)
The formatoptions tells Vim that we want to automatically wrap comments but don't want code wrapped. The next line:
tells Vim what a comment looks like. In this case we've defined the standard C comment (/*, */) and the C++ comment (//). We've also told Vim that if we are in the middle of a C-style comment, to please begin each line with a “*”.
With these options set, when you type /*<RETURN>, Vim automatically puts in a “ *” to begin the next line. Given the limited space allowed in this article, all I can really tell you is that this is a really neat feature, and you should play around with it. If you need more details, you can check out the on-line help text.
Vim is a very versatile editor. In this article we've touched on a few of the more interesting features of this editor. But we only scratched the surface. There are still hundreds of commands and options that we've not discussed. You can find out about these by reading the help text and other documentation that comes with the editor.
By introducing you to some of the new features in Vim we've given you a start toward more effective editing. How far you go from here is up to you.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- SourceClear Open
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide