My GVim distribution on a Windows 8.1 machine has both vimwiki and Vim-Latex-Suite installed through Vundle.
It bothers me that the following display (on the left) will occur when I do the following:
Open a *.wiki file (thereby enter the filetype vimwiki once);
In the same GVim session, open another *.tex file.
Notice that almost all those math symbols are no longer readable on the left. The quoted code-segment was displayed correctly (on the right) when opened by itself, through a new Gvim.exe session.
For this specific case, my guess is that, Vim is incapable of:
Correctly identify and display all math symbols (e.g. subscripts are displayed as a square);
Correctly displaying math symbols in full-width. (By default, half-width is default and this is why those \phi or \int are hiding all its right part.)
The goal for this post is not to "display math symbols in Vim" correctly. It is too wild and LyX can handle it pretty well. Instead, I would like to know:
How can I stop Vimwiki from interfering the display of *.tex
documents?
Any suggestion? Thank you in advance :)
Original answer from #Sato Katsura
This is the conceal feature. It works better in gVim, provided that you use a font that has all the relevant symbols. You can disable it with:
set conceallevel=0
Further details for Vimwiki
Vimwiki has specified g:vimwiki_conceallevel=2 by default according to line 2100 of the help file. Unfortunately, this "default value" was set globally for all buffers.
Specific solution:
For ~\vimfiles\ftplugin\tex.vim, add the following to the end:
setlocal conceallevel=0
For ~\vimfiles\ftplugin\vimwiki.vim, add the following to the end:
setlocal conceallevel=2
I've had the same problem what made me research until reach this mapping:
nnoremap <Leader>c :let &cole=(&cole == 2) ? 0 : 2 <bar> echo 'conceallevel ' . &cole <CR>
It toggles between conceallevel=0 to conceallevel=2
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 like to use vim (on ms windows), I guess everybody have a favorite editor and this is mine.
On one particular PC I run into problems conserning the mark[a-zA-Z] command.
It does not work for the letters a and A but it does for b-z and B-Z and I would like to know why.
If I use the command :marks I can see that ma and mA do set an entry. But 'a and 'A have no effect. The same for the backtick versions.
If I do the same with labels b or B it works.
I checked my _vimrc but there is no line doing something to a or A.
What can block the labels a and A?
How can I find out what is causing this problem?
Any sugestion is welcome.
Additional information: 5-mar-2016, 23:59
I have no _gvimrc file and use the `standard' _vimrc file, never took the time to dig deep into the vim configurations. So it is still pretty vanilla. I like it this way, there are too many PC's I have to work with and synchronising _vimrc files is not what I'm looking for. :-)
This is in my _vimrc file.
:source C:\Program Files (x86)\Vim\_vimrc
let g:xml_syntax_folding=1
:filetype on
:filetype plugin on
:set foldmethod=marker
:set foldmarker={,}
autocmd FileType xml source C:\Users\andre\vimfiles\ftplugin\xml.vim
autocmd FileType python source C:\Users\andre\vimfiles\ftplugin\py.vim
autocmd FileType cs source C:\Users\andre\vimfiles\ftplugin\cs.vim
I have tried the suggestions made by cbaumhardt and that does not make any difference, running vim -Nu NONE -U NONE.
Additional information: 6-mar-2016, 20:23LT
The keyboard setting was interfering with the input. (US-international)
Changing the keyboard setting to US solved the problem.
The operating system can intercept the key presses before vim sees it. So if you use an international keyboard layout, 'a might produce a with an accent. Vim will not see 'a which is why the mark doesn't work.
One solution is to map the character with the accent to 'a or change the keyboard layout.
nnoremap <a with accent> 'a
I recently use the vim to write the latex source. But I got a very strange problem. When I open a old .tex file with vim, the equation will not show as usual. For example, when I type $K$, it just display K unless I move cursor to the line of the equation. And this does not happen when I open a new .tex file. Can anyone help? Thank.
I think you see the effects of the conceal feature; the Tex syntax plugin uses that do shorten certain sequences for display. See :help tex-conceal for the full explanation of that feature.
If this annoys you, just disable concealing, e.g. via
:set conceallevel=0
In a previous post here - vim buffer Trying char-by-char conversion - I was running into a problem when opening up certain files and vim wasn't able to detect the encodings in that file and this was resolved by the solution provided by Ingo.
But after I installed vim's NERDTree plugin, I am running into the same problem again.
It appears that buffer opened by NERDTree mapping map <F2> :NERDTreeToggle<CR> does not obey the :set encoding=utf-8 directive.
I have to manually run :set encoding=utf-8 again in order for the Trying char~by-char conversion... problem to be resolved.
Also, my nerdtree directory shows up with a weird ? instead of the | symbol. Like this:-
What am I doing wrong?
I have temporarily solved this problem by mapping
map <F2> :NERDTreeToggle<CR>:set encoding=utf-8<CR>
instead of the original plain
map <F2> :NERDTreeToggle<CR>
However this solution is not good enough as the Trying char~by-char conversion warning still pops up whenever I browse open a specific directory in the NERDTree buffer.
So, I would like to hear if anyone has a better solution! Thanks!
The nerdtree ? character problem was solved by this post - vim - nerdtree suddenly broke
You shouldn't need to do anything: NERDTree doesn't manipulate encoding and encoding is a global option that you set once and for all in your ~/.vimrc. Go back to an almost empty ~/.vimrc and build from that (with encoding and other options).
I am using Linux Mint 13 Maya Cinnamon 64-bit. My Vim version is 7.3 and I installed the latest version of Janus.
I found that for any files with a hash "#" in its content, the syntax highlight for the file does not work. For example,
# test
print "Hello"
The 'print' has color while I am editing the file. But when I save it and open it again the whole file loses syntax highlight.
If I deleted the first line and save, the syntax highlight comes back after I open it again.
This applies to all kinds of files such as .py, .c and .h. If there is a hash "#" character in the file, syntax highlighting does not work.
I have already tried "syntax on" but nothing changes.
I don't know Janus so this answer might not be 100% useful for you, but let's see. You could try finding out where the settings have been set. Try this:
Get current settings:
:set filetype? syntax?
Check where these have been set:
:verbose set filetype? syntax?
Execute these commands when you lost your syntax highlighting:
:syntax on
:set ft=python
:verbose set ft? syn?
Here you should see which script changed your filetype after saving. Normally, vim uses heuristics to determine the correct filetype if the file extension is ambiguous. In cases where these heuristics don't work, you usually set a global variable in your vimrc to a fixed value. In your case this would be something like:
let g:filetype_py="python"