On 03/12/09 15:42, Rick R wrote:
On Wed, Dec 2, 2009 at 6:28 PM, John Beckett <[email protected]
<mailto:[email protected]>> wrote:
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.)
--
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.
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
