After switching git branches, any files that existed on my previous branch raise an E211: File "path/to/file.txt" no longer available warning. I already know that and I find it very annoying that I'm warned about it every time I change the tab or pane that I'm focused on. Especially if I need to close 8 panes of files that no longer exist.
Is there any way to disable this warning or make it something that does not require any input to continue?
You can tweak Vim's default behavior via the :help FileChangedShell event.
This autocommand is triggered for each changed file. [...] If a FileChangedShell autocommand is present the warning message and prompt is not given.
Unfortunately, by defining an :autocmd (e.g. invoking a no-op like an empty :execute), you'll lose all the default functionality, and would have to re-implement parts of it (without the message on deletion) by inspecing v:fcs_reason. If the sledgehammer approach is fine for you, this will do:
:autocmd FileChangedShell * execute
Instead of *, you could enumerate all of your Git working copies, to make this a bit more targeted.
Related
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.
Whenever I make a new directory, copy, a file, etc. using netrw's mt mf mc commands (for example), or just d, my vim gets into a state where it will absolutely, by no means (known to me) be exited from.
Even if I try to type q! from the netrw directory view, I get:
E37: No write since last change
E162: No write since last change for buffer
Literally all I am left with doing is killing my terminal process.
Assuming I can't change the permissions in this environment. What options am I left with? Completely avoiding netrw for managing directories?
And I'm always seeing this kind of thing after editing files:
"NetrwTreeListing 1" [Not edited][readonly]
netrw creates and modifies hidden buffers.
A way out of the situation might be
autocmd FileType netrw setlocal bufhidden=delete
That can be placed in ~/.vimrc, then q! will let you out after netrw work.
This is via Tim Pope, https://github.com/tpope/vim-vinegar/issues/13#issuecomment-47133890 but there are other comments in that thread that that setting may not always work. Works here, but that is probably luck, very light newrw usage, and not bumping into some bufhidden on/off edge case yet.
That autocmd setting might delete a hidden modified buffer that means something someday, so take this as unexpert sledge hammer advice, no warranty expressed or implied.
All of a sudden, my Vim starts with specifying fdm=marker regardless of the following two specifications
In _vimrc, both in the beignning adn bottom, set fdm=manual;
Per file type, have specified set fdm=manual through the *.vim files found in ~/vim/vimfiles/ftplugin.
Same setting had been working well around a week ago, when I updated the _vimrc. However, I just notice today that "marker" had been speificed for no reason.
Any suggestion? I have tried to Grep all the presences of "marker" in the ~vimfiles directory. This turned to be an unreasonable job to do, as there are thousands of presences of marker.
I have also tried to specify the following in my _vimrc, which did not work at all.
autocmd BufEnter * silent! set fdm=manual
fdm=manual will always pop up regardless of what type of file I open, upon typing set fdm in the command line. (by pressing :).
I have just made my Vim available on Github under: https://github.com/llinfeng/Vim
All the best,
-Linfeng
This is only a partial answer:
A plug-in called "restore_view.vim" is causing the problem. Upon uninstalling it, both settings I've tried did the work.
My guess is that, while _vimrc and "*.vim" files in ~/ftplugin/ did get sourced, the "restore_view" plugin will restore the "old view", which includes the folding methods and formatoptions, at the very end of the sourcing process. Therefore, all the previous settings of fdm and formatoptions had been restored and the newly implemented ones cannot be applied.
Here goes the github mirror of this plugin:
https://github.com/vim-scripts/restore_view.vim/blob/master/plugin/restore_view.vim
As a solution to my post, simply removing the plugin will solve all the issues. However, it remains to be an open question of how to properly deploy the "restore_view" plugin. I have emailed the author for suggestion and will also start a new question on Stack Overflow.
I have enabled undodir, to keep track of changes I make even after I close my vim session.
I sometimes want to edit a file, make some changes, save it, then return to the original file of that session. (This might be one of the possible use cases)
If I had undodir disabled, I could simply keep hitting u until it showed me a message.
So I want undodir to be disabled in undo/redo by default, and I should have a command to enable it when needed.
All changes to the file must be tracked in either states, at all times.
Is this possible?
As far as I understand the documentation, only setting undodir does nothing unless undofile is set to true.
So, I assume that you want to activate undofile for certain files.
First thing that comes in mind is a modeline in order to set undofile to true for certain files. But unfortunately, this doesn't work.
The issue, however, is present on the vim developer mailing list and there was a fix provided in January: http://comments.gmane.org/gmane.editors.vim.devel/32896. This fix could be present in current sources; so if you'd like to try, grab the latest vim sources, build it and check if you could use a modeline for setting udf
Until there's an official version containing that fix, you could get around your issue using undofile.vim. Excerpt of it's description:
If you want 'undofile' only for certain files, you will notice that 'undofile' cannot be set in a modeline, or once the buffer is loaded (because an existing undo file will not be loaded then). Bram suggests to use a BufReadPre autocmd which sets 'undofile' before the buffer is loaded. This script does the steps for you.
I'm using c-support in Vim. One of it's features is the automatic comment expansion.
When I'm pasting code into Vim from an external editor, the comments are expanded (which gives me double-comments and messes up the paste - see below for example). I'd like to be able to disable the plugin, paste, then re-enable it, without relaunching Vim. I'm not sure if this is possible.
The SO questions here, here and here all describe methods to disable plugins, but they all require me to close Vim, mess with my .vimrc or similar, and relaunch; if I have to close Vim, I might as well cat file1 >> myfile; vim myfile, then shift the lines internally, which will be just as quick.
Is it possible to disable a plugin while running vim without relaunching, preferably in a way which allows me to map a hot-key toggle-plugin (so re-sourcing ~/.vimrc is alright; that's mappable to a hotkey [I imagine, haven't tried it yet])?
Messed up comments:
/*
* * Authors:
* * A Name
* *
* * Copyright:
* * A Name, 2012
* */
EDIT: It turns out you can :set paste, :set nopaste (which, to quote :help paste, will "avoid unexpected effects [while pasting]". (See the comments).
However, I'm still curious whether you can disable/enable a plugin as per the original question, so I shall leave the question open.
Insert ":set paste" then paste your code. After that insert :set unpaste
There is no general way of doing this without modifying plugin source. Some plugins (like all of mine) can add this feature (I have “unload” feature in my framework, but use it mainly for updating without restarting vim, not for temporary disabling something). What you can definitely do is to add a function call to each sourced plugin file that will save current vim state and also something that will do this after plugin was loaded (due to existance of finish, throw, try | <code with some error> you can’t just add this function at the end of the plugin), likely on VimEnter, FileType and Syntax events. Then you need to have a function that will revert changes done to the plugin and an s:Execute function definition in each plugin, like this:
function s:Execute_I_do_not_expect_function_with_this_suffix_to_be_defined_by_the_plugin_so_I_add_it_to_avoid_name_collisions(s)
execute a:s
endfunction
. This is needed to execute a line of code in the context of sourced script. By “state” that needs to be saved I mean
Mappings
Commands
Signs
Functions
Menus
Events (autocommands)
Syntax (likely to be empty before plugin run)
Options
Some vim, all global, buffer, tab and window variables
// Script-local variables. Though it is simple here: at the start of the script script-local scope is empty and all you need is to empty it when disabling.
For each item it is possible to revert changes done by plugin, but it is not that easy to code. And presence of <script> argument to mappings is not distinguishable with presence of nore, though they have different behavior.
If you want to write it, do not forget about the fact that if script is resourced, your code will be relaunched.
Also, note the SourcePre event. It will help with automatic addition of your lines to all plugins.
Do not forget that there are more places that can be modified and can’t be saved and restored easily or at all: filesystem, interpreters state, opened plugin buffers, etc.