I have a windows directory (U:\S) that contains files that must not be
changed. Their read-only bit cannot be set, so they must remain writeable.
As I have to look into some of the file's content rather regurarly with VIM, I want to make sure that I don't accidentally change the file's conent.
So, I put the following line into my .vimrc conifugration file:
autocmd InsertEnter u:/s/* call confirm("File should not be changed")
which seemed to work fine.
But then, I have also directory named U:\supportTerminal that contains files
that I have to change. When I edit a file within that directory, the file pattern u:/s/* for some reason matches and my warning pops up.
I tried playing around with some pattern, but I found none that only matches within u:\s but not within u:\supportTerminal
So, how could I go about what I want?
That makes for a bug, which you should report to vim-dev at vim.org. In linux I don't have this behaviour: it matches nicely.
As a temporary workaround,
:au BufRead u:/s/* set readonly
:au! BufRead u:/supportTerminal/*
should first make the general rule and then remove the one dir as an exception. Not sure whether this works in Windows GVim properly. Should this fail, other hack would be:
:au BufRead u:/supportTerminal/* set noreadonly
PS: As mentioned in the comments above, setting vim's own setting readonly works better to prevent accidental edits. User can't :write files with RO flag on, but it can be circumvented by setting noreadonly if needed.
Related
I am creating a very simple plugin to make syntax highlighting better in Vim for baan syntax (basically an improved version of syntax/baan.vim).
This is my plugin directory.
One file inside ftdetect folder; baan.vim. It looks like this.
au BufRead,BufNewFile *.bc set filetype=baan
The file inside syntax folder; baan.vim. It is almost the same as baan.vim in syntax folder within Vim. With one line of change in syntax highlighting.
My problem is when I open any files with .bc extensions, two more syntax files are called; one before my own plugin syntax file, and other one is after.
bc.vim syntax file is called already from filetyp.vim, I guess. Because filetypes I want to set syntax is with extension .bc. This is the first issue. Second one is that I set filetype to 'baan' but Vim is looking and sourcing all baan.vim files. But once baan.vim is source from myplugin, it is still sourcing the one from Vim itself. How can I solve those issues elegantly without using /after directory?
This is normal. Consider the following.
$VIMRUNTIME/filetype.vim sources ftdetect/*.vim scripts near to the end. At this point setf bc was already executed and the first FileType event was triggered and processed. BTW. This is the reason why late set ft=baan works but setf baan no more. Shouldn't be a problem though, as :syn clear is executed in $VIMRUNTIME/syntax/synload.vim automatically. And no, you can't do anything with this unless you patch/replace filetype.vim.
synload.vim intentionally sources all matching files (:runtime!). This is the reason they respect b:current_syntax variable. The first to set it wins, others step aside by executing :finish at a top. Nonetheless, they all are sourced and get into :scriptnames. Note this also means that extending existing syntax with after/syntax (while not respecting b:current_syntax) is usually more preferable.
I set the comments option for a filetype to b:*. If I open such file I can verify this with set comments?. Now further I explicit set the formatoptions to use r for repeating the comment on a new line. After all calling set formatoptions? return in sum j1tcqln.
If open a new line o and write something like * This is a comment hit <CR I expect to get a * on the new line es well, cause the r option, but is doesn't.
The check if the +comments feature is available with :echo has('comments') is positive and returns 1.
Whats the problem here?
Edit:
This is my ftplugin/markdown.vim:
setlocal comments=b:*,b:-,b:+,b:>
setlocal formatoptions+=r
setlocal formatoptions-=c
echom 'Format: ' . &formatoptions
The last line leave a correct message when open a file with this type. But calling :echo &formatoptions manually afterwards, its again the false output.
It seems like no matter what I do in this ftplugin afterwards its not there anymore, even though it has been executed.
Edit:
It looks like my ftplugin gets overwritten by the default one in /usr/share/nvim/runtime/ftplguin/. Does this make sense and how can I mix them up?
Filetype plugins are sourced in this order, each potentially overriding the preceding one:
$HOME/.vim/ftplugin/markdown.vim
$VIMRUNTIME/ftplugin/markdown.vim
$HOME/.vim/after/ftplugin/markdown.vim
--- edit ---
The first location is suitable for two scenarii:
you are creating support scripts for a language not natively supported by Vim,
you want to prevent Vim from sourcing the default support script for a specific filetype (the solution in your answer).
The second location is off-limits. Four main reasons for this:
your changes can and will be overridden during future updates,
your changes may make Vim unstable,
having to sudo your way to your config will get annoying pretty quickly,
put your stuff in your $HOME.
The third location is sourced last so it allows you to selectively override default settings and add your own. This is the safest place for your own filetype-specific settings.
The solution is to add this at the header of the ftplugin file:
if exists('b:did_ftplugin') | finish | endif
let b:did_ftplugin = 1
Then is necessary cause the ftplugin in /usr/share/nvim gets loaded after and does not been executed if this variable is set.
Problem
A setting in my vimrc (set noshowmode) is being overridden by a plugin later in the loading process.
Goal
Have a VimScript file be executed last (or at least after plugins).
What I Know
Plugin VimScripts are executed after the vimrc (Source).
The after-directory is run close to last and holds user overrides
(Source: :h after-directory).
Vim's runtimepath determines the order of what is run.
Failed Attempts
I tried appending a VimScript file (containing set noshowmode) to the
end of $VIMRUNTIME with
set runtimepath=$VIMRUNTIME,~/.vim/nosmd.vim, but this method ended up
messing up other plugins (namely vim-airline, which did not load).
I also tried creating the ~/.vim/after directory and putting my
VimScript in there, but this had no effect.
Your attempts
set runtimepath=$VIMRUNTIME,~/.vim/nosmd.vim
That cannot work. 'runtimepath' contains a list of root configuration directories; you cannot directly place script files in there. Instead, point to a directory that contains plugin/yours.vim.
I also tried creating the ~/.vim/after directory and putting my VimScript in there, but this had no effect.
You can check with :scriptnames to see whether your script was executed (and at the end of the plugin load sequence!)
Solutions
An ounce of prevention is better than any workaround. I would first try to locate the culprit who changes the 'showmode' option; a plugin shouldn't do this (or at least have a configurable option to disable it).
:verbose set showmode?
might already tell you who changed this setting.
As #romainl already commented, ~/.vim/after/plugin/myplugin.vim should work for undoing this. If it doesn't try the following autocmd (in your ~/.vimrc) as a last resort:
autocmd VimEnter * set noshowmode
I have a mapping in my .vimrc file to map F2 to save a file. Have done this for years. However now the system administrator has decided to override my setting with one of their mappings. If I run :scriptnames I see the order and I know which one is the offending script.
Is there a way to just ignore one startup script? I also tried creating a .vim/after/fixit.vim file which re-did the mapping but that file does not get read.
I know I could ignore all files and just load my .vimrc but I do want some of the administrator's defaults, just not all.
You can only avoid sourcing of a script if it uses the canonical inclusion guard:
:if exists('g:loaded_pluginname') | finish | endif
But it probably doesn't.
Your idea with .vim/after/fixit.vim is a good one (you haven't posted your :scriptnames output, so I can't tell for sure), but you need to include the plugin subdirectory there, too:
.vim/after/plugin/fixit.vim
Finally, as a last resort, you can define an :autocmd VimEnter (in your ~/.vimrc). That autocmd will fire after all other initializations, so you can definitely change the offending mapping in there.
I'm after a means by which I can add additional commands to a text file via vim. For example, just as you can do something like this:
# vim:syntax=foo
I'd like to do something like:
# vim:option call matchadd('Special', '\(REQUIRED\|OPTIONAL\)')
Any ideas? I know I can write a syntax file, but this is not what I'm after for now.
Vim modeline syntax (see :help modeline) is not intended to specify commands
to execute during file opening. That is exactly what autocommands is for (see
:help autocommand). What you are trying to do should be an autocommand
similar the following.
autocmd FileType foo call matchadd('Special', '\(REQUIRED\|OPTIONAL\)')
or
autocmd BufReadPost *.foo call matchadd('Special', '\(REQUIRED\|OPTIONAL\)')
(Here instead of *.foo you can use any pattern that matches path or filename
(or both) of the target file.)
If the configuration you are setting up is local to some files or a project,
and you don't want to pollute your .vimrc with those autocmds, use
localvimrc plugin. It allows you to have a "local" .vimrc file next to
your target file or project folder. Script stored in that .lvimrc is
executed when you open files in the same directory where the "local" .vimrc
is, or in its subdirectories. Autocommands shown above (or any other
configurations) can be stored in a .lvimrc file local the project. For
details about localvimrc configuration see the homepage of the plugin.
This isn't an answer to your question, but I have also searched for Truth, and this question here is the closest one to it:
Vim: How to execute selected text as vim commands
It isn't automatic, but potentially only one keypress away it's close enough. :)
My ModelineCommands plugin extends Vim's built-in modelines to execute any Ex command(s) when a file is opened. A set of configurable validators examine the commands and can verify the correctness of an optional command digest, in order to prevent the execution of potentially malicious commands from unknown sources. (That's the main reason why Vim doesn't offer this feature!) This way, you could restrict the commands to only simple :let, or have the plugin query you to confirm execution of anything that isn't signed with your own secret key.