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
Related
I use vim as my text editor, and I want to make use of highlighted syntax. However, I cannot get it to work when I use the command “syntax on” in my ~/.vimrc file.
The strange thing is that it does the syntax is highlighted in the ~/.vimrc file itself, but not in other files.
When I use the command “syntax on” in my ~/.vimrc file, it does highlight the text in the ~/.vimrc file itself, but not in other files. If I provide other commands in the ~/.vimrc file they work: colorscheme wors, set number also works. So the ~/.vimrc file itself is actually used and works correctly, only the “syntax on” command does not work.
Anybody who can help me with this?
Thanks in advance!
I have found the issue. Beginners mistake I guess...
As mentioned the comments, in the .vimrc file syntax highlighting worked fine. In the files I made myself, I just opened a file without extension (i.e. vim testfile).
In a file without extension, the syntax highlighting does not work because vim does not know how to highlight the syntax. When I now for instance open a file vim testfile.py (with the Python extension), it works fine.
Thanks anyway for your comments!
I have a problem with syntax highlighting in gvim.
i have the following command in my vimrc file:
autocmd BufNewFile,BufRead *.v,*.vs,*.va set syntax=verilog
However if i'm in gvim reading a file - "a.txt" and i also have "b.txt" open on split, when i click on b and then return to a , the syntax highlighting is gone after the click.
someone tried to explain to me that the autocmd not always running.
any ideas
The BufRead option only applies when reading a file into a new buffer, so it makes sense that simply switching between splits won't trigger the auto command. The file has already been read into the buffer; it's not read again unless you close and reopen it.
You want the option BufEnter, as it triggers on entering a buffer. Your new command should then look like:
autocmd BufNewFile,BufRead,BufEnter *.v,*.vs,*.va set syntax=verilog
As a side note, it's probably better to use filetype instead of syntax, as syntax won't affect indentation rules, if there are any. Or even better, use a plugin to get everything set up automagically without needing explicit autocommands in your .vimrc. Just from a quick Google, this plugin pops up a bunch.
When editing a text in markdown, I don't want to highlight bibliography entries. This can be achieved with the following command:
:syn match CitNoSpell '\[#[^[:space:]]\+\]' contains=#NoSpell
However, if I enter this command to .vimrc, it is ignored. I assume that is because spell file is loaded after vimrc has been read, and this definition is not kept.
How should I force vim to ignore this pattern? I prefer it to stay in .vimrc, as I synchronize the file across multiple systems, but another solution would also be welcome.
As the ~/.vimrc is loaded first (before any files), the syntax of an opened file is set only later, and syntax scripts :syntax clear any existing syntax stuff, including your definition.
The right place for your customization would be the :help after-directory; i.e. ~/.vim/after/syntax/markdown.vim, as this will be sourced after $VIMRUNTIME/syntax/markdown.vim.
If you insist on configuring this within your ~/.vimrc, you can try the following autocmd, which has to be put somewhere after :syntax on:
autocmd Syntax markdown syn match CitNoSpell ...
PS: For consistency, as you're tweaking the Markdown syntax, your added syntax group should also start with the syntax name, i.e. markdownCitNoSpell.
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
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)