I am using gVim 7.2 on Windows 7. I can set the gui font as Consolas 10 (font size) from the menu. I am trying to set this in .vimrc file like below:
set guifont=Consolas\ 10
But it doesn't work. Does anyone know how to set this?
I use the following (Uses Consolas size 11 on Windows, Menlo Regular size 14 on Mac OS X and Inconsolata size 12 everywhere else):
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=Consolas:h11:cANSI
endif
endif
Edit: And while you're at it, you could take a look at Coding Horror's Programming Fonts blog post.
Edit²: Added MacVim.
Try setting your font from the menu and then typing
:set guifont?
This should display to you the string that Vim has set this option to. You'll need to escape any spaces.
I am trying to set this in .vimrc file like below
For GUI specific settings use the .gvimrc instead of .vimrc, which on Windows is either $HOME\_gvimrc or $VIM\_gvimrc.
Check the :help .gvimrc for details. In essence, on start-up VIM reads the .vimrc. After that, if GUI is activated, it also reads the .gvimrc. IOW, all VIM general settings should be kept in .vimrc, all GUI specific things in .gvimrc. (But if you do no use console VIM then you can simply forget about the .vimrc.)
set guifont=Consolas\ 10
The syntax is wrong. After :set guifont=* you can always check the proper syntax for the font using :set guifont?. VIM Windows syntax is :set guifont=Consolas:h10. I do not see precise specification for that, though it is mentioned in the :help win32-faq.
Start a graphical vim session.
Do :e $MYGVIMRC Enter
Use the graphical font selection dialog to select a font.
Type :set guifont= Tab Enter.
Type G o to start a new line at the end of the file.
Type Ctrl+R followed by :.
The command in step 6 will insert the contents of the : special register
which contains the last ex-mode command used. Here that will be the command
from step 4, which has the properly formatted font name thanks to the tab
completion of the value previously set using the GUI dialog.
For Windows do the following:
Note down the font name and font size from the "Edit-Select Font..." menu of "gvim.exec".
Then do :e $MYGVIMRC
Search for "guifont" string and change it to
set guifont=<font name as noted>:h<font size>
Save the file and quit.
Next time when you execute gvim.exec, you will see the effect.
Although this is an old thread I thought that I would add a comment as I have come across it whilst trying to solve a similar issue; this might help anyone else who may find themselves here:
The backslash character is used to ignore the next character; once added to the font name in my gvimrc it worked; I am on a GNU/Linux machine which does not like spaces. I suspect that the initial post was an error due to the back slash being used on a windows machine.
In example:
:set guifont? ## From gvim command, would give the following:
set guifont=DejaVu Sans Mono for Powerline 11
Where as I needed to add this line to the gvimrc file for it to be read:
set guifont=DejaVu\ Sans\ Mono\ for\ Powerline\ 11
When I try:
set guifont=Consolas:h16
I get: Warning: Font "Consolas" reports bad fixed pitch metrics
and the following is work, and don't show the waring.
autocmd vimenter * GuiFont! Consolas:h16
by the way, if you want to use the mouse wheel to control the font-size, then you can add:
function! AdjustFontSize(amount)
let s:font_size = s:font_size + a:amount
:execute "GuiFont! Consolas:h" . s:font_size
endfunction
noremap <C-ScrollWheelUp> :call AdjustFontSize(1)<CR>
noremap <C-ScrollWheelDown> :call AdjustFontSize(-1)<CR>
and if you want to pick the font, you can set
set guifont=*
will bring up a font requester, where you can pick the font you want.
I had to end up doing
:set guifont=Courier:h10:cANSI
Ubuntu 14.04 LTS
:/$ cd etc/vim/
:/etc/vim$ sudo gvim gvimrc
After if - endif block, type
set guifont=Neep\ 10
save the file (:wq!). Here "Neep" (your choice) is the font style and "10" is respect size of the font. Then build the font - cache again.
:/etc/vim$ fc-cache -f -v
Your desired font will set to gvim.
Related
I'm using Mac OS 10.13.4.
iTerm2 Version is Build 2.1.1
Vim Version is
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 29 2017 18:37:46)
Included patches: 1-503, 505-680, 682-1283
Compiled by root#apple.com
And I Installed the Vundle plugin
And when I open vim in iTerm2 with oh-my-zsh, the $p appears at the first line.
It doesn't appear with Terminal.app of Apple?
How to solve this problem?
vim is assuming that iTerm2 is xterm (not a good assumption), and attempting to determine the state of the cursorBlink resource by sending an escape sequence containing $p which iTerm2 does not handle properly (see source-code for vim for the escape sequence, and also where it uses the feature). While vim starts with the TERM setting (i.e., "xterm"), it does make a few checks to exclude things like gnome-terminal as noted in the source code comment. But iTerm2 happens to fool vim in this case. So the result goes to the screen.
In XTerm Control Sequences that is documented like this:
CSI ? Ps$ p
Request DEC private mode (DECRQM). For VT300 and up, reply is
CSI ? Ps; Pm$ y
where Ps is the mode number as in DECSET/DECSET, Pm is the
mode value as in the ANSI DECRQM.
Two private modes are read-only (i.e., 1 3 and 1 4 ), pro-
vided only for reporting their values using this control
sequence. They correspond to the resources cursorBlink and
cursorBlinkXOR.
Although vim is fooled here, the problem is due to iTerm2, for which you've probably set the TERM environment variable to xterm-256color, or something like that. It doesn't match iTerm2's behavior very well (the function keys don't match up, etc). ncurses provides a better one. But out-of-the-box MacOS has a terminal database that's about ten years old, and lacks that entry. To get a good terminal database (i.e., one where you could set TERM to iterm2), you could do that with MacPorts or home-brew.
Running infocmp to get a measure of the differences between the (correct) iterm2 entry and linux, xterm-256color shows that
it's actually closer to nsterm-256color (a correct entry for Terminal.app which Apple doesn't provide) with 38 lines of difference,
next closest linux with 76 lines and
still further away from xterm-256color with 94 lines.
The feature that's missing or mis-implemented in iTerm2 isn't in the terminal description: it's a special feature that vim has to guess about.
As mentioned above, this $p is due to vim sending a control sequence for a cursor blink request. In your .vimrc, you can turn off the cursor blink request by clearing the t_RC terminal option. I wrapped this in a conditional which turns it off only for 256 color terminals.
if &term =~ '256color'
set t_RC=
endif
Setting the terminal explicitly to linux solved it for me:
export TERM=linux
The p means print, which is the command the range is being given to, and yes.. it displays to you what is in that range.
In vim you can look at :help :range and :help :print to find out more about how this works. These types of ranges are also used by sed and other editors.
They probably used the 1,$ terminology in the tutorial to be explicit, but note that you can also use % as its equivalent. Thus, %p will also print all the lines in the file.
I use vim for all my coding and was wondering to use the following features but getting troubles in configuring my .vimrc file
using mouse pointer for cursor : set mouse=a (works perfectly)
using line numbers : set number (works perfectly)
copy to clipboard : does not work as expected.
Reason: because " set mouse=a " keeps it into visual mode.
Workaround : press and hold shift and then select the text : works OK
Problem : because I press shift and hold it, the line numbers are also getting copied to the clipboard and
pasting it wont be of help as those line numbers need to be removed. ofcourse i can unset it and remove line numbering temporarily, but i dont want to do it for every file i open.
So I need :
mouse support for cursor
line number support
copy to clipboard (without) line numbers
any solutions ? (I did try a combination of this and that from other questions, but couldnt get it done)
On ubuntu, run this command in a terminal to install a proper Vim:
$ sudo apt-get update && apt-get install vim-gnome
On Suse, look for the "gvim" package.
Once you are done, you can use "+y to yank to your system clipboard and "+p to paste from it.
Getting the clipboard to work in VIM works different in different Operating Systems. In my vimrc, I have it set up for OSX and Linux and it works nicely in both. In Linux I can just yank lines and they will be in the clipboard, on the Mac when I use MacVim I can use CMD+C (works out of the box) or when run in the console, I use c.
This is the required vimrc setup. When running Linux, you can of course just use the last two lines. When running Windows and using GVim, CTRL+c should work out of the box, as well.
"Clipboard
if os == "darwin"
"Fast copying to clipboard in visual mode
vmap <leader>c "*y<cr>
"Fast cutting to clipboard in visual mode
vmap <leader>x "*x<cr>
elseif os == "Linux"
set clipboard=unnamed
set clipboard=unnamedplus
endif
I cannot set the automatic coloring on vim for FORTRAN. I looked at the other thread on stackoverflow, and both of these lines in my .vimrc do not work:
syntax on
au BufNewFile,BufRead *.f08 set filetype=fortran
The "syntax on" does actually works, but just underlines some part of the code. I want to have the conventional FORTRAN colors.
Actually you were quite close to the solution. Adding the following lines to .vimrc works on my mac.
:syntax enable
:au BufNewFile,BufRead *.f08 set filetype=fortran
PS.: I'm using the Terminal.app. If you use another Termial, the problem might be caused due to the value of TERM. Typing
echo $TERM
should e.g. give xterm-color. Alternatively it might be VT100, which doesn't support colors. But you can easily change this by setting:
TERM=xterm-color
in your Terminal. This you can of course also add to your .bash_profile or .bashrc or whatever file which is read on start-up.
I'm having trouble getting tmux to display lines for borders. They are being created with x and q. It's a debian squeeze server and the locale is set to en_US UTF8. I also tried adding
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
lines to .tmux.conf. Nothing seems to work. I'm not sure if it's a locale issue or not. It displays correctly on other servers, but not the debian. I appreciate any tips you could offer! Thanks...
I had the same problem with PuTTY and Windows 8 when connecting to tmux running on a Debian Squeeze machine. Even when setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) I didn't get the correct line drawing.
Setting the Remote character set to "Use font encoding" did the trick for me.
There is some mismatch between your terminal emulator and the terminfo database entry being used by tmux (the one named by the TERM environment variable when you start/attach to a tmux server).
Per the VT100 User Guide, Table 3-9: Special Graphics Characters, when the “special graphics set” is selected, x is used to draw the “Vertical bar” and q is used to draw “Horizontal line - Scan 5”.
Under terminfo, the VT100 special graphics characters are available as a part of the Alternate Character Set functionality; see the “Line Graphics” section of the terminfo(5) man page.
Probably (on your Debian server) the effective terminfo database entry indicates that ACS is available, but your terminal emulator is not actually responding to the specified control sequences.
The tmux CHANGES file indicates that some terminal emulators (e.g. Putty) do not respect the ACS control sequences when they are in UTF-8 mode. Thus, tmux 1.4 has a change that makes it always use UTF-8 characters instead of ACS sequences when the attaching client specifies that it can handle UTF-8 (i.e. when attaching, -u was given or UTF-8 is present in LC_ALL, LC_CTYPE or LANG; the utf8 window option is about what tmux should expect from the programs it runs, not what it can send to the attached client).
Debian “squeeze” only includes tmux 1.3, so your tmux probably does not have the “prefer UTF-8 line drawing” feature (unless it pulls from a backports source).
If you can not fix your terminal emulator nor upgrade to at least tmux 1.4, then you might be able to use tmux’s terminal-overrides option to unset the ACS-related capabilities so that tmux will fall back to ASCII line drawing. In your .tmux.conf (on the Debian system):
set-option -ga terminal-overrides ',*:enacs#:smacs#:rmacs#:acsc#'
Try setting the character set to "UTF-8" and "Use Unicode line drawing code points" under Window -> Translation in your putty settings.
I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (tmux -u)
If you have Putty 0.73 or higher open settings, expand Window category, then select Translation. Check 'Enable VT100 line drawing even in UTF-8 mode':
I ran thru the gamut of suggestions including:
confirming locale and UTF-8 setting in PuTTY
exporting NCURSES_NO_UT8_ACS=1
manually trying various fonts and PuTTY translation selections
Above did not work. Dialog displays showed qqqq... and xxxx with various corner characters.
Changing all dialog calls to include --ascii-lines was an option but it would involve a lot of script changes.
Best recommendation was to change the Remote Character Set to Use font encoding.
PuTTY Change Settings --> Window --> Translation --> Remote Character Set --> Use font encoding
Left all other PuTTY settings default.
I changed the setting in Putty for terminal to Latin-1 and that seemed to fix the problem.
If you are using KiTTY there is a check box under Windows -> Translation tab, that is called "Allow ACS line drawing in UTF". It needs to be checked:
For me the issue was I forgot to make a locale.conf file when I setup this Arch Linux box. Below line fixed the issue, substitute your own language. A reboot was not required for me.
echo "LANG=en_US.UTF-8" > /etc/locale.conf
under windows/ putty the font you use has to have the characters for it to display
set translation "UTF-8" and "Use Unicode line drawing code points" and font to "courier-new" and most of those problems go away
It seems the font choice is a confusing factor here, to wit:
Lucida sans doesn't display UTF-8 line drawing, only - + | (pipe)
substitution
Courier New Bold does horizontal lines but |
substitution for vertical
Courier New Normal does 'em all.
I'm working with the Vim 7.2 that comes with Mac OS 10.6.1 (Leopard), using the Mac's "Terminal" app. I'd like to use a fancy color scheme. I did this...
:syntax on
Then this...
:colorscheme slate
:colorscheme elflord
:colorscheme desert
etc...
Syntax highlighting is working, but I'm finding that regardless of the scheme I choose, the only colors displayed are the basic Red, Blue, Cyan, Gray, etc.
Is there a way to get the Terminal app to display a larger collection of colors to allow some more subtle schemes?
Create a .vimrc file on your home ~/ folder and then edit it with vim ~/.vimrc. You can try adding syntax on inside ~/.vimrc file. The following command does that:
echo "syntax on" >> ~/.vimrc
It will highlight your code syntax on vim
You need to create file ~/.vimrc and add syntax on in that file
vi ~/.vimrc
syntax on
save the file
and run your vim
Add "syntax on" to the file /usr/share/vim/vimrc and you'll get highlighting in your files every time you edit one.
# vi /usr/share/vim/vimrc
Add this line at the end of the file:
syntax on
Now you'll get highlighting when you edit whatever's file.
The Terminal.app supports AFAIK only 16 colors; iTerm supports more colors or you use mvim (as suggested by Daniel).
You might want to consider using a version of Vim that is a native Mac app (that runs in a window).
MacVim has great color schemes and you can still launch it from Terminal like so:
$ mvim file.txt
That will open your file in a new Vim window.
#ashcatch - Can't leave a comment, but wanted to add that iTerm has other advantages over Terminal.app such as sensible copy and paste (configurable 'word' regex for easy double click selection of paths/urls, middle click paste) and terminal mouse support (:se mouse=a in vi to get mouse text selection, moving of window borders etc.)
I'd be lost without it.