I currently have my terminal running in full screen, with three nice large vertical splits in it. The leftmost is running NERDTree, so I don't really need the full height. I'd like to split that column horizontally and put help in the new frame, but when I :help, it creates a large horizontal split across the entire screen. I know I can technically set this up the way I want before I make my vertical splits, but I tend to not think about opening help until I'm well into my workflow.
So is it possible to have help only split the existing window, or open into the current buffer?
The answer (works for me) is:
:above help
Note that it already has the same behaviour if you were in the rightmost column.
See also :help vert, :help above etc. for all kinds of variations (rightbelow etc.)
Related
Whenever I create a vertical split in VIM using the :vs command, the newly created panel is a duplicate of the first, and it updates both panels in real-time as I type.
How can I turn this behaviour off and make it revert to opening a second independent panel?
That's exactly what's supposed to happen. If you don't want what a command does, use another command that does what you want.
From :help :vsplit:
Like :split, but split vertically.
From :help :split:
Split current window in two. The result is two viewports on the same file.
If you scroll down a bit you can find :help :vnew:
Like :new, but split vertically.
Which leads you to :help :new:
Create a new window and start editing an empty file in it.
So… what you want is :vnew.
I would like vim to scroll horizontally like nano does, by scrolling only the current line, not the whole screen.
I tried playing with nowrap and scrolloff settings, without success.
Here are some screenshots (with the cursor at the end of a long line) to explain myself.
Nano:
Vim (wrap):
Vim (nowrap):
Thanks!
No, Vim cannot do this, and I think it would be hard to implement this in a way that isn't inconsistent or confusing to the user. There would need to be an indicator (like with side scrolling) that only the current line is scrolled. Also in Vim, there are several commands (like j / k and i_CTRL-Y / i_CTRL-E) that refer to the same column in above / below lines. A partially scrolled view state would make it difficult to use those.
That said, you can sort-of achieve this with a hack: The foldtext of folded lines does not scroll horizontally. So if you fold each individual line (other than the current one) via a custom 'foldexpr', set the fold text to be the line's text, and automatically close all surrounding folds, you'll get this. However, as you'll lose syntax highlighting and "normal" folding, this is more for demonstration than an actual solution.
Am used to IDE style tab'd panels and am hitting some arggghh inducing scenarios with vim when trying to replicate this functionality using buffers and splits.
I have the following relevant .vimrc settings:
set hidden
set switchbuf=useopen,usetab
Now, let's say I open up 4 buffers, split vertically and then horizontally so that 1 buffer displays on the left and 2 buffers display stacked on the right. The 4th buffer is hidden (opened on the left split).
With the cursor in the left split, using :bnext and :bprevious rotates through all buffers in the left split; that's not desirable as I really have no use for seeing the same file contents in 2 different splits (is there a way to opt-in to the vim cloned buffer affect?). Using :sbnext and :sbprevious works great for visible buffers, but as soon as a hidden buffer is encountered then it opens up in a new split thus wreaking havoc on my layout. The problem gets worse when working with 10+ buffers.
Ideally I'd like to rotate through all buffers visible and hidden within a given split (i.e. where the buffers were opened).
Suggestions appreciated.
p.s. am trying out vim ctrl-space plugin now, quite good but does not address above issue.
Thanks
Why rotate through the buffers when you can go directly to the one you want via :buffer command?
:b foo
:b take either a buffer number or a partial filename (with globs too!). I recommend the partial filename approach. You can also use tab completion to distinguish between ambiguous partial filenames.
You can use :sbuffer (:sb for short) the same way but to open a split instead.
For more help see:
:h :b
:h :sb
The basic navigation unit is the buffer. Windows and tab pages are abstractions built on top of buffers that introduce their own good and bad idiosyncrasies and, most of the time, don't play well with traditional buffers.
You are having troubles because you are trying to apply buffer commands to a window-centered workflow.
As soon as you split your workspace in more than one window you are bound to use window commands for navigation and tab-navigation becomes your standard as soon as you use tab pages. As you noticed, not only is it hard (impossible, AFAIK) to make buffer-navigation window/tab-aware but the alternative techniques actually lack quite a bit in terms of power.
The 4th buffer is hidden (opened on the left split).
That's your first problem: that 4th buffer is hidden and thus transient. It is not opened in any window and could be displayed in any window. You can choose to display a specific buffer in a specific window but you can't really "pin" it to that window.
With the cursor in the left split, using :bnext and :bprevious rotates through all buffers in the left split; that's not desirable as I really have no use for seeing the same file contents in 2 different splits (is there a way to opt-in to the vim cloned buffer affect?).
Again, you are using buffer commands that don't care at all about windows and tab pages.
Using :sbnext and :sbprevious works great for visible buffers, but as soon as a hidden buffer is encountered then it opens up in a new split thus wreaking havoc on my layout.
Again, the wrong tool for the job.
It is possible to keep as many window-local argument lists as you have windows and use those lists with :next and :previous, though, but that would require quite a bit of focus and forethinking. Maybe there's a plugin for that? Anyway:
Create your layout:
:vs|sp
Go back to the large window on the left:
<C-w>w
Put two files in the local argument list:
:arglocal aaa.txt bbb.txt
Move to the next window, edit your local argument list and repeat:
<C-w>w
:arglocal ccc.txt ddd.txt
<C-w>w
:arglocal eee.txt fff.txt
You can now do :next and :previous to switch arguments or <C-^> to switch to the alternate file.
Note that, while you were able to "force" somehow your buffers to specific windows, you are now seriously limited in your ability to navigate around and you now have to deal with a multi-dimensional construction that's rather fragile and requires to too many braincells.
You should consider working with Vim and not against it by using straight buffers as much as possible.
I'm using vim dwm plugin, and it is working very well for my workflow. I'm used to open a lot of buffers in the same window. With this plugin I can manage all of them with easy. I'm using vim-ctrlspace plugin too, and this two plugins are wonderful working together. Well, that's it. I hope this help!
Ok so first off, this is NOT the answer I'm looking for:
autocmd VimResized * :wincmd =
Let me explain: Let's assume I have 2 vertically split windows, one at 30% size and one at 70% size. When I resize my window, I want that percentage to stay the same. Without this command, the split on the right slowly collapses so that you eventually can't see anything in the window. With the command above, once you start resizing the window, the window sizes immediately change to 50%/50%.
I work with a lot of splits (vertical and horizontal) and I don't want the command above to just make everything equal, but at the same time I do want them to resize, just PROPORTIONALLY to the window... I want the percentage height/width of all splits in the window to stay the same when the window is resized. Ideas?
I've attempted to implement this in my ProportionalResize plugin, following basically the approach outlined in romainl's answer. You can wrap your resize commands in a :ProportionalResize wrapper; the plugin also hooks into various events to allow automatic adaptation when the Vim window is resized e.g. with the mouse.
if you are asking a "vim - official" way to do that, answer is NO. (Vim 7.3)
to prove it:
open vim, type :h todo<Enter>then type /proportionally[Enter] you will see:
- When resizing the whole Vim window, the windows inside should be resized
proportionally (Webb).
so it is in vim's todo list. In this window type gg, you can see the leading minus "-" means Priority classification:
- unclassified
If you want to do it, you could write a function by yourself, on VimResized event, resize all windows based on your logic.
You could create a function that logs window sizes and bind them to a bunch of events like WinEnter/WinLeave and another one bound to VimResized that uses those values to resize the windows.
This doesn't sound like a trivial task.
Or even like a good idea.
I used ctrl-6 to jump between two files and compare these two files page by page, But each time when I switch back, the page content is changed. That is, a new page with previous cursor line in the middle of screen now is shown instead.
Is there a way to keep the page position in the screen unchanged when I switched back.
Thanks a lot!
May I suggest using tabs (C-PgUp and C-PgDn to switch)?
You can always start by doing C-wsC-^C-wT
Otherwise see this odler answer of mine for hints on restoring cursor positions:
After a :windo, how do I get the cursor back where it was?
Vim buffer position change on window split (annoyance)
This might not be what you're looking for, but just in case: For a different approach to the task you're doing (visually comparing two files), see :help scrollbind. You would do :set scrollbind in two side-by-side windows and open one file in each, then scroll through them together, linked. See also vimdiff for even more functionality.