I have problems with automated splits and folding. In my ~/.gvimrc file, at the very end, I have the command vsplit, so that when I'm using gvim as opposed to vim, it opens with two panes. The problem occurs when I open a file that would normally be folded via the command line, as in gvim example.cpp. This opens the example.cpp file in two panes; however, the first pane is folded while the second is not. It's a minor annoyance, but I wondered if anyone had a suggestion to get the second (or all) buffers to be folded when the window first appears.
If it makes a difference, I use set foldmethod=indent in my ~/.vimrc file, and my version is 7.1.
this is very strange, it also happens here, I'm guessing there must be a bug because other settings are valid on the second pane, except for the 'foldmethod' setting.
Anyway, I found an easy workaround. I have this at the end of my .vimrc and what you are looking for now works on my vim:
set foldmethod=indent
set sw=2
set tw=2
vsplit +edit
Now when I open a file, the window is split in two and both are folded correctly.
The workaround is executing the ex command :edit on the second pane so that the missing settings (although it seems that only 'foldmethod' is missing) are reloaded. That's what the +edit after the vsplit does.
Hope this resolves your problem.
Related
I have a very weird problem which did not exist in my environment before but now happened. When editing files, I'm used to doing this way:
gvim . #open current directory browsing
scroll up/down to select file, enter then edit.
ctrl-6 #back to previous directory
However one day I found the step3 was failed, it said "No alternate file".
My .vimrc file only contains:
colorscheme darkblue
set number
set autoindent
set nowrap
set ignorecase
set cursorline
I tried to clean all content in .cshrc but the same.
Can anyone tell me what's wrong with my gvim ?
Thanks in advance.
This looks to be a change in behavior introduced in Vim 7.4. The netrw view is no longer stored as an alternate file. See this discussion.
The Vim maintainers seemed split on what the correct behavior should be, but Bram himself offered up this advice with a mapping:
I do realize that editing the directory of the current file is
something I often do, but I never bothered to set up a mapping for
it. Typing ":e %:h" is not too difficult, but CTRL-O to jump back to
the netrw %directory view was easier.
I now added a mapping:
map ,d :e %:h<CR>
Let's see if I can get used to that.
Another related discussion can be found here.
You are likely using netrw to edit a directory. This is the equivalent of :Explore. Sadly netrw has a bad habit of not maintaining the alternative buffer, #. You maybe able to upgrade netrw or use :Rexplore (:Rex for short) to resume exploring.
Another option is to just use :e with wildcards and tab completion to explore files. Use <c-d> to list out completions as well.
I'm having a weird issue with vim on Ubuntu. I've been using it for the last few weeks, trying to learn, on Windows and it behaves differently now that I'm using it on Linux.
I noticed that while in insert mode pressing backspace will delete text just like any other editor on Windows, but on Linux the text is "deleted" yet it stays there until I press ESC or write over it.
I was trying to fix this but I'm confused as to whether this is intended behaviour or not. It happens in gvim too.
The reason of this question is this, however:
I deleted my .vimrc file to see if any of my config was at fault and it fixed it. Backspace was now back to its regular self.
But then I tried creating an empty .vimrc file and that made it go back to the delayed delete. It's empty. Why the hell?
So I have no idea what's causing this. Hope my question makes sense my English ain't the best. Thanks.
Alright so looking at :h compatible I found this:
"When a |vimrc| or |gvimrc| file is found while Vim is starting up,
this option is switched off, and all options that have not been
modified will be set to the Vim defaults. Effectively, this means
that when a |vimrc| or |gvimrc| file exists, Vim will use the Vim
defaults, otherwise it will use the Vi defaults. (Note: This doesn't
happen for the system-wide vimrc or gvimrc file, nor for a file given
with the |-u| argument). Also see |compatible-default| and
|posix-compliance|."
So if I'm getting this right, running Vim with a .vimrc file should automatically set nocompatible and running it without one should set compatible... ? Whatever the case, I tried checking with :verbose set compatible? and it always says nocompatible is on so the -N flag shouldn't do anything... Yet it fixes the issue.
Without a vimrc Vim will load /usr/share/vim/vim80/defaults.vim (depending on your vim version). In this file the bs/backspace parameter is set to 2, or actually it is indent,eol,start which is the same as 2 (see :h bs)
Now if you create an empty .vimrc, defaults.vim will not be loaded, so your bs will possibly be 0.
This behaviour is described in :h defaults.vim
So to solve your problem, just put set bs=2 in your .vimrc
Alright I fixed it.
Running vim with the -N command makes it work properly. I'm not sure why but that's what's happening.
Sometimes when I'm working on a project I want to play around with some data. Often times the data is on one line and is huge (>25k characters). I understand I could set nowrap and have this line just run off the screen, but I tend to like set wrap for other reasons. So, as a workaround I want to hide these long lines in a marker fold (e.g. {{{ long line }}}). This works fine but I run into a problem with synmaxcol for some reason. If the folded line exceeds synmaxcol then when I open the file, the syntax highlighting runs over. For example:
However, as soon as I open the fold the syntax corrects itself:
Having to open the fold every time is annoying though. As you can see in this example the line is not actually all that long -- it just exceeds synmaxcol. Since synmaxcol is exceeded at a "string" element, the rest of the file is highlighted as a string (so nothing but a singular double quote will stop it).
Why is this happening and how can I fix it? I've tried this with different syntax files and filetypes and it still occurs. I've also tried it with no plugins, a minimal vimrc (containing only syn on) and a modeline to set fdm=marker:synmaxcol=60 and it still happens.
You can manually enter :syntax sync fromstart to force Vim to rescan the syntax from the beginning of the opened file.
I would suggest defining a hotkey for convenience:
noremap <F5> <Esc>:syntax sync fromstart<CR>
inoremap <F5> <C-o>:syntax sync fromstart<CR>
Now you can press F5 to clean up most syntax highlighting problems.
Also, have a look at Vim's fixing syntax highlighting - wiki page
Moreover reading :help :syn-sync-first might shed some more light on the issue.
UPDATE:
I was able to reproduce this behavior on my machine (I'm running Vim 7.3.429).
However, when I wrapped the fold markers {{{ and }}} in block comments, vim correctly rendered the syntax. You can create appropriately wrapped fold-markers using the zf command. See Vim tips: Folding fun.
Normally Vim picks the correct blockcomment string based on the currently active syntax. However, my Vim is pretty vanilla and didn't recognize Ruby syntax. I could specify autocmd FileType ruby set commentstring==begin%s=end in my .vimrc file to set the proper block comment. See :fold-create-marker for more details.
Another solution is to set synmaxcol=0, which will effectively set it to infinity. This causes Vim to check the syntax of the entire line, no matter how long it is. However, I'm not sure what kind of performance penalty you'll have to pay for that.
I've set this on my .vimrc:
let g:clang_snippets=1
let g:clang_snippets_engine='clang_complete'
let g:clang_conceal_snippets=1
set conceallevel=2 concealcursor=inv
I don't know how conceal is expected to work, maybe the clang_complete's docs should have a tip for a specific setting to hide the snippets adorns.
How do I hide it? I'm using MacVim built with +conceal, but it's not working. This is my messy .vimrc by now.
NOTE:
I'm sticking with g:clang_snippets_engine='clang_complete' because it seems to be more smart than the snipMate parameter completion, switching to NORMAL mode is a wiser choice to navigate between parameters since I can use SuperTab completion for params in INSERT mode while being able to navigate through them with the same tab at NORMAL mode. snipMate engine was acting weird to me sometimes too, sometimes it switched to a parameter after a completion, sometimes not.
Also, I'm missing a final tab to go after the last parameter, right after the function call (snipMate does that), so I can just insert ; and hit Enter.
Disclaimer: This question is related with the issue at https://github.com/Rip-Rip/clang_complete/issues/176.
EDIT:
My problem was with this line at my .vimrc:
au BufNewFile,BufRead *.cpp set syntax=cpp11
I'm using C++11 Syntax Support and #xaizek has discovered and pointed it out as the problem in the comments bellow in the accepted response, it seems the root cause is the use of the syntax clear command in it.
According to :help 'concealcursor':
Sets the modes in which text in the cursor line can also be concealed.
When the current mode is listed then concealing happens just like in
other lines.
n Normal mode
v Visual mode
i Insert mode
c Command line editing, for 'incsearch'
So with concealcursor=iv you asked Vim to hide concealed text in insert and visual modes, but show it in normal mode. So just do:
:set concealcursor=inv
What does a horizontal line in vim mean? While editing a remote file I see a horizontal line in the current line.
I don't see it while editing local files
Edit:
cursorline is not shown until I save the file(:w). When I type :w and enter password, cursorline appears. Why does it have such a behavior? When I edit file in remote machine cursorline is turned off and is not shown.
As others have answered, the effect is probably being caused by the cursorline option.
You can track down what is script made the most recent change to an option by running the command set optname? under the verbose command:
:verbose set cursorline?
You will probably just find that the Netrw plugin set it; Netrw handles local directory browsing and remote directory/file access like your scp:// example. Netrw adjusts cursorline (and cursorcolumn) for its own purposes (e.g. directory listings), but it tries to restore the value to the “user value”. Unfortunately, its idea of the “user value” is captured when part of the Netrw code loads and is not updated afterwards.
My guess is that, somehow (via some other plugin, or bit of configuration), cursorline is set when Netrw loads (and captures its value), but it is later reset by the time you start editing the first file. Then, when you later save the file (:w), Netrw restores the “captured” value. Unfortunately, there does not appear to be any good way to update this “captured” value of the cursorline option (there is no “external” access to the script variable it uses, and it does not “recapture” if you manually reload the file).
What you can do, however, is explicitly load the bit of Netrw that “captures” cursorline when your desired value is active. You could do that with the following two commands early in your ~/.vimrc (possibly at the very top, if necessary—it needs to be before the first time autoload/netrw.vim would ever be used):
set nocursorline
runtime autoload/netrw.vim " will 'capture' cursorline and cursorcolumn values
Netrw will still set/reset cursorline (and cursorcolumn), but as long as the value you normally want matches the value that is active right before Netrw is loaded, then you will not notice it.
I don't quite know the simplest solution to get get netrw to really capture the right value, but at very least (since for me, nocul is right,) adding:
let g:netrw_cursorline=0
To the end of my ~/.vimrc seems to have fixed the problem for me. Hope this helps someone!
It's the cursorLine. Its appearance is defined in your colorscheme. The one on the remote machine is probably different than yours or there's a mismatch between your client/server's $TERM.
Yup, ":set cursorline" or ":set nocursorline" to turn the line on or off.
The command "vim scp://...." copies the remote file onto your local machine (i.e. machine where the "vim" process runs), then opens the file in "vim" for you to edit, then, if you have modified the file, copies the file back onto the remote system. As such, syntax highlighting etc. is determined only by "vim" on your local machine.
Files with the same syntax type (":se syn" to show current syntax highlighting scheme) are highlighted the same way. Do the files, in which you see the difference, have the same syntax type?
Version 142 of netrw.vim has fixed this bug, at least for me (vim 7.3, old netrw.vim version was 140, running under cygwin).
You can get the latest version here: http://www.vim.org/scripts/script.php?script_id=1075