I've been reading some dotfiles (.vimrc .gvimrc) to learn some neat tricks, and I've come across this one:
if has("gui_running")
set fuoptions=maxvert,maxhorz
au GUIEnter * set fullscreen
endif
If this is already a .gvimrc (only loaded if gVim is loaded) why does it have the condition if has("gui_running")? Isn't this redundant? Is there an special issue/reason for that?
I know that if has("gui_running") is interesting to use in scripts and such, I'm asking specifically for it's uses in .gvimrc, because it's only sourced when I use gvim, so in theory, is not needed.
The gvimrc file that the OP linked to was mine, so I had better own up and admit that it was done for no good reason.
I copied that snippet from Hacking without distractions, which recommends putting it in your vimrc. Then at some point I realized it would be neater to move it into the gvimrc file, but I didn't think it through clearly and left the if has('gui_running') check in place. You're right to point out that it is unnecessary, so I have now removed it.
For the sake of posterity, here's my gvimrc before and after the change.
Keeping one config file instead of two is easier (especially if you work on several machines, and need to keep their configs in sync). So instead of creating .gvimrc and .vimrc, some might prefer to put it all into .vimrc file and use guards.
And then someone shares this file in the internet, and people copy GUI-relared sections of it to .gvimrc. That's how it ends up there.
From vim-documentation, basically it allows you to do various settings depending on which gui that is running.
- To check in a Vim script if the GUI is being used, you can use something
like this:
if has("gui_running")
echo "yes, we have a GUI"
else
echo "Boring old console"
endif
*setting-guifont*
- When you use the same vimrc file on various systems, you can use something
like this to set options specifically for each type of GUI:
if has("gui_running")
if has("gui_gtk2")
:set guifont=Luxi\ Mono\ 12
elseif has("x11")
" Also for GTK 1
:set guifont=*-lucidatypewriter-medium-r-normal-*-*-180-*-*-m-*-*
elseif has("gui_win32")
:set guifont=Luxi_Mono:h12:cANSI
endif
endif
UPDATE:
*gui-init* *gvimrc* *.gvimrc* *_gvimrc* *$MYGVIMRC*
The gvimrc file is where GUI-specific startup commands should be placed. It
is always sourced after the |vimrc| file. If you have one then the $MYGVIMRC
environment variable has its name.
Could it be the case .gvimrc is read if you call start the program by using gvim
instead of vim?
The only difference that I can see is if you are calling gvim in a setting where
it cannot start (example, you are in ssh session without X). In that vim is going to be run, but the file might still be sourced.
(I don't really know if this is the case, in my system I have compiled vim without X, so I cannot test it)
Related
I'm having a weird issue with vim on Ubuntu. I've been using it for the last few weeks, trying to learn, on Windows and it behaves differently now that I'm using it on Linux.
I noticed that while in insert mode pressing backspace will delete text just like any other editor on Windows, but on Linux the text is "deleted" yet it stays there until I press ESC or write over it.
I was trying to fix this but I'm confused as to whether this is intended behaviour or not. It happens in gvim too.
The reason of this question is this, however:
I deleted my .vimrc file to see if any of my config was at fault and it fixed it. Backspace was now back to its regular self.
But then I tried creating an empty .vimrc file and that made it go back to the delayed delete. It's empty. Why the hell?
So I have no idea what's causing this. Hope my question makes sense my English ain't the best. Thanks.
Alright so looking at :h compatible I found this:
"When a |vimrc| or |gvimrc| file is found while Vim is starting up,
this option is switched off, and all options that have not been
modified will be set to the Vim defaults. Effectively, this means
that when a |vimrc| or |gvimrc| file exists, Vim will use the Vim
defaults, otherwise it will use the Vi defaults. (Note: This doesn't
happen for the system-wide vimrc or gvimrc file, nor for a file given
with the |-u| argument). Also see |compatible-default| and
|posix-compliance|."
So if I'm getting this right, running Vim with a .vimrc file should automatically set nocompatible and running it without one should set compatible... ? Whatever the case, I tried checking with :verbose set compatible? and it always says nocompatible is on so the -N flag shouldn't do anything... Yet it fixes the issue.
Without a vimrc Vim will load /usr/share/vim/vim80/defaults.vim (depending on your vim version). In this file the bs/backspace parameter is set to 2, or actually it is indent,eol,start which is the same as 2 (see :h bs)
Now if you create an empty .vimrc, defaults.vim will not be loaded, so your bs will possibly be 0.
This behaviour is described in :h defaults.vim
So to solve your problem, just put set bs=2 in your .vimrc
Alright I fixed it.
Running vim with the -N command makes it work properly. I'm not sure why but that's what's happening.
I've tried looking everywhere for information on this but have come up short. I want to be able to use vimrc to set my own arguments for opening vim with. The idea being that if I run "vim -#code foo.bar" then the vimrc file will set syntax highlighting and line numbers but if run "vim foo.bar" then the file will open without line numbers or syntax highlighting. This seems like an obvious thing to want to do and I'm sure I've missed a trick somewhere but I'm struggling to get vim to play nicely. It seems silly to have to set a bash alias for this when the vimrc file is designed for this kind of thing.
My vimrc currently looks like this:
if $ARGV[0] == "#code"
set nu
filetype plugin on
syntax on
endif
I have a workaround for similar situation
I have special vimrc (.coding_vimrc)
wich loads usual vimrc inside
source .vimrc
and contains all special settings for coding
Run vim with
vim -u .coding_vimrc foo.bar
PS:
assumes full path in both cases
As I asked (and answered myself) in this question, some vim script is preventing the color scheme solarized.vim to load correctly. And I have found a workaround which is to load solarized.vim in or after /usr/share/vim/gvimrc.
However, even as a workaround it's not optimal, because I hope all my customization would reside in my ~/.vim directory (or at least my $HOME directory).
So here is my question:
How to load a script after /usr/share/vim/gvimrc?
Especially, If I can create a script solarized.vim, putting a single line colo solarized in it, and let it loaded after gvimrc.
The quick and easy way: create a ~/.gvimrc and put your commands in there.
If you want to keep everything in ~/.vim, however, you could try the suggestion from http://vimdoc.sourceforge.net/htmldoc/gui.html#gvimrc and something like this to your ~/.vim/vimrc file:
If you want some commands to be executed just after opening the
GUI window, use the |GUIEnter| autocommand event. Example:
:autocmd GUIEnter * colo solarized
I have always been one to replace TABs in VIM with x amount of spaces (usually 4).
Four lines I almost always use in my .vimrc config file are:
set tabstop=4
set shiftwidth=4
set expandtab
syntax on
Basically, there are moments when I NEED to use a single TAB (such as Makefiles), and I don't know how else to work around that other than leaving the file, editing my .vimrc, and then reloading the file of interest.
That said, what is the quickest way (from within VIM) to revert it back to using TABS, and then reverting back to my original settings? I'm looking for the least-hassle, least-keystrokes solution.
VIM will automatically enable the TAB for a makefile, assuming you name it "makefile," as opposed to "Makefile." Not sure why VIM still doesn't detect the type with a lower-uppercase difference, but such is life. (#Sedrik)
That aside, other alternative solutions are:
Filetype Binding (#ThorstenS #tungd):
autocmd FileType make setlocal noexpandtab
RealTime Switch (#ThorstenS):
Assuming the .vimrc configuration mentioned in the question, do:
:set noet (to switch from spaces to TAB)
and :set et (to switch back)
Just use the magical escape key available in insert mode.
On the *NIX's it is ^V by default when you are in insert mode. On Windows, you need to find out what the magical escape character is - ^V is taken for something else; I think it may be ^Q or ^S?
So! In your makefile:
this: this.c
<C-V><Tab>cc this.c
where the usual meanings apply:
means hit ctrl-V (you should see a ^ hiding away under the cursor)
- hit the tab key. Bingo.
Works for me.
Note: if you use vim settings or startup code which smashes tabs as you read a file, this obviously is a short-term fix. I prefer to learn how to use the retab command to ensure a file is tab-clean, because I don't like a file to be touched unless I consciously choose to do so.
Just type set noexpandtab . Perhaps you bind this to a function key.
Only this configuration helped me solve this problem.
filetype plugin indent on
filetype detect
autocmd FileType make set noexpandtab
Vim defaults to tabstop=8 and noexpandtab, so the defaults are well suited to working with Makefiles. If your .vimrc uses custom options for tabstop, expandtab, etc., one simple solution is to bypass your .vimrc while working with Makefiles.
From the manpage (emphasis mine):
-u {vimrc} Use the commands in the file {vimrc} for initializations. All the other initializations are skipped. Use this to edit a special kind of files. It can also be used to skip all initializations by giving the name "NONE". See ":help initialization" within vim for more details.
Since I can never remember the necessary flag/value/formatting, I've created a Bash alias which remembers for me: alias vimnone='vim -u NONE'
You can create a custom configuration per file type.
mkdir -p ~/.vim/after/indent
echo 'set noexpandtab' >> ~/.vim/after/indent/make.vim
Basically, here we created a new indent configuration for makefiles that will be loaded after other scripts.
source
Several users in this epic question put the following in the .vimrc:
" Necesary for lots of cool vim things
set nocompatible
But is it really necessary? From the docs:
'compatible' 'cp'
boolean (default on, off when a |vimrc| or |gvimrc| file is found)
If set nocompatible is going in a .vimrc, that means that a .vimrc file exists, seemingly making it pointless.
If it is the system-wide vimrc, this option won't be off. So, if you're changing the system-wide vimrc and you want it, you need to set it.
From the documentation section *compatible-default* (emphasis mine):
When Vim starts, the 'compatible'
option is on. This will be used when
Vim starts its initializations. But
as soon as a user vimrc file is found,
or a vimrc file in the current
directory, or the "VIMINIT"
environment variable is set, it will
be set to 'nocompatible'.
Another difference is that explicitly setting 'nocompatible' overrules calling vim with the -C flag.
In any other scenario, yes, setting 'nocompatible' in your vimrc is a noop.
In the end I think it's just a matter of "better safe than sorry".
Many people share their .vimrc files on GitHub and I sometimes will test out settings without replacing my .vimrc file. vim allows me to do this with the -u flag.
vim -u test_vimrc
From vim ":help nocompatible"
(Note: This doesn't happen for the system-wide vimrc or gvimrc file,
nor for a file given with the |-u| argument).
This means that if you share your .vimrc with someone and they use -u flag to load your file, vim won't be configured the same as if the file were named .vimrc and located in your home directory.
I was using vim in Cygwin on a Windows VM and every time I was in Insert Mode, pressing arrow keys would result in vim printing "A", "B", "C" or "D" on the screen instead of scrolling. I found a forum that said putting vim in nocompatible mode would fix it. Thankfully, it did.
I put "set nocompatible" in my ~/.vimrc file and the problem remains gone. So perhaps it's not 100% useless.
Based on what Johnny pointed out above, I was simply astonished when I just found THIS out:
$ cat /usr/share/vim/vimrc.tiny
" Debian system-wide default configuration Vim
set runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim74,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/after
set compatible
ARGH!!!
No I did NOT expect that.
Debian (or Debian Unstable aka Ubuntu) indeed DOES put up a nightmare to their users by overriding the default setting by set compatible.
I hope that you will now know why when you're coming from FreeBSD, the first thing you would have to do is override the system-wide setting by putting a set nocompatible into your own ~/.vimrc. Because otherwise you'd just produce letters instead of being able to move the cursor the way you've been used to.
I think this is a horrid idea. In other words, this set compatible line ought to be removed from the system-wide vimrc.tiny in both Debian and Ubuntu, because it will annoy new users who are not (yet) as smart as knowing how to get the cursor keys working.
It's things like these that force them to nano and others because of such entirely pointless blockers!
I would really want to talk with the dude who once propagated this change to the system-wide resource file in Debian. And maybe also to the people who acknowledged his change to the fullest.
Johnny is right: on your private PC, you may remove said line from the system-wide .vimrc (if there), and touch an empty .vimrc on your $HOME. Thanks so much for pointing that out, way less clutter again. Note that you MUST have that ~/.vimrc (even if empty!) as otherwise you will not be able to use the cursors without explicitly putting in set nocompatible.
got the same problem on using -u vimrc option, even doing set nocompatible was misbehaving with some of my older setting, after some search i found one compactible version that works for me:
" Avoid side-effects when nocompatible has already been set.
if &compatible
set nocompatible
endif
this avoid re-setting of nocompatible flag when it is already set.
vim :help nocompatible shows conditions when it set/resets the options value, scroll to that table of options and values, for quick reference, conditions that effect this behaviour are:
Option is set to the value given in {set value} when 'compatible' is
set.
Option is set to the value given in {set value} when 'compatible' is set AND is set to its Vim default value when 'compatible' is
unset.
Option is NOT changed when setting 'compatible' but IS set to its Vim default when 'compatible' is unset.