The vim manual states:
On systems where 'guifontset' is supported (X11) and 'guifontset' is
not empty, then 'guifont' is not used.
Spaces after a comma are ignored. To include a comma in a font name
precede it with a backslash. Setting an option requires an extra
backslash before a space and a backslash. See also
|option-backslash|. For example: >
:set guifont=Screen15,\ 7x13,font\\,with\\,commas
will make Vim try to use the font "Screen15" first, and if it fails it
will try to use "7x13" and then "font,with,commas" instead.
So, I would like to do the following:
if has("gui_running")
if has("gui_gtk2")
set guifont=Droid\ Sans\ Mono,Inconsolata,Monospace
elseif has("gui_win32")
set guifont=Droid\ Sans\ Mono:h10,Consolas:h11:cANSI
endif
endif
Trouble is that it does not work for me... I have been trying for a couple of hours on CentOS6.3 and Debian Wheey, but when ever I write this command like this, VIM will just start with Sans font.
Am I doing something wrong? How do you smartly detect which fonts are on the system ?
OK, I know this is probably not the right way, but it works. So, here is how I set a fallback font for VIM-GTK:
if has("gui_running")
if has("gui_gtk2")
let dsm=system('fc-list | grep -c Droid\ Sans\ Mono')
let cons=system('fc-list | grep -c Inconsola')
if ( dsm > 0)
set gfn=Droid\ Sans\ Mono\ 10
elseif ( cons > 0)
set gfn=Inconsolata\ 12
else
set gfn=Monospace\ 10
endif
elseif has("gui_win32")
set guifont=Droid\ Sans\ Mono:h10,Consolas:h11:cANSI
endif
endif
This snippet will check if Droid Sans Mono is installed, and also if Inconsolata is installed.
If the first one is install, the UI font will be Droid Sans Mono, if not it will be set to Inconsolata, and finally, it will be set to Monospace.
On Windows 7 the comma separated list just works.
I ran into the same issue. The problem here is that when Vim calls gui_init_font (code) it expects if gui_mch_get_font (code) fails it can move on to the next font in the comma-separated list. But in GTK gui_mch_get_font calls pango_font_description_from_string (code) which will never fail, it'll just return a default.
But pango_font_description_from_string itself takes a comma-separated list of families followed by style options, size and variations and has its own fallback logic (doc) withe the following format: [FAMILY-LIST] [STYLE-OPTIONS] [SIZE] [VARIATIONS]. Thus escape your list as follows:
if has("gui_running")
if has("gui_gtk2") || has("gui_gtk3")
set guifont=Droid\ Sans\ Mono\\,Inconsolata\\,Monospace 10
elseif has("gui_win32")
set guifont=Droid\ Sans\ Mono:h10,Consolas:h11:cANSI
endif
endif
Then Pango will do the fallback work and pick the right font for you. On GTK it seems to be best to fully escape your string and let GTK do the logic.
I either failed to get Oz123's answer properly abstracted into a function or else otherwise couldn't get this working on my system. I had additional issues due to actually using two users (a sandboxed web user and my main account); there was some problem executing fc-list).
My workaround was to reassign the alias for the Monospace font, which affects all of my apps (don't employ this technique if you only want this to work in gvim).
This change goes into ~/.config/fontconfig/fonts.conf:
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
<alias>
<family>monospace</family>
<prefer><family>Panic Sans</family></prefer>
</alias>
</fontconfig>
I chose Panic Sans (unofficially hosted here), a variant of the highly popular free DejaVu Sans Mono font, because it is particularly good at rendering code (it additionally solves the underscore and dash problem in DejaVu). The font's files themselves live in my ~/.fonts/Panic_Sans directory.
Installing it in this manner allows me to share my ~/.vimrc between systems and not have to worry about whether Panic Sans is installed on them.
This means that my ~/.vimrc now merely contains:
if has("gui_running")
if has("gui_gtk2")
set guifont=Monospace\ 7
endif
" …
And this works because the fontconfig alias properly matches Monospace to Panic Sans:
$ fc-match Monospace
PanicSans.ttf: "Panic Sans" "Regular"
Related
I am using Vim inside the Windows Subsystem for Linux. The windows command prompt has a bug which renders the background color incorrectly.
The fix is set t_ut=. Rather than applying this fix in all situations, I assume it would make sense to only apply it when Vim is being used inside the Windows console.
Unfortunately, I am not sure how to detect whether the Windows console is being used, because I am inside the Windows Subsystem for Linux.
I used the following code that implemented Roadowl's comment.
let uname = substitute(system('uname'),'\n','','')
if uname == 'Linux'
if system('$PATH')=~ '/mnt/c/WINDOWS'
" We are in Windows Subsystem
endif
endif
Update: I combined roadowl's and bk2204's answer:
let uname = substitute(system('uname'),'\n','','')
if uname == 'Linux'
let lines = readfile("/proc/version")
if lines[0] =~ "Microsoft"
return 1
endif
endif
Typically, one addresses issues like this by detecting the terminal type, but it seems Microsoft Terminal reports xterm-256color when it really doesn't support this.
It's possible to detect whether one is running WSL with a function like the following:
function! IsWSL()
if has("unix")
let lines = readfile("/proc/version")
if lines[0] =~ "Microsoft"
return 1
endif
endif
return 0
endfunction
This is consistent with the way that Microsoft suggests that WSL be detected.
I often use gf in vim to open files under cursor. Often these file paths use environment variables but when in .tcl script files vim is unable to use the environment variable.
This works for gf:
$tcl_lib/myfile.tcl
These do NOT work for gf:
$env(tcl_lib)/myfile.tcl
$::env(tcl_lib)/myfile.tcl
These are some of the things I have tried:
:set isfname=#,48-57,/,.,-,_,+,,,#,$,%,~,=,{,},(,)
:set isfname=#,48-57,/,.,-,_,+,,,#,$,%,~,=,{,},40-41
:set includeexpr=substitute(v:fname,'\$env(\([^)]\+\))','\$\1','')
Is there a way to make vim understand the syntax for environment variables in tcl scripts (specifically for the 'gf' command)?
There are a few techniques:
Set 'path' & 'includeexpr'
In theory you can just add $tcl_lib to path. e.g. set path=.,$tcl_lib,,. However, any filename starting with / will fail. This can be remedied by removing the starting /.
Add to ~/.vim/after/ftplugin/tcl.vim:
set path=.,$tcl_lib,,
let &l:includeexpr="substitute(v:fname, '^/', '', 'g')"
Reading Environmental variables via 'includeexpr'
Can use a substitution to expand environment variables
let l:includeexpr = "substitute(v:fname, '$\\%(::\\)\\=env(\\([^)]*\\))', '\\=expand(\"$\".submatch(1))', 'g')"
This uses a sub-replace-expression (See :h sub-replace-expression) to use expand() to get the environmental variable.
This might require you to change 'isfname' to allow more characters tto be a part of a filename looking string.
Just map gf and friends
Make buffer-local mappings for gf, <c-w>f, etc which are specific to your language and check certain paths. This completely side-steps many of Vim's built in methods so it should be used as a last resort.
Finally got back to this and was able to solve it in a pretty good way. Add the following tcl.vim file to your ~/.vim/ftplugin and your "gf" should work!
https://github.com/stephenmm/dotfiles/blob/master/vim/ftplugin/tcl.vim
" Add charecters to possible filename types so vim will recognize:
" $::env(THIS)/as/a/file.tcl
set isfname+={,},(,),:
" Turn the string into something vim knows as a filename:
" $::env(THIS)/as/a/file.tcl => ${THIS}/as/a/file.tcl
function! TclGfIncludeExpr(fname)
if a:fname =~? '\$\(::\)\?env([^)]\+)'
return substitute(a:fname, '\$\(::\)\?env(\([^)]\+\))', '${\2}', 'g')
endif
return a:fname
endfunction
" Tie the function to includeexpr
set includeexpr=TclGfIncludeExpr(v:fname)
Adding below 2 lines in ~/.vimrc will work for me.
set isfname+={,},(,),:
let &l:includeexpr = "substitute(v:fname,'$\\%(::\\)\\=env(\\([^)]*\\))','\\=expand(\"$\".submatch(1))', 'g')"
I've installed the vim-latex-suite and I'd like to customize the folding for use with the labbook package. The labbook package uses \labday, \experiment, and \subexperiment in place of \chapter, \section, and \subsection.
I'd like to customize the folding options with vim-latex-suite in Vim so that \labday, \experiment, and \subexperiment are folded like the traditional sectioning commands.
I've tried adding to my ~/.vim/after/ftplugin/tex.vim the following (but it didn't work)
" Folding sections
let g:Tex_FoldedSections = ',labday,experiment,subexperiment'
" Folding commands
let g:Tex_FoldedCommands = ',labday,experiment,subexperiment'
Can someone show me how to customize the folding for the labbook package?
I think you should put
let g:Tex_FoldedSections = 'labday,experiment,subexperiment'`
in your .vimrc itself. If you take a look at ftplugin/latex-suite/folding.vim you'll find:
if g:Tex_FoldedSections != ''
call Tex_FoldSections(g:Tex_FoldedSections,
\ '^\s*\\frontmatter\|^\s*\\mainmatter\|^\s*\\backmatter\|'
\. '^\s*\\begin{thebibliography\|>>>\|^\s*\\endinput\|'
\. '^\s*\\begin{slide\|^\s*\\end{document')
endif
Which means that setting Tex_FoldedSections after the plugin as already loaded will not work. Also make sure that your sections in your latex file itself are nested correctly.
When building my application using the :make command in Vim, the output is not colorized. I have configured the makefile to use clang as the C compiler, and when running make outside of Vim or when running :!make, clang's output is colorized. :set makeprg returns makeprg=make, just for reference.
I have the same issue with grep: when running :grep, the output is not colorized; when running :!grep, it is. I have tried using the --color option with :grep, to no avail. :set grepprg returns grepprg=grep -n $* /dev/null.
I've read through VIM Unix commands printed in color and also How to color my vimgrep result patterns. The former seems to have the opposite problem (i.e. :!command output not colorized); the latter doesn't have any alternative to dropping down to the shell, which I don't feel is a "correct" fix for the issue.
The problem is that when Vim runs other commands via :make or :grep, those commands don't get a terminal for their standard output -- in the sense that for them isatty(STDOUT_FILENO) is false -- because Vim is capturing the output on its way to being displayed on the terminal. On the other hand, when you use :!make or :!grep, standard output is just going to the terminal.
Clang by default and grep --color=auto (which is probably how you have it aliased) use the terminalness of stdout to decide whether to colourise their output. This is convenient in that you get colourful output on your terminal but capture just the text when you redirect output to a file -- all without needing to add extra command line options.
So what you want to do is override these commands' usual smarts so that they always colourise their output.
For grep, you can use --color=always when it is run via :grep within Vim:
:set grepprg=grep\ --color=always\ -n\ $*\ /dev/null
and depending on your colour settings and version of grep this will work well enough.
For clang, you can change your Makefile to use clang -fcolor-diagnostics so as to force colourisation or more flexibly add an extra variable to $(CC) that will be overridden when run via :make within Vim:
:set makeprg=make\ EXTRA_CFLAGS=-fcolor-diagnostic
However (at least with clang 3.0 and vim 7.3) you will find that clang's style of colourisation prevents Vim from picking out filenames and line numbers from the diagnostics, so doing this wrecks the advantage of using :make rather than :!make.
You may be able to teach Vim to pick out the filenames etc from the surrounding ANSI escape sequences that do the colourisation by adding more entries to Vim's errorformat option to match the colourised clang-style diagnostics. (And similarly with grepformat if your grep colourisation colours the filenames or linenumbers.)
When you run :grep or :make (as opposed to :!grep or :!make),
the output is not only shown in the terminal,
but also sent to the quick-fix window, from which it is processed.
You can access the quick fix windo using the vim-command :copen.
The quick fix window is essentially a text file that is opened in read-only mode.
Like in any other text file, colors are not supported in the quick fix file.
Instead, they are represented with escape characters like [01;34m.
Therefore, producing colorized output from make (or grep) will
mess up the output as it is shown in the quick-fix window, even if you can get vim to process it,
and send the cursor to the selected error/warning/find message.
The question whether the output is colorized now becomes a little subtle: I suggest that the
terminal output should remain uncolored, but that the quick-fix output should be colorized.
The color scheme in the quick fix window is not defined by any color-indications in the file itself, but in the syntax highlighting
of the quick fix window, defined in the file qf.vim (/usr/share/vim/vim81/syntax/qf.vim on my computer).
The color scheme defined in qf.vim does not add much color to the quick fix window, but the syntax hightlighting
scheme may be extended by creating the file ~/.vim/syntax/after/qf.vim. I use cmake in combination with the
gnu and/or the intel compilers, and get nice-looking results with the following contents for ~/.vim/syntax/after/qf.vim:
syn match qBuilt "Built target *" nextgroup=qTarget
syn match qTarget ".*$" contained
syn match qEnteringLeaving ": \(Entering\|Leaving\) directory *" nextgroup=qdSeparator
syn match qdSeparator "'" nextgroup=qdName contained
syn match qdName "[^']*" contained
syn match qbProgress "\[ *[0-9]*%\]"
syn match qBuild "Building .* object"
syn match qWarn "warning\( *#[0-9]*\|\):"
syn match qError "error\( *#[0-9]*\|\):"
syn match qRemark "remark\( *#[0-9]*\|\):"
hi def link qTarget Constant
hi def link qError Error
hi def link qWarn Error
hi def link qRemark WarningMsg
hi def link qEnteringLeaving Keyword
hi def link qBuild Keyword
hi def link qBuilt Keyword
hi def link qdName Include
hi def link qbProgress Special
I'm using gvim on Windows.
In my _vimrc I've added:
set shell=powershell.exe
set shellcmdflag=-c
set shellpipe=>
set shellredir=>
function! Test()
echo system("dir -name")
endfunction
command! -nargs=0 Test :call Test()
If I execute this function (:Test) I see nonsense characters (non number/letter ASCII characters).
If I use cmd as the shell, it works (without the -name), so the problem seems to be with getting output from powershell into vim.
Interestingly, this works great:
:!dir -name
As does this:
:r !dir -name
UPDATE: confirming behavior mentioned by David
If you execute the set commands mentioned above in the _vimrc, :Test outputs nonsense. However, if you execute them directly in vim instead of in the _vimrc, :Test works as expected.
Also, I've tried using iconv in case it was an encoding problem:
:echo iconv( system("dir -name"), "unicode", &enc )
But this didn't make any difference. I could be using the wrong encoding types though.
Anyone know how to make this work?
It is a bit of a hack, but the following works in Vim 7.2. Notice, I am running Powershell within a CMD session.
if has("win32")
set shell=cmd.exe
set shellcmdflag=/c\ powershell.exe\ -NoLogo\ -NoProfile\ -NonInteractive\ -ExecutionPolicy\ RemoteSigned
set shellpipe=|
set shellredir=>
endif
function! Test()
echo system("dir -name")
endfunction
Tested with the following...
:!dir -name
:call Test()
I ran into a similar problem described by many here.
Specifically, calling
:set shell=powershell
manually from within vim would cause powershell to work fine, but as soon as I added:
set shell=powershell
to my vimrc file I would get the error "Unable to open temp file .... "
The problem is that by default when shell is modified, vim automatically sets shellxquote to " which means that shell commands will look like the following:
powershell -c "cmd > tmpfile"
Where as this command needs to look like this, in order for vim to read the temp file:
powershell -c "cmd" > tmpfile
Setting shellquote to " in my vimrc file and unsetting shellxquote (i.e. setting it to a blank space) seem to fix all my problems:
set shell=powershell
set shellcmdflag=-c
set shellquote=\"
set shellxquote=
I've also tried taking this further and scripting vim a bit using the system() call:
system() with powershell in vim
I suspect that the problem is that Powershell uses the native String encoding for .NET, which is UTF-16 plus a byte-order-mark.
When it's piping objects between commands it's not a problem. It's a total PITA for external programs though.
You can pipe the output through out-file, which does support changing the encoding, but still formats the output for the terminal that it's in by default (arrgh!), so things like "Get-Process" will truncate with ellipses, etc. You can specify the width of the virtual terminal that Out-File uses though.
Not sure how useful this information is, but it does illuminate the problem a bit more.
Try replacing
"dir \*vim\*"
with
" -command { dir \*vim\* }"
EDIT: Try using cmd.exe as the shell and put "powershell.exe" before "-command"
Interesting question - here is something else to add to the confusion. Without making any changes to my .vimrc file, if I then run the following commands in gvim:
:set shell=powershell.exe
:set shellcmdflag=-noprofile
:echo system("dir -name")
It behaves as expected!
If I make the same changes to my .vimrc file, though (the shell and shellcmdflag options), running :echo system("dir -name") returns the nonsense characters!
The initial example code works fine for me when I plop it in vimrc.
So now I'm trying to figure out what in my vimrc is making it function. Possibly:
set encoding=utf8
Edit: Yep, that appears to do it. You probably want to have VIM defaulting to unicode anyway, these days...
None of the answers on this page were working for me until I found this hint from https://github.com/dougireton/mirror_pond/blob/master/vimrc - set shellxquote= [space character] was the missing piece.
if has("win32") || has("gui_win32")
if executable("PowerShell")
" Set PowerShell as the shell for running external ! commands
" http://stackoverflow.com/questions/7605917/system-with-powershell-in-vim
set shell=PowerShell
set shellcmdflag=-ExecutionPolicy\ RemoteSigned\ -Command
set shellquote=\"
" shellxquote must be a literal space character.
set shellxquote=
endif
endif
Combining the answers in this and the related thread, add the following to your $profile assuming you installed diffutils from chocolatey:
Remove-Item Alias:diff -force
And add the following to your ~/.vimrc:
if (has('win32') || has('gui_win32')) && executable('pwsh')
set shell=pwsh
set shellcmdflag=\ -ExecutionPolicy\ RemoteSigned\ -NoProfile\ -Nologo\ -NonInteractive\ -Command
endif
make sure shellcmdflag is exactly as shown
All credit for these solutions to their respective contributors, this is merely an aggregation post.
I propose an hackish solution. It doesn't really solve the problem, but it get the job done somehow.
This Vim plugin automate the creation of a temporary script file, powershell call through cmd.exe and paste of the result. It's not as nice as a proper powershell handling by vim, but it works.
Try instead
set shellcmdflag=\ -c
Explanation:
Vim uses tempname() to generate a temp file path that system() reads.
If &shell contains 'sh' and &shellcmdflag starts with '-'
then tempname() generates a temp file path with forward slashes.
Thus, if
set shell=powershell
set shellcmdflag=-c
then Vim will try to read a temp file with forward slashes that
cannot be found.
A remedy is to set instead
set shellcmdflag=\ -c
that is, add a whitespace to &shellcmdflag so that the first character
is no longer '-' and tempname() produces a temp file path with backward
slashes that can be found by system().
I remarked on the vim_dev mailing list ( https://groups.google.com/forum/#!topic/vim_dev/vTR05EZyfE0 ) that this deserves better documentation.
actf answer works for me, but because of Powershell built in DIFF (which is different from the Linux one) you must add this line to your Powershell profile to have diff working again in VIM:
Remove-Item Alias:diff -force
I'm running GVim v8.2 (Windows).
Using the fullpath to the executable works for me:
set shell=C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
I don't use VIM but Powershell's default output is Unicode. Notepad can read unicode, you could use it to see if you are getting the output you expect.