Practical Vim< /a> vit Practical Vim< /a> Note that the styling for a Visual selection is the... development I thought I knew Vim, but Practical" name="description"/>
Tải bản đầy đủ - 0 (trang)
Tip 37. Group Buffers into a Collection with the Argument List

Tip 37. Group Buffers into a Collection with the Argument List

Tải bản đầy đủ - 0trang

Group Buffers into a Collection with the Argument List

• 81

Like many features in Vim, the functionality of the argument list has been

enhanced, while the original name has stuck. We can change the contents

of the argument list at any time, which means that the :args listing doesn’t

necessarily reflect the values that were passed to the vim command when we

launched the editor. Don’t take the name literally! (Also, see ‘:compiler’ and

‘:make’ Are Not Just for Compiled Languages, on page 268.)

Populate the Argument List

When the :args Ex command is run without arguments, it prints the contents

of the argument list. We can also set the contents of the argument list using

this form (:h :args_f ):

:args {arglist}

The {arglist} can include filenames, wildcards, or even the output from a shell

command. To demonstrate, we’ll use the files/mvc directory, which you can find

in the source files that come distributed with this book. If you want to follow

along, switch to that directory and launch Vim:

$ cd code/files/mvc

$ vim

For an overview of the directory tree, refer to the code listing on page 94.

Specify Files by Name

The simplest way of populating the argument list is by specifying filenames

one by one:

:args index.html app.js


[index.html] app.js

This technique works fine if we only want to add a handful of buffers to our

set. It has the advantage that we can specify the order, but doing it by hand

can be laborious. If we want to add a lot of files to the argument list, we can

get the job done faster by using wildcards.

Specify Files by Glob

Wildcards are placeholders that can stand in for characters in the name of a

file or directory. The * symbol will match zero or more characters, but only

in the scope of the specified directory (:h wildcard ). The ** wildcard also

matches zero or more characters, but it can recurse downward into directories

below the specified directory (:h starstar-wildcard ).

report erratum • discuss

Chapter 6. Manage Multiple Files

• 82

We can combine these wildcards and use partial filenames or directories to

form patterns, also known as globs, that match the set of files we’re interested

in. This table shows a representative summary of some (but not all) of the

files in the files/mvc directory that are matched by the specified globs.


Files Matching the Expansion

:args *.*



:args **/*.js





:args **/*.*







Just as we can use more than one filename in the {arglist}, we can also supply

more than one glob. If we wanted to build an argument list containing all .js

and .css files but not other file types, we could use these globs:

:args **/*.js **/*.css

Specify Files by Backtick Expansion

As I wrote this book, I sometimes wanted to populate the argument list with

the chapters in the same order that they appear in the table of contents. For

this purpose, I maintained a plain-text file that contains one filename per

line. Here’s an excerpt from it:






I can populate the argument list from this file by running this:

:args `cat .chapters`

Vim executes the text inside the backtick characters in the shell, using the

output from the cat command as the argument for the :args command. Here,

we’ve used the cat command to get the contents of the .chapters file, but we

could use any command that’s available in the shell. This feature is not

available on all systems. See :h backtick-expansion for more details.

report erratum • discuss

Manage Hidden Files

• 83

Use the Argument List

The argument list is simpler to manage than the buffer list, making it the

ideal place to group our buffers into a collection. With the :args {arglist} command, we can clear the argument list and then repopulate it from scratch

with a single command. We can traverse the files in the argument list using

:next and :prev commands. Or we can use :argdo to execute the same command

on each buffer in the set.

The way I see it, the buffer list is like my desktop: it’s always messy. The

argument list is like a separate workspace that I always keep tidy, just in

case I need space to stretch out. We’ll see a few examples of how the argument

list can be used in other tips, such as Tip 69, on page 169, and Tip 96, on page


Tip 38

Manage Hidden Files

When a buffer has been modified, Vim gives it special treatment to ensure that

we don’t accidentally quit the editor without saving our changes. Find out how

to hide a modified buffer and how to handle hidden buffers when quitting Vim.

Run these commands in the shell to launch Vim:

$ cd code/files

$ ls



$ vim *.txt

2 files to edit

Let’s make a change to a.txt: we’ll just press Go to append a blank line at the

end of the buffer. Without saving the changes, let’s examine the buffer list:


1 %a + "a.txt"



line 1

line 0

The buffer representing a.txt is annotated with a + sign, which indicates that

it has been modified. If we were to save the file now, the contents of the buffer

would be written to disk and the + annotation would go away. But let’s not

save the buffer just yet. Instead, we’ll try to switch to the next buffer:


E37: No write since last change (add ! to override)

