Popping The Stack

We considered the essential features in .vimrc required by a programmer editing in vim in Chapter 0. Time for some more features, more easy editing, and more horrible puns. The updated version has been uploaded on github on a new branch. Click here for the source.

Code folding

Code folding is a feature that is an integral part of almost all the editors. You do not want the burden of seeing all the functions, loops and blocks in your code all the time : the time to scroll through is too tiring. The answer is to fold those sections : that is substitute them view-wise with a single header describing the code block.

Eclipse allows you to fold functions through mouse button clicks. Since we assert our loyalty to the keyboard while using vim, lets see how we can manage that. For convenience sake, we will use key mappings for useful folding operations.

a. Lets look at the first mapping. The zfa} is used to fold a code block enclosed by { and }. For this, the cursor needs to be present between the two braces. Thus, to fold the block, all you need is to position your cursor between its two braces, and type the sequence zfa}.

b. The second mapping is slightly complex to understand, but it spares the user from manually having to move the cursor to the block of interest. This mapping allows you to directly fold the next block to be encountered. Lets break this down to simplify.

1. Search for the next occuring } using the “/}” command and take your cursor there. (<CR> stands for Enter)
2. Do a zf% to fold the block.
3. Do a nohlsearch to undo the effect of your /} command that highlights all the }’s. This is required only if you have set the hlsearch option in your .vimrc.

c. To remove any folds in the code, we can use the third mapping for zE.

More on folds can be found here.

The mkview-loadview cycle : Understanding the chakra-view

Once you are done setting your folds, you want them saved across different sessions, that is, the folds should be preserved after closing and re-opening a file. In general, you can create a view of your folds using the mkview command, and reload that view using the loadview command. Using the au command from Chapter 0, we can make the loading and saving automatic.

More on views here.

NOTE : Before you set these options in your .vimrc, make sure that the $HOME/.vim folder is created. Any new view that you create using mkview is stored in the $HOME/.vim/view directory.

Vim and windows

Even with terminals allowing multiple split windows on the current screen, having multiple windows within a current session is helpful as well, when it comes to certain tasks. For example, you can easily copy-paste text the vim way between two open windows in the same vim session. Another use of multiple windows in vim is when you are browsing code using a tool like cscope, where searches for a declaration or a definition can be conveniently opened in new windows. Here‘s a basic tutorial for windowing in vim.

1. Initial window height

Suppose you have a single file in a window open in a vim session. Suppose you want to open another file in a split window (using the split command). How many lines should you display for the old and the new file? This is decided by the winheight parameter. By setting this parameter to a very high value, say 9999, we always ensure that the newly opened window will occupy most part of the vim session, whereas the older windows will be minimized. This parameter is set accordingly.

2. Changing window size

To control the size of the window, we can define additional mappings.

In the above mappings the <leader> corresponds to the ‘\’ character. Therefore, the mapping \+ will increase the window size to 3/2 the original, whereas the \- mapping will reduce the window size to 2/3 the original.

3. Cursor migrations across windows 

And finally, window migrations. Vim defines ways for you to migrate your cursor between multiple windows opened up in the same session, but the keystroke sequence for them is a bit complex. We therefore provide some simple mappings for the same.

The C-J stands for Ctrl+J key sequence. The same applies to other mappings.

More on windowing options in vim is available here.

A note on the new .vimrc structure

The latest .vimrc source is available on the github account, on the v1 branch. As of now, the main .vimrc file will only be a file which sources other files, each corresponding to one chapter. Therefore, in the current .vimrc file, we source 2 individual files :

Each .vim file contains the actual settings we discuss in the blog.

Any comments, questions, feedback highly appreciated. Please write to us at poppingthestack@gmail.com.

References:

1. On folding : http://vim.wikia.com/wiki/Folding

2. On views : http://vim.wikia.com/wiki/Make_views_automatic

3. Basic options for windowing : http://web.cs.swarthmore.edu/help/vim/windows.html

4. On more windowing : http://vimdoc.sourceforge.net/htmldoc/windows.html

Introduction

Using the command-line terminal in any *nix environment can be intimidating to many beginners. This tutorial introduces the reader to the shell and some default script files used with Linux. This is not meant to be an article for an advanced reader, but instead, sets out to serve as a sort of primer for any person interested in scripting in Linux.

First, a two line history about Bash. Bash was a program written by Brian Fox and released in 1989, for the GNU project. Bash was written as a Free Software replacement for the Bourne shell (a command processor program written by Stephen Bourne), which in turn was a replacement for the Mashey shell (a command processor program, written by John Mashey). For more on the history of development of the shell program, the following are a good source for the interested reader:

• PWB Shell
• Bourne Shell
• Bash (Unix Shell)

