How to close all files opened by different vim instances
howard Schwartz
> Because I want all of the vim instances save or simply quit without save.
I take it the client-server feature will not let you do this, because you can
only send commands to a single instance of vim (the server). And you want
multiple instances running simultaneously, right?
> What I need is: One vim server manages one or more vim instances which may
> be lunched within different windows/terminals.
You can still do this with vim's client-server, by launching each instance of
vim, as a server with a different name (e.g., --servername "some-unique-name" .
Then just send commands to each by servername. You would still have to
write a shell script to keep track of each server name and send commands to
all or some vim's, as you like.
Vim's client-server commands require either x-windows or ms-windows be running.
I assume you are running x-windows in a unix environment?
If you want to write a shell script to do vim saves, quits etc. you will need
vim autocommands to automatically send commands to vim once you bring them back
into the foreground. I have a way to do this, using a tiny file that each vim
reads, when it wakes up from the background. For example, in .vimrc you can
have have each vim execute a script like this, each time it starts:
enew
w c:/tmp/%.cmd
set nobufliste noswapfile
This creates a 0-width file for each vim instance.
Each tiny file, %.cmd is used to send commands to each instance of vim. Use
autocommands that sends commands to a vim each time the tiny file changes, like
this:
au fileChangedShell %
FileChangedShellPost % source c:\tmp\%.cmd
Now you can use the shell's foreground command to activate one or more vim's,
at which time they will execute the commands in the tiny files. Really, you can
use the same idea with --servername to name instances of vim, so they are easy
to keep track of.
BUT - why must you do all this with multiple instances? Why not run only one
instance of vim, with files in different windows, buffers, or tabs? Then
everything becomes MUCH easier, and you get the added benefit that you can
cut and paste and do global changes with the different files. Indeed,
most of us use --remote-tab-silent to run one, rather than many instances of
vim, when working with many files.
John Little
>You can still do this with vim's client-server, by launching each instance of
> vim, as a server with a different name (e.g., --servername "some-unique-name" .
themselves. Perhaps the OP's requirement would be met by something
like the following bash script:
for vim_instance in $(vim --serverlist); do
vim --servername $vim_instance --remote-send ":xall<cr>"
done
> BUT - why must you do all this with multiple instances? Why not run only one
> instance of vim, with files in different windows, buffers, or tabs?
and make use of one's window manager and one's skills with it.
There's already multiple windows with browser, xterms, file managers,
and so on; they can't go in a vim buffer, and vim has a limited
repertoire of window stuff, f.ex. it doesn't do a rotating cube.
Regards, John
howard Schwartz
> That's not necessary; the vim instances invent a unique name for
> themselves.
I think it is necessary since, in general, he wants to use one instance of vim
to ``manage' other instances, most of which run in the background. Thus, he
might want to write and quite instance2, but quit instance1 without writing,
etc. Practically speaking, each servername should use some memonic that
reminds the user of what file is being edited. That is why I suggested names
like %.cmd meaning, original-filename.cmd. It would be up to the user to pick
useful names.
howard Schwartz
> Well, multiple instances give more flexibility with window placement,
> and make use of one's window manager and one's skills with it.
> There's already multiple windows with browser, xterms, file managers,
> and so on.
Yes, I have a (blind) friend that prefers to manage multiple vim instances
from a shell so he can use his familiar unix command-line skills.
I have an unsubstantiaed belief that running multiple vim's with multiple
files, each writing viminfo, swap, backup, or session files, etc. -- now and
then, is asking for trouble. Indeed, my friend does seem to experience corrupt
viminfo files with some frequency. I wonder if using a single instance is less
prone to errors, corrupt files, etc?
> and vim has a limited repertoire of window stuff
I wonder what others think about this? Certainly, vim's text-based windows are
no match for graphical xterms. But the huge apparatus of multiple args,
buffers, file explorers, windows, and tabs, sessions, views - - is meant to
manage multiple files better inside vime, compared to outside - no? Otherwise,
why bother?
Certainly, inside vim one can more easily switch files/buffers, cut and paste
between files, do global changes and jumps, with many files, and so on. And
the shell command lets one leave vim easily and do shell or xterm work, as one
pleases.
I would think there would only be major advantages of multiple vims in
multiple windows, if vim were a graphical editor like wordpad.
ZyX
sent 01:28:56 22 March 2011, Tuesday
by howard Schwartz:
> I have an unsubstantiaed belief that running multiple vim's with multiple
> files, each writing viminfo, swap, backup, or session files, etc. -- now
> and then, is asking for trouble.
Swap files prevent you from editing one file in different vim sessions. Others
are fine, though without plugins like my `parinfo' (not posted to vim.org, is to
be rewritten, but works now: bitbucket.org/ZyX_I/parinfo), using viminfo is not
much fun: you will be constantly loosing parts of command-line history. Though I
never experienced corrupt viminfo. Other files (backup, sessions) are just fine
if you don't disable swap and don't edit one file in different vim instances.
> I wonder what others think about this? Certainly, vim's text-based windows
> are no match for graphical xterms. But the huge apparatus of multiple
> args, buffers, file explorers, windows, and tabs, sessions, views - - is
> meant to manage multiple files better inside vime, compared to outside -
> no? Otherwise, why bother?
When I want to edit a file I just type `vim file'. What I am supposed to do if I
want to keep one vim session? Don't suggest me switching to other terminal
window and typing anything there.
> Certainly, inside vim one can more easily switch files/buffers, cut and
> paste between files, do global changes and jumps, with many files, and so
> on.
I don't need to instantly paste anything between different projects, so `one vim
for one project + one vim for each non-project file' is fine. Though I keep
editing tests in a separate vim, not in that one that holds project. Setting vim
up to `one vim for one project' is easier than `one vim for all projects'.
Original message:
howard Schwartz
> When I want to edit a file I just type `vim file'. What I am supposed to do
if I
> want to keep one vim session? Don't suggest me switching to other terminal
> window and typing anything there.
I thought this would be obvious: If you work in unix/linux with x-windows,
then alias gvim thus:
alias gvim gvim --remote-tab-silent
Now `vim filename' will open a single instance of vim, with `filename' in one
tab. Switch files by simply clicking on one of the tabs.
If you work in a shell, with no graphic windows you can do something similar
by using autocommands and a tiny file to pass commands to one instance of vim.
If desired, I can specify how to do this.
> Setting vim up to `one vim for one project' is easier than `one vim for all
> projects.
Actually, session files and tab functionality were designed, for the most
part, to let users work on projects, using a single instance of vim. In
particular, each tab can correspond to a project, with settings saved and
sourced in a session file. Each tab can handle a collection of files in
several buffers and/or windows. You go to a project by selecting a tab. Then
you change from one file to another, using buffer commands or a buffer plugin.
You load a project into vim, by loading a particular session file.
I can understand being reluctant to give up one's private system, and learn
all these session, tab, buffer commands. But, they are there for those who
want them.
================================================
{ PLEASE CHANGE YOUR EMAIL CONTACT LIST! }
{ If I am listed as how...@sfo.com, change my }
{ address to howa...@gmail.com }
================================================
ZyX
sent 23:16:30 22 March 2011, Tuesday
by howard Schwartz:
> I thought this would be obvious: If you work in unix/linux with x-windows,
> then alias gvim thus:
>
> alias gvim gvim --remote-tab-silent
>
> Now `vim filename' will open a single instance of vim, with `filename' in
> one tab. Switch files by simply clicking on one of the tabs.
No, I can't:
1. gvim --remote-tab-silent is not going to bring gvim to current virtual
desktop.
2. With one gvim for all projects I am going to constantly taking gvim from one
virtual desktop to another and constantly switching tabs. I do not do this with
one-vim-for-one-project. I am not going to close anything because it saves time
when I switch from one project to another.
3. I do use some advanced zsh features which help me with writing VCS commands
and doing other stuff like renaming (or massive renaming) files. Gvim is going
to be another window in desktop's window list and this is not convenient.
> Actually, session files and tab functionality were designed, for the most
> part, to let users work on projects, using a single instance of vim.
Can you prove that? Tabs are for saving window layouts for different tasks (for
example, see last paragraph in `:h tab-page-intro') for one vim session.
Sessions are to `quickly switch between different projects', here you are right.
But there is a thing to consider: session file saves the whole vim session, not
only tab, so it was not intended to use one-vim-for-all-projects, but one-vim-
for-one-project.
> Each tab can handle a collection of files in
> several buffers and/or windows.
You misunderstood what tabs are:
1. Tabs do not handle buffers, they only make one able to have multiple window
layouts.
2. There are no binds between buffers and windows or buffers and tabs, so you
may view any buffer in any window located in any tab.
> Then you change from one file to another, using buffer commands or a
> buffer plugin.
Buffer list is not attached to any tab, so I will get a lot more alternatives
for `:buffer' command if I do this.
> You load a project into vim, by loading a particular
> session file.
Effectively wiping out everything that I am doing currently.
It looks like you have actually never worked with several projects
simultaneously in one vim, or have brought a habit (probably from windows) to
close tasks that you don't need just now. There is more effective habit: if you
don't need an application just now, but will need it later, then leave it on one
virtual desktop and switch to another. It is not machine-effective though: for
example, I have now above two hundred tabs in Opera which saves my time, but
consumes lots of memory (30% of 4 GiB: 1,2 GiB for a single application. Next
memory-consuming application takes only 3%).
Original message:
Paul
> You wrote:
>
>> Because I want all of the vim instances save or simply quit without save.
How about vim supporting signals, eg. have SIGQUIT invoke a nice :qa! shutdown? I'm not sure if SIGQUIT would be appropriate.
--
.