I am using gvim 7.3 on Windows 7. I want to set the "Courier_New" font in bold style.
How to do that? I tried the following but it failed.
if has("gui_running")
if has("gui_gtk2")
set guifont=Inconsolata\ 12
elseif has("gui_macvim")
set guifont=Menlo\ Regular:h14
elseif has("gui_win32")
set guifont=Courier_New\ Bold:h12:cANSI
endif
endif
An almost exactly identical example is available at the bottom of :help 'guifont':
:set guifont=courier_new:h12:w5:b:cRUSSIAN
so the following should do what you want:
:set guifont=courier_new:h12:b:cANSI
Always start with :help.
Additionaly, you can use :set guifont=* to open the font choosing dialog, select your font, and then use :set guifont? to see how the option was set.
Related
This happened when I start the vim in my Macbook:
huzi:~ huzi$ vim
Error detected while processing /usr/share/vim/vim73/syntax/synload.vim:
line 19:
E185: Cannot find color scheme huzi_python
Press ENTER or type command to continue
When in synload.vim, it is:
" Set the default highlighting colors. Use a color scheme if specified.
if exists("colors_name")
exe "colors " . colors_name
else
runtime! syntax/syncolor.vim
endif
You need to put the "huzi_python.vim" into your ".vim" folder into the subfolder "colors".
After that you have to set the following in your ".vimrc":
colorscheme huzi_python
If you want a dark background within the editing area and syntax highlighting you cann add the following:
set background=dark
I have a global statusline set, but it would be useful if each split window had the current filename in its own statusline.
OK, the default setting is empty so I added the following setting for stock console vim that seems to play nice with the NERDTree and Syntastic plugins:
" [buffer number] followed by filename:
set statusline=[%n]\ %t
" for Syntastic messages:
set statusline+=%#warningmsg#
set statusline+=%{SyntasticStatuslineFlag()}
set statusline+=%*
" show line#:column# on the right hand side
set statusline+=%=%l:%c
In response to this question on SuperUser, I wrote a small vimscript that will detect the filetype of a symbolic link and change the syntax highlighting:
au BufNewFile,BufRead * if &syntax == '' | silent! execute (':set filetype='.matchstr(resolve(#%),'.[^.]*$')[1:]) | endif
So if I open a symbolic link with no extension, it will look at the extension of the file it points to.
It works, but an unintended consequence is that now the syntax highlighting of my .vimrc file is gone. By default, my .vimrc file has vim syntax highlighting (:echo &syntax returns vim).
But when I add the above line, :echo &syntax returns vimrc (an invalid type).
I don't know why this is happening. Shouldn't &syntax=='' evaluate to false, and thus keep &syntax==vim? I suspect that my code is executing before the syntax highlighting is set to vim. But how (and when) exactly is the syntax highlighting set to vim for .vimrc? Additionally, how can I make my script behave the way it should?
Look in Vim's runtime area for filetype.vim. You can bring it up in vim with:
:e $VIMRUNTIME/filetype.vim
In my version, it looks like this line does the trick:
" Vim script
au BufNewFile,BufRead *vimrc* call s:StarSetf('vim')
Perhaps you want to put your autocmd in ~/.vim/after/filetype.vim. I believe this will cause it to be registered after the system ones, and then &syntax should be set up correctly.
jszakmeister's answer diagnoses the problem accurately: filetype.vim sets the filetype for vimrc.
An alternative solution though, to keep everything contained in in your .vimrc file, is to use:
au BufNewFile,BufReadPre * if &syntax == '' | silent! execute (':set filetype='.matchstr(resolve(#%),'.[^.]*$')[1:]) | endif
Note the change from BufRead to BufReadPre. The change causes this line to execute before filetype.vim. The syntax will be changed to vimrc, but then subsequently changed to vim. The upshot is that the script works as it should, but syntax highlighting for vimrc is preserved.
When the current file is ~/.vimrc, this part of your code
matchstr(resolve(#%),'.[^.]*$')
returns your file name: .vimrc.
I have no idea how you could imagine that /home/username/.vimrc would produce vim.
This is rather obviously a bad approach for the problem you tried to solve but there's no bug: you get exactly what you ask for. Using the filename/extension for filetype can't work reliably (js vs javascript, py vs python…).
You will probably need a filename/filetype list or many if/elseif if you want your code to do what you want.
See :h syntax-loading.
I have recently started using a Mac OS X Lion system and tried to use Vim in terminal. I previously had a .vimrc file in my Ubuntu system and had F2 and F5 keys mapped to pastetoggle and run python interpreter. Here are the two lines I have for it:
set pastetoggle=<F2>
map <buffer> <F5> :wa<CR>:!/usr/bin/env python % <CR>
It's working just fine in Ubuntu but no longer works in Mac. (The above two lines are in .vimrc under my home dir.) I have turned off the Mac specific functions in my preference so the function keys are not been used for things like volume. Right now pressing F5 seems to capitalize all letters until next word, and F2 seems to delete next line and insert O.....
Is there something else I need to do to have it working as expected?
In addition, I had been using solarized as my color scheme and tried to have the same color scheme now in Mac. It seems that the scheme command is being read from .vimrc, but the colors are stil the default colors. Even though the .vim/colors files are just the same as before. Is this a related error that I need to fix? Perhaps another setting file being read after my own? (I looked for _vimrc and .gvimrc, none exists.)
Thanks!
I finally got my function mappings working by resorting to adding mappings like this:
if has('mac') && ($TERM == 'xterm-256color' || $TERM == 'screen-256color')
map <Esc>OP <F1>
map <Esc>OQ <F2>
map <Esc>OR <F3>
map <Esc>OS <F4>
map <Esc>[16~ <F5>
map <Esc>[17~ <F6>
map <Esc>[18~ <F7>
map <Esc>[19~ <F8>
map <Esc>[20~ <F9>
map <Esc>[21~ <F10>
map <Esc>[23~ <F11>
map <Esc>[24~ <F12>
endif
Answers to these questions were helpful, if you need to verify that these escape sequences match your terminal's or set your own:
mapping function keys in vim
Binding special keys as vim shortcuts
It probably depends on terminal emulators behaving consistently (guffaw), but #Mark Carey's suggestion wasn't enough for me (I wish it was so simple). With iTerm2 on OS X, I'd already configured it for xterm-256color and tmux for screen-256color, and function mappings still wouldn't work. So the has('mac') might be unnecessary if these sequences from iTerm2 are xterm-compliant, I haven't checked yet so left it in my own config for now.
You might want some imap versions too. Note that you shouldn't use noremap variants since you do want these mappings to cascade (to trigger whatever you've mapped <Fx> to).
Regarding your colorscheme/solarized question - make sure you set up Terminal (or iTerm2, which I prefer) with the solarized profiles available in the full solarized distribution that you can download here: http://ethanschoonover.com/solarized/files/solarized.zip.
Then the only other issue you may run into is making sure you set your $TERM xterm-256color or screen-256color if you use screen or tmux.
You can take a look at my dotfiles for a working setup, but don't forget to setup your Terminal/iTerm color profiles as a first step.
see this answer: https://stackoverflow.com/a/10524999/210923
essentially changing my TERM type to xterm-256color allowed me to map the function keys properly.
I used the following in my vimrc to copy and paste
if &term =~ "xterm.*"
let &t_ti = &t_ti . "\e[?2004h"
let &t_te = "\e[?2004l" . &t_te
function XTermPasteBegin(ret)
set pastetoggle=<Esc>[201~
set paste
return a:ret
endfunction
map <expr> <Esc>[200~ XTermPasteBegin("i")
imap <expr> <Esc>[200~ XTermPasteBegin("")
cmap <Esc>[200~ <nop>
cmap <Esc>[201~ <nop>
endif
I got it from here https://stackoverflow.com/a/7053522
I'm using Vim with a bunch of plugins (pathogen, ctags, snipmate, supertab, ...), and everything works fine for all kinds of file extensions.
However, when I'm try to edit .tex files it presents two problems which seem related. First, Vim starts to work really slow, and second, when I press "any letter + Tab", it tries to auto-complete with words previously written in the text.
One way which I tried to solve those issues, is by removing the supertab plugin from my bundle folder, but it's a not satisfactory solution.
The problem is due to the relativenumber option, when I turned it off the latex edit speed come back to normal.
The following relativenumber, cursorline and MatchParen can slow vim down a lot, especially when dealing with large latex files. When I turn them off then vim becomes much more responsive when dealing with large latex files.
To turn off relative number, type the following in editor mode:
:set nornu
To turn off cursorline, type the following in editor mode:
:set nocursorline
To turn off MatchParen, type the following in editor mode:
:NoMatchParen
If you still want regular line numbering then you can have
:set number
For a more permanent solution, you can also set latex specific settings in your ~/.vimrc file:
" Latex specification
au BufNewFile,BufRead *.tex
\ set nocursorline |
\ set nornu |
\ set number |
\ let g:loaded_matchparen=1 |
The \ and the | are there to allow you add the latex commands over multiple lines.
The other two possible problems are the following being active
cursorline
DoMatchParen
So to make your LᴬTᴇX editing experience much better, you can do something like the following in your ~/.vimrc
au FileType tex setlocal nocursorline
au FileType tex :NoMatchParen
After doing this my Vim is as fast with .tex files as it is with .cpp ones.
I know this is an old issue, but, to anyone seeing this now, it is better to use the ftplugin/ folder in your .vim directory to instruct Vim to enable certain options on a specific file type. Create a file ~/.vim/ftplugin/tex.vim with the following options:
set nocursorline
set nornu
let g:loaded_matchparen=1
This makes Vim load these options only on TeX files (*.tex and related) without resorting to an :autocommand like gloriphobia’s answer does.
Folding is another common source of slowdown. It is normally disabled by default, but perhaps you have enabled it. You can just disable it again:
" (1) if you use the builtin TeX support:
" comment the line in your vimrc that looks like this:
"let g:tex_fold_enabled = ...
" OR, just to be sure, do:
unlet! g:tex_fold_enabled
" (2) if you rather use VimTeX:
" comment the line in your vimrc that looks like this:
"let g:vimtex_fold_enabled = 1
" OR, just to be sure, do:
let g:vimtex_fold_enabled = 0
Note that folding must be enabled/disabled before TeX syntax is loaded in the buffer. Also, Vim option 'foldenable' (toggled by the normal-mode command zi) does not actually clear folding, it just hides it but it’s still there).
However, if you don’t want to give up on folding altogether, I found a single bottleneck in the builtin TeX folding that was responsible for most of the slowdown in my case: the document environment. Simple test: typing stuff just before \begin{document} is reasonably fast, but typing right after it is amazingly laggy. I guess it happens because that environment commonly spans hundreds of lines.
If you use the builtin TeX folding, you can prevent the folding of just the document environment by disabling the texDocZone matchgroup¹. Anyway, why would you want to fold the toplevel contents?
" put this in your vimrc :
au FileType tex :syntax clear texDocZone
" OR put this in ~/.vim/after/syntax/tex.vim :
syntax clear texDocZone
Alternatively, if you have VimTeX, you can replace the builtin TeX folding with the VimTeX’ one. I find it generally better, and it carefully avoids folding the document environment.
" put this in your vimrc :
unlet! g:tex_fold_enabled " just to be sure
let g:vimtex_fold_enabled = 1
VimTeX’ folding is nicely customizable, see :help vimtex-folding.
¹ As of version 121 (April 2022) of the builtin TeX syntax.