5

One way to create a highlighted message is this: echohl WarningMsg | echo "Buffer changed!" | echohl None The first command selects a particular highlight mode for any subsequent echo calls. When echo is called the message will be displayed on the status line with approriate color and/or format (in my case white on yellow text). Don't forget the second ...


4

Choosing between plugin/ and autoload/ is a matter of how a plugin designer intends the plugin to be used. vim-plug is intended to be placed in autoload/ because it is initialized through functions named plug#[...]. vim-plug is not loaded and does nothing until you call one of these functions. This is a better practice than using plugin/ because if the ...


3

autoload plugins are sourced: either when we source them explicitly (like in :runtime autoload/fakeclip.vim) or when we call a function that starts in foo#bar#whatever(), it'll source autoload/foo/bar.vim, even if the function doesn't exist. So, if you want to define a variable in an autoload plugin, either use a dedicated interface: :call fakeclip#_init(...


2

Using 0read on BufNewFile actually works as expected, in fact the documentation for BufNewFile explicitly mentions using that event for loading a template or skeleton file. If we also rule out the other things that might have gone wrong there, then the most likely explanation is that 0read is working, but the contents of the buffer are later erased by ...


1

Untested, but my theory is that during startup the definition of a function (particularly using function!) causes vim to check if a function by that name is defined, and this in turn causes the autoload search. Feedback from contributors to vim would be welcome, in order to decide whether this is a bug or a feature.


Only top voted, non community-wiki answers of a minimum length are eligible