Can't seem to find any reason for this, but I have been using Ycm, syntastic, and all the lh- plugins with vim for a while now. In the case of lh-brackets, I used to have a problem with it generating "«»" every time it 'automatically' generated the other bracket, paren, quote, etc. But it was only happening in .vim files, so i turned it off for vim files in my vimrc. Now nothing has changed, no new scripts installed, and all of the sudden, this happens with ALL files (cpp, h, pl, py, etc). Like i said, not using heavy customization, and everything is default except the disabling of lh-brackets when editing vim files, but that has now become a hotkey since i cant use it anywhere.
My Question is this: does anyone have this or similar problem with lh-brackets, and if so, any idea how to fix it, or is there some setting I am missing?
My first thoughts are to go though and check any updated vim scripts (this just happened a day ago) that could have been updated when doing an apt-get upgrade (like debian.vim) but after that I've got nothing...
The placeholders characters can be jumped to (:h <Plug>MarkersJumpF -> <C-J> with vim, <m-ins> with gvim). That's their purpose.
If you have installed lh-cpp, see :h lh-cpp-first-steps, you'll find a quick guide to my C++ suite (and lh-brackets incidentally).
EDIT: The plugin was badly designed. I've patched the plugin to rely on g:usemarks in order to fix the ergonomic of plugin .
In the (now-) past, if you wanted to set b:usemarks to 0, you'd have needed to add an autocommand that'd set b:usemarks to 0 in all new buffers.
Now, (lh-brackets v2.2.0), if you want to always disable the placeholders/marker characters, you need to set g:usemarks to 0, not b:usemarks. Buffer-local variables are meant to be set from ftplugins, or tree/project-local plugins which are supported thanks to plugins like local_vimrc.
And as romainl has pointed out, don't hesitate to use the bug trackers, or even to contact me.
hmm found it:
:let b:usemarks=0
now needs to be set, apparently that was a marker for integration to another plugin, though i dont use it.
Related
I installed a vim 8.1 on the cluster I am using in my home folder. I also installed a number of plugins including YouCompleteMe. I then made an alias so that I can open the vim easier.
However, I found that my vim cannot delete letters very well. When I am writing I can delete what I just typed. But if I move the cursor to other places, then it cannot delete letters at all, unless I type in something at first.
I am using a Scientific Linux system developed by the Fermi Lab.
How can I solve this problem?
Thanks
This sounds like the default configuration of the :help 'backspace' option. If this doesn't contain start, you cannot remove characters over the start of insertion by pressing Backspace, only what got inserted before. Removal of characters via the x or d commands (:help deleting) should always work - anywhere. Else, you have a serious misconfiguration should inspect your ~/.vimrc and re-add plugins one by one.
If you're new to Vim (and using backspace for deletion in insert mode is a typical approach of people used to other, modeless editors), you should spend 30 minutes on the vimtutor that comes with it (see :help vimtutor). Then, there are several good resources, cheatsheets, and vi / Vim tutorials out there on the net. http://vimcasts.org/ has several short entertaining episodes that go beyond the basics.
Your problem could be fixed by putting
set backspace=indent,eol,start
into your ~/.vimrc. Also have a look at :help defaults.vim; by including that instead, you'll get other goodies and recommended settings as well! (The reason for the odd defaults is backwards compatibility.)
I uninstalled vim74 and compiled vim81 and installed it. However I found it strange, comparing to vim74. When there's no .vimrc file under HOME dir, I open a c++ file and syntax highlight is working and I can use Backspace to delete letters. However when I add a .vimrc under HOME dir and just put set number into it, when the c++ source file is opened, no highlight, and Backspace not working. Why is that ? I used to add some configurations in .vimrc under vim74 before, and this situation never happens.
After complaints that Vim in its default configuration is hard to use (especially for beginners), it was decided to enable a default configuration if the user hasn't created his own ~/.vimrc (yet). This was introduced with Vim 8.0, and explains what you're seeing (namely: syntax highlighting and sensible backspace behavior). Read more about the details at :help defaults.vim.
The help also has instructions how to keep the defaults when adding your own ~/.vimrc configuration:
If you create your own .vimrc, it is recommended to add these lines somewhere
near the top:
unlet! skip_defaults_vim
source $VIMRUNTIME/defaults.vim
Then Vim works like before you had a .vimrc.
Tip: Don't go all crazy with adding various snippets (especially not those you don't fully understand) and plugins to your ~/.vimrc, even though the Internet is full of them. Rather, build it up gradually, depending on needs, and back up your understanding with careful studying of the excellent :help. Also, avoid pre-packaged Vim distributions; they're even worse.
I’m starting to learn about creating my own .vimrc file and I keep noticing features that are missing with my custom version that were present in the default setup.
I was wondering if it is possible to view the default settings, so I can compare them to my own and look up all the standard inclusions I don't know to learn more about them.
I searched and couldn’t find an answer online, and if the reason why there isn’t one is that the answer to this question is glaringly obvious, I’m really sorry; I’m still a bit of a noob :p
No worries, it’s a perfectly valid question. Unfortunately, the answer is a bit complicated. First of all, Vim has certain defaults that are documented in the built-in help system.
Some of them are only used when Vi compatibility mode is disabled, and that’s the first customisation most people make:
:set nocompatible
On top of that, many distributions provide their own custom config, for example Debian/Ubuntu comes with /etc/vim/vimrc. To makes things even more confusing, Vim 8 comes with a sane configuration (called default.vim) that only gets applied when ~/.vimrc is not found. Not to mention that NeoVim comes with its own set of defaults.
In practice, I suggest to explicitly set any options you care about to make sure your config is portable between systems and versions of Vim. To see the current value of a given option, use a question mark:
:set showcmd?
To learn more about a given option (including the default value), use Vim’s comprehensive help system:
:help showcmd
Finally, you might want to check my annotated .vimrc for some inspiration, and there is also the vim-sensible plugin that provides some sane defaults most people would agree to.
The easiest way to see “vanilla” Vim options is to start it using:
$ vim -u NONE -N
It will start Vim without any of your customizations or plugins, but still in ‘nocompatible’ mode (i.e., basically, running full-fledged Vim, instead of its stripped down version emulating Vi).
Then, you can execute the following commands:
:set all
:map
:command
:let
:function
:autocmd
to see all options, mappings, commands, variables, functions, and auto-commands, respectively, that are currently in effect. (I cannot promise I haven’t forgotten a customization category.)
Vim also comes with a bunch of basic configurations that is skipped by the -u NONE option, that you can also include while still excluding your .vimrc, by using -u NORC, instead.
Based on #Amadan's answer, I came up with this file (ShowAllDefaults.vim) and command to run it and capture the output.
. In the mean time, learning that, if you have files under ~/.vim, they get executed if you use this:
vim -u ShowAllDefaults.vim -N +q
So the correct way to do it is:
vim -u NONE -N +"source ShowAllDefaults.vim" +q
Contents of ShowAllDefaults.vim:
set verbosefile=/tmp/ShowAllDefaults.log
set all
map
command
let
function
autocmd
I am trying after long time to get familiar with vim also, and I came across this because I had same question.
How I found answer from within vim was to pull up help on defaults and it explained to get defaults along with .vimrc for newer users and also gave the path to default script so you could open it right up in your editor and read & compare it.
I am not going to give my exact path because that might change in different versions, so best to get it from help documents inside vim.
I use gvim with julia-vim for editing julia code. I am using julia 0.5 on a mac and installed julia-vim with vundle.
My problem is that files with the .jl extension do not have appropriate highlighting. For example, if is highlighted but for is not. Any solution for this?
.jl files are sometimes recognized as lisp files by default, (blame Sawfish) so that's probably the syntax highlighting you're getting. (type defun and progn and etc and see if the pretty colors pop up)
You were close when you said the correct solution was :set syntax=julia, what you need is to set filetype plus some autocmd magicks to make that happen every time you open a .jl file.
Put something like this in some file (e.g. jl.vim) in your ftdetect directory:
autocmd BufRead,BufNewFile *.jl :set filetype=julia
And that should do it.
Addendum 1: Changing filetype instead of syntax may be required to trigger additional features like the LaTeX expansions depending on the root of your problem, so that's what I am using.
Addendum 2: Note that this should've been handled by the julia-vim plugin, but conflicts with other scripts can mess with that. You can use :scriptnames to see what scripts have been loaded and in what order, and try to debug what could be causing the conflict, if you think that's worth the trouble.
Addendum 3: Also related is that Vundle has some specific configurations that need to be made when it comes to filetypes, so that could also be causing this. However, I've seen this and similar problems happen outside Vundle for any number of reasons so I still believe that the solution at the top is the best one, and will possibly prevent some future headaches.
After testing julia-vim I think the issue is likely with the color scheme you are using.
Try using a different one.
:colorscheme desert
I tried it with the built-in desert and both if and for were highlighted (see below).
I found that the instructions here worked a treat. Namely
git clone https://github.com/JuliaEditorSupport/julia-vim.git
mkdir -p ~/.vim
cp -R julia-vim/* ~/.vim
Note: I realise that the OP claims to have already installed Julia-Vim using Vundle, but I came to this question because Vim was automatically using LISP syntax highlighting for me, and the above was enough for me. So I am sharing in case anyone comes from the same boat as me (i.e. the problem is not Vundle related) :)
I am using Vim 7.3 with a great deal of plugins, mainly for PHP development. The omnicompletion works well, apart from a small glitch I've come across. I'm trying to work out whether this is a bug in Vim or a problem with my set up, so here's the situation:
I use set tags=<files> to specify the ctags files that I'm using.
:set tags=/home/jon/.vimtags.php,/home/jon/project/.vimtags.php
If I then print the contents of tags, I get what I expect to:
:set tags?
tags=/home/jon/.vimtags.php,/home/jon/project/.vimtags.php
I can also use omnicomplete as usual, with <C-x> <C-o>. This is, until I try and complete with something that doesn't exist (i.e. an unknown tag that returns no results). I get the "Pattern not found" error message and then, bizarrely, my tags file list is cleared. If I print the contents of tags straight after, I get:
:set tags?
tags=
I've done a great deal of grepping on the Vim plugins that I'm using but, as far as I can see, none of them are setting the tags files anywhere.
Can anyone tell me whether this is due to something in my set-up or a bug in Vim itself? Or even whether anyone else finds the same issue?
I can confirm that this isn't default Vim behaviour - it was being caused by the indexer plugin. For some reason, there was a function that reset tags when the omnicomplete failed. I'm going to contact the developer about this, and see if he can come up with a solution.