If I quit a buffer how do I keep the one I was last editing displayed (when using NERDTree)??
Rick R
I have NERDTree open on the left.
I have several buffers open (only one visible in the main view... call it "buffer 1" )
I now go to NERDTree and select another file that I just want to look at really quick or copy something from. So I open that file from NERDTree and buffer1 is correctly hidden and I'm now looking at the buffer I just opened (call it buffer 2)
I now want to completely quit this buffer 2 and go back to editing buffer 1, but when I do :q on buffer 2 I end up looking at just one large NERDTree and I have to redisplay buffer1.
That's a bit annoying so there must be something I'm doing wrong?
--
Rick R
John Beckett
> I have NERDTree open on the left.
>
> I have several buffers open (only one visible in the main
> view... call it "buffer 1" )
>
> I now go to NERDTree and select another file that I just want
> to look at really quick or copy something from. So I open
> that file from NERDTree and buffer1 is correctly hidden and
> I'm now looking at the buffer I just opened (call it buffer 2)
>
> I now want to completely quit this buffer 2 and go back to
> editing buffer 1, but when I do :q on buffer 2 I end up
> looking at just one large NERDTree and I have to redisplay buffer1.
Ctrl-^ (probably Ctrl + the 6 key) to switch back to buffer1.
See this for how to close a buffer AND keep the window:
http://vim.wikia.com/wiki/Deleting_a_buffer_without_closing_the_window
See this for ideas on switching between buffers:
http://vim.wikia.com/wiki/Easier_buffer_switching
John
Rick R
I do not use Nerdtree, but it sounds like you should be typing
Ctrl-^ (probably Ctrl + the 6 key) to switch back to buffer1.
Thanks John. I ended up going with this script http://www.vim.org/scripts/script.php?script_id=1147 (mentioned as link off the wiki site you posted.)
The problem with just Ctrl-^ (as far as I can tell) is that it doesn't really delete the buffer. I want the buffer completely gone, but wanted the previous buffer I was working on to then become visible. Using the kill buffer plugin did the trick.
(side note: buffers still confuse the heck out of me even after reading this faq http://vim.wikia.com/wiki/Vim_buffer_FAQ Seems like 99% of typical editor users would simply want buffers to act like typical tabs in other editors.)
Tony Mechelynck
> You received this message from the "vim_use" maillist.
> For more information, visit http://www.vim.org/maillist.php
Don't :q[uit] the buffer you're viewing now unless you want to close its
window.
Ctrl-^ is equivalent to :e # which points in the direction you want: #
represents the "alternate file", i.e., usually the file you just left,
the way % represents the current file. So basically, with :e # (or
Ctrl-^) # becomes % and vice-versa. So, to go back to the previous
editfile and then remove the file you shortly viewed from the buffer
list, use
:e #
:bdel #
Note that here the two # signs represents different files, because of
the way :e # swaps # and %
Of course, the above assumes that either you didn't modify the "shortly
viewed file", or you saved the changes before going back, or you have
'autowriteall' set ('autowrite' is not enough in this case). It also
assumes that that buffer is not also open in another split-window (if it
is, the :bdel will close that other window).
If you have 'hidden' set, the :e[dit] will succeed, but I'm not sure
what will happen with the :bd[elete] -- I /think/ that it will keep the
buffer in memory, but "unlisted", i.e. shown by :ls! (with bang) but not
by :ls (without bang), and in any case still unsaved, which IMHO is
something dangerous to have -- you could just too easily forget about
this "modified unlisted buffer" in this case.
If you modified the "shortly viewed buffer" and didn't save it, and have
neither 'hidden' nor 'autowriteall' set, then of course the above pair
of commands will fail -- unless (of course) you cancel the changes by
adding an exclamation mark after :e
Now about your side note:
-1- A buffer is an area of memory used by Vim to keep one file and some
data that goes with it (such as buffer-local options, buffer-local
variables, buffer-local mappings, etc.). There may or may not be an
actual disk file associated with that buffer: usually there is, but, for
instance, not (yet) with a [No Name] buffer that you just created, not
with a netrw directory view, and, I think, not with the NerdTree view
(which I don't use).
-2- A window is a viewport on a buffer. Each buffer may be displayed in
zero or more windows. Each window has its own cursor position, begin and
end lines, etc., but any changes you make in one window are reflected in
all other windows (if any) that display the same buffer. The current
window is at least one line high (not counting the statusline) so you
can see where you work; other windows may have zero or more lines (plus
one statusline) but no window has ever fewer than 'winminheight' lines
(still not counting the statusline). (See the caveat in �4 below about
the meanings of the word "window".)
-3- In Vim 7, a tabpage is the set of windows you see or hide together.
You can have one or more tabpages, each of them with one or more windows
in it. By default, all your tabs (one per tabpage) are shown near the
top of the Vim screen if you have two of them or more, but you may
change the 'showtabline' option to always or never display them if you
want. When a buffer is displayed in several windows, these windows may
or may not be in the same tabpage, and if they aren't you can have any
number (zero or more) of each of those "windows on a common buffer" in
each of your tabpages in any combination.
-4- With Vim, a single instance of the executable (with a single PID)
cannot handle more than one of what is called a "screen" in Vim
terminology and a "window" in MS-Windows, X-Windows or Macintosh
terminology. (For Console Vim, the "Vim screen" also corresponds to what
the OS would call "the display" of a console or a terminal.) I know this
is confusing but that's how it is. Sometimes "Vim language" and "OS
language" feel like related but different languages, and there are
"false friends" between them. You /can/ have "several Vims" running in
parallel but they are different processes and any communication between
them is via the clipboard (if available and compiled-in), the X
selection (if running on X), the disk, or the |client-server| feature
(if compiled-in).
Most of the above describes the behaviour of Vim executables compiled
with the +windows feature. Without that feature, you can still have any
number of buffers (memory permitting) but you can never see more than
one of them at a time (so that for instance, in that case, viewing the
help hides the buffer you were editing).
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
238. You think faxes are old-fashioned.
Christian Brabandt
On Fr, 08 Jan 2010, Tony Mechelynck wrote:
> the way % represents the current file. So basically, with :e # (or
> Ctrl-^) # becomes % and vice-versa. So, to go back to the previous
> editfile and then remove the file you shortly viewed from the buffer
> list, use
>
> :e #
> :bdel #
>
> Note that here the two # signs represents different files, because of
> the way :e # swaps # and %
Note that if you are issuing :e # again, you can reopen that buffer. If
you use :bw # the alternate file name will be undefined and :e # will
result in an error.
> If you have 'hidden' set, the :e[dit] will succeed, but I'm not sure
> what will happen with the :bd[elete] -- I /think/ that it will keep the
> buffer in memory, but "unlisted", i.e. shown by :ls! (with bang) but not
> by :ls (without bang), and in any case still unsaved, which IMHO is
> something dangerous to have -- you could just too easily forget about
> this "modified unlisted buffer" in this case.
no, :bd will complain and not succeed, while :bd! will silently abort
your changes. I don't see a problem with that.
regards,
Christian
--
hundred-and-one symptoms of being an internet addict:
57. You begin to wonder how on earth your service provider is allowed to call
200 hours per month "unlimited."
Ben Fritz
On Dec 3 2009, 8:42 am, Rick R <ric...@gmail.com> wrote:
> (side note: buffers still confuse the heck out of me even after reading this
> faq http://vim.wikia.com/wiki/Vim_buffer_FAQ Seems like 99% of typical
> editor users would simply want buffers to act like typical tabs in other
> editors.)
Tony gave you a good explanation, here's another very similar one:
http://vim.pastey.net/115548
You might also be interested in: http://vim.wikia.com/wiki/Introduction_to_using_tab_pages
and http://vim.wikia.com/wiki/Category:Tabs
As for "99% of typical editor users" wanting buffers to act like the
limited, featureless tabs of other editors, I think that statement is
false for most Vim users. A buffer is different than a tab, and a Vim
tab page different than the tabs of other editors, all by design. A
buffer is a much older concept than tab pages and was the original
method of editing multiple files in Vim, emacs, and other editors.
Buffers, windows, and tab pages in Vim are all different ways to
organize your work that can interact in interesting ways.
That being said...there are ways to get close to what you say you
want. See the links in the pages above.