report erratum • discuss

Chapter 6. Manage Multiple Files

• 84

Vim raises an error message, reporting that the current buffer contains

unsaved changes. Let’s try following the advice in parentheses and add a

trailing bang symbol:



1 #h + "a.txt"

2 %a


line 1

line 1

The bang symbol forces Vim to switch buffers, even if our current buffer has

unsaved changes. When we run the :ls command now, b.txt is marked with

the letter a for active, while a.txt is marked with the letter h for hidden.

Handle Hidden Buffers on Quit

When a buffer is hidden, Vim lets us go about our business as usual. We can

open other buffers, change them, save them, and so on, all without consequences—that is, right up until we attempt to close our editing session. That’s

when Vim reminds us that we have unsaved changes in one of our buffers:


E37: No write since last change (add ! to override)

E162: No write since last change for buffer "a.txt"

Vim loads the first hidden buffer with modifications into the current window

so that we can decide what to do with it. If we want to keep the changes, we

can run :write to save the buffer to a file. Or if we want to discard the changes,

we can instead run :edit!, which rereads the file from disk, overwriting the

contents of the buffer. Having reconciled the contents of the buffer with the

file on disk, we can try the :quit command again.

If we have more than one hidden buffer with modifications, then Vim activates

the next unsaved buffer each time we enter the :quit command. Again, we

could :write or :edit! to keep or discard the changes. This cycle continues until

we make a decision for each of the hidden buffers with modifications. When

there are no more windows and no more hidden modified buffers, the :q

command closes Vim.

If we want to quit Vim without reviewing our unsaved changes, we can issue

the :qall! command. Or, if we want to write all modified buffers without

reviewing them one by one, we can use the :wall command. Table 11, Options

for Hidden Buffers on Quit, on page 85 summarizes our options.

Enable the ‘hidden’ Setting Before Running ‘:argdo’ or ‘:bufdo’

By default, Vim prevents us from abandoning a modified buffer. Whether we

use the :next!, :bnext!, :cnext!, or any similar command, if we omit the trailing

report erratum • discuss

Divide Your Workspace into Split Windows

• 85




Write the contents of the buffer to disk


Read the file from disk back into the buffer (that is, revert changes)


Close all windows, discarding changes without warning


Write all modified buffers to disk

Table 11—Options for Hidden Buffers on Quit

bang symbol, Vim will nag us with the “No write since last change” error

message. In most cases, this message is a useful reminder. But in one scenario

it becomes a nuisance.

Consider the :argdo and :bufdo commands. The :argdo {cmd} command works like







If our chosen {cmd} modifies the first buffer, the :next command will fail. Vim

won’t permit us to advance to the second item in the argument list until we

save the changes to the first item in the list. That’s not much use!

If we enable the ‘hidden’ setting (see :h 'hidden' ), then we can use the :next,

:bnext, :cnext (and so on) commands without a trailing bang. If the active buffer

is modified, Vim will automatically hide it when we navigate away from it.

The ‘hidden’ setting makes it possible to use :argdo and :bufdo to change a collection of buffers with a single command.

After running :argdo {cmd}, we’ll want to save the changes that were made to

each item in the argument list. We could do it one at a time by running :first

and then :wn, which would give us the opportunity to eyeball each file. Or if

we’re confident that everything is in order, we could run :argdo write (or :wall) to

save all buffers.

Tip 39

Divide Your Workspace into Split Windows

Vim allows us to view multiple buffers side by side by dividing our workspace

into split windows.

report erratum • discuss

Chapter 6. Manage Multiple Files

• 86

In Vim’s terminology, a window is a viewport onto a buffer (:h window ). We

can open multiple windows, each containing the same buffer, or we can load

different buffers into each window. Vim’s window management system is

flexible, allowing us to build a workspace tailored to the demands of our


Creating Split Windows

When Vim starts up, it contains a single window. We can divide this window

horizontally with the s command, which creates two windows of equal

height. Or we can use the v command to split the window vertically,

producing two windows of equal width. We can repeat these commands as

often as we like, splitting our workspace again and again in a process that

resembles cell division.

The following figure illustrates a few of the possible results. In each case, the

shaded rectangle represents the active window.



s v

s v

Each time we use the s and v commands, the two resulting split

windows will contain the same buffer as the original window that was divided.

Having the same buffer displayed in separate windows can be useful, especially if we’re working on a long file. For example, we could scroll in one of

the windows to show a part of the buffer that we want to refer to while making

changes to another part of the buffer in the other window.

report erratum • discuss

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tip 37. Group Buffers into a Collection with the Argument List

Tải bản đầy đủ ngay(0 tr)