So as mentioned above, the Bash shell is a program that basically parses text, uses that parsed knowledge combined with already installed command line functions (cd, grep, ls, etc) to provide greatly flexible and interactive functionality. What makes Bash even more attractive is the ability to perform controlled loops, conditional checks and store information in temporary variables – all the things that are present in a programming language. An excellent introduction can be found at the official Bash reference page here.

Types of Shells

Shells can be classified primarily on two attributes, which answer two different questions:

1. Is the user required to enter a username/password combination to use this shell? login/non-login
2. Can the user input commands to this shell, which the shell would then execute and show output for? interactive/non-interactive

Here are a few examples that any shell user may have frequently come across, to illustrate the above mentioned types in greater detail:

• A user types cd into an Ubuntu terminal — interactive shell
• A user wants to start an application. So he goes into the installation’s /bin directory, and types

$ ./application.sh.

The terminal prompt disappears, the application runs, and then the command prompt in the terminal re-appears with a message “application run successfully. Socket closed” — non-interactive shell

• A user starts his Ubuntu box, and is prompted for a password for the default user — login shell
• A user clicks the terminal icon on his desktop that opens a new terminal window, that then presents a command line prompt — non-login shell
• A user ssh’s into a remote virtual machine using login credentials — login shell

But if one observes, there are four types in total that one could classify a given shell to fall under:

1. Interactive login shell
2. Interactive non-login shell
3. Non-interactive login shell
4. Non-interactive non-login shell

So, to re-label our examples above,

• A user types cd into an Ubuntu terminal — interactive non-login shell
• A user wants to start an application. So he goes into the installation’s /bin directory, and types

$ ./application.sh.

The terminal prompt disappears, the application runs, and then the command prompt in the terminal re-appears with a message “application run successfully. Socket closed” — non-interactive non-login shell

• A user starts his Ubuntu box, and is prompted for a password for the default user – interactive login shell
• A user clicks the terminal icon on his desktop that opens a new terminal window, that then presents a command line prompt – interactive non-login shell
• A user ssh’s into a remote virtual machine using login credentials – interactive login shell

One category that you’ll see missing above: non-interactive login shell. Indeed, these kinds of shells are rather rare (think about it: A shell that doesn’t let you interactively enter commands, yet asks for username/password credentials. Now how many times have you seen that?), but they none-the-less exist. Try typing the following into your terminal:

where your_user_name is the user name that you are logged in as. If you don’t know what that is, try running the following command:

This will tell you what the username of your current session is.

What the above series of commands should do, is ask you for a password when you run the exec part (login) and once you do so, the terminal should close. However, when you re-open a new terminal and go into the Desktop directory, you will indeed see a copy of the file test.txt. This is the non-interactive part (the shell didn’t ask you for any input other than password, and never stayed around to show you any output).

Different Flavors of Start-up Scripts

Now that we are armed with the knowledge of different types of shells, it is but natural to have a script file that runs automatically, for each type of shell. Why so? This is to allow the user enough flexibility for the shell to respond to the type of login! Suppose for example, that a user wants to keep a log of who remotely logged into a remote repository (basically, an operating system not present locally on one’s computer). But the user doesn’t want to count the logins that he made himself! In another case, a user might need to know how some system peripherals are doing, while logging in remotely; but in a non-login terminal, the user can just use a graphical tool to monitor system performance. As a final example, a user may want to have a single function that can extract data from any kind of compressed file format (there are a ton out there. Some famous ones are .zip, .gz, .tar), instead of remembering which package to use for what compression type (unzip, tar, or gunzip?). To cater to these varied needs dependent on the type of interfacing, it makes sense to have different script files run for different shell types.

Classifying the different script files then becomes real easy! Here is a table of the type of shell, along with the script file that is usually run, when using Bash:

Type of shell	Configuration script run
Interactive non-login shell	~/.bashrc
Login shell (both interactive and non-interactive)	~/.bash_profile
Interactive shell (both login and non-login)	~/.bash_logout
Interactive login shell	/etc/profile

The above listed configuration files are the ones that exist in all Linux distributions. Apart from these, your distribution may have files specific to that OS, and so those would be non-generic files, which is not the subject matter here.

The ~/.bashrc is probably the most widely configured script file. As the tables above mention, whenever starting a new shell, say a new graphical terminal, the .bashrc file is “sourced”. This means, the script is run every time an interactive non-login shell is called for. This makes it suitable as a start-up script for terminal prompts.

In the next tutorial, we will actually go through a .bashrc file and see what interesting things we can do with it! Feel free to leave questions/comments below!

We are all so crazy about our editors, we make them our personal strengths of programming. xkcd couldn’t have expressed it better :

With the blessings of my inspiration, Mr. Shiv Khera (oh yeah!), I shall agree with the lady in the second panel and embark upon making your life in vim easier.

The idea behind the exercise 

I have to admit that I am very much new to vim features, and I figured that the best way to learn them would be to document and explain them. I waded through so many rich sources of vim, and figured that although they contain excellent information, their scattered form across different web-sites frustrates a beginner in trying to figure out how to add a specific feature in vim.

When you start using an editor, the first thing you want to do is to learn the tricks and shortcuts for quick and easy typing. This is required more often in coding where you want your editor to :

1. Index your code

2. Automatically indent it

3. Compile it with a tap of a button

4. Automatically represent the keywords in your code with different syntax

Essentially, anything that makes the code more readable, browseable, and easy to debug.

Since the literature on vim is vast and scattered across the internet, my intention here is to collect together useful tools that can help you learn vim and make it more useful for your purposes at the same time.

The simplicity that is .vimrc

Vim mirrors the modular policy of GNU/Linux, in that you can start off with as simple an editor as you want, and you can work your way up to add as many features  (modules) as you like. With every feature, your vim will get heavy, and often break under complex conditions, but you always have an option of cutting it down again (as opposed to big packages such as Eclipse).

For this tutorial, I shall assume that the reader has a working knowledge of vim (For a quick training in vim, please refer to the vimtutor or go have a nice adventure).

To go beyond the basic tools of vim, you can automate much part of it using the .vimrc file. This file is present in the $HOME directory of your machine (I shall assume Linux/Mac OS here), and is read by vim every time at startup of the program. This file contains an army of options, macros, functions that a user can define to automatically  execute operations for different actions of the user. The number of such options are huge, and it would take a real long time to master them. My focus here would be to introduce certain key features you might require more often than not, with the help of some horrible puns.

These features have been compiled into a .vimrc (along with suitable comments) that you may download from here and start using (Aah, the TL;DR’s!). Just add it to your $HOME folder, and open a new file. 🙂

1. The Set Theory (:set) 

This could be the simplest option in vim. We can address a number of features using the set option. Here are a few examples :

With the set option, you can enable a number of options in highlighting, searching, indenting. The comments inlined in the code explain the utility of each option.

2. Making a (in)dent

Indenting forms an essential part of coding, and vim provides its efforts for the cause. The comments in the coming code block explain the various options (again enabled using the set option).

A beautifully indented code is a necessity, but certainly not at the cost of all those tabs you may have to enter manually. Embrace smartindent :P.

3. For the mousahari carnivores (Mouse options)

Though I am not too much in favor of using a mouse for vim, it often comes handy when you are want to move the cursor quickly to an arbitrary position in the visible file. It also helps if you want to highlight a numbered file (set using :set nu), while excluding the numbers from the highlight. Other advanced options, such as searching for a word using a mouse can be set with the mousemodel option.

4. Mapping the territory 

Ah yes, the shortcuts! Vim provides the map command with a number of variants to map specific key combinations to perform a bunch of actions.

More information on different variants of map can be found here.

5. Abbreviations

Similarly, abbreviations can be created that autocomplete to specified strings :

6. Remembering our past

You can specify commands to be executed automatically when reading or writing a file, when entering or leaving a buffer or window, and when exiting Vim. This is done by the autocmd command (abbreviated as au). One of the most important applications is opening a file and moving the cursor automatically to its location when the file last exited. This is the command :

Let us break down the command step-by-step.

1.The start of an auto command is done by mentioning the au or autocmd.

2. What follows the au is the event required for triggering the auto command. In this case, the event is BufReadPost, indicating the time when the buffer is read in from the secondary storage but the modelines are yet to be executed.

3. The “$” indicates the last line of the buffer, and the symbol ‘\” determines what  the location of the cursor in the file was, the last time it was closed.

4. The exe executes the command that is provided to it as an argument; in this case the argument is normal! g’\”.

5. normal! indicates that we execute in the normal mode, where the symbol “!” asks to clear any mappings (macros) when executing. This is done, because a user may define his own mapping during the execution, and that might screw up the command.

6. The g’\” command essentially tells vim to go to the line marked ‘\”.

7. In addition, the whole command adds checks to make sure that the line ‘\” is within the limits of the first and last line. It is possible that non-vim commands modified the file so that the ‘\” line got deleted somehow.

More information on autocmd and BufReadPost can be found here.

More to come … 

We will try to address more sophisticated commands and manipulations  in future posts that can make the vim experience more enjoyable. The .vimrc file has been uploaded on my github account. Feel free to download, modify, use and provide your valuable feedback. We will be happy to address any special features you would like to see in your vim editor, and keep updating the .vimrc with each post.

Kindly drop your suggestions/questions from you at poppingthestack@gmail.com.