| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
Replace it with new plugin put_blank_lines.vim and new mappings to cycle
between open buffers: the only features from the plugin that I actually
use in recent memory.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Functionality merged into new plugin auto_cache_dir.vim.
|
|
|
|
| |
Renamed as uncap_ex.vim.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It's too complicated and confusing, and doesn't do enough to justify
wrecking Vim's own logic for doing this sort of thing. Better to just
say `:set background=dark` and be done with it.
This is the only one of my inline plugins with an `autoload` file, so we
can get rid of that, too.
Not worth packaging/publishing to www.vim.org.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
* hotfix/v0.34.1:
Bump VERSION
Remove stray echo from Vim plugin
|
| |
| |
| |
| |
| | |
This was probably left in during debugging. Because 'showmode' hides it,
it didn't get noticed.
|
|/
|
|
|
| |
This makes it explicit what the variable is for, in the same way as
s:cpoptions_save in vim/vimrc.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'showbreak' option is global and has no local value--that is, it's
not global-local--so `setlocal` actually just changes the global value,
and hence we can't "change back" using `setlocal showbreak<`. Instead,
keep the "normal" value in a script variable so that we can reliably
switch back to it.
This surprised me, as I had thought it was working, but I can't find
even an older Vim that behaves the way I expected it too. I suppose I
must just not have changed back often enough to actually notice.
|
|
|
|
|
| |
* commentary
* unimpaired
|
|
|
|
|
|
| |
No particular reason beyond preference; I think of these as properties
of the window itself, not the window-buffer pair, so it makes more sense
to me this way.
|
|
|
|
| |
I never use its normal function.
|
|
|
|
|
| |
Otherwise entering a Tab in insert mode inserts four spaces. I'm not
sure how I didn't notice this before.
|
|
|
|
|
| |
In practice, I don't actually use this; I do ^V^I, and I seldom need
literal tabs anyway. Better to leave the behaviour predictable.
|
|
|
|
|
| |
NeoVim v0.2.3-708-g77286915a no longer includes this option, and raises
an error if I try to set it.
|
| |
|
|
|
|
|
|
|
| |
Per the comment in the new file, this is to avoid loading in HTML
ftplugins as well, a curiosity of the stock ftplugin/php.vim file that's
probably a well-intentioned way of accommodating templated files with a
mix of PHP and HTML in them.
|
|
|
|
| |
Include the variable guard, just for completeness' sake.
|
|
|
|
| |
No longer applicable since pathogen.vim was removed in 3e2740f.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't have guards for old Vim, compatibility settings, or
repeat-reload checks, which is not very good, and means it spits errors
on old Vims about newer constructs like :finally, where all the other
plugins are well-behaved.
I was going to replace it with vim-easy-align, but that doesn't seem to
have a version or compatibility guard either, though it does have a
repeat-reload check which means I could probably shoehorn in a version
check before loading it, but even that seems a bit gross.
So, I might just leave lining things up nicely to the various tidy
scripts. Let's see how much I miss it.
|
| |
|
|
|
|
|
|
|
| |
Given that all of this is installed rather than symbolically linked,
there's not really any harm following the old mixed ~/.vim layout for
plugins. It's one less dependency and it makes the setup quite a bit
less complicated.
|
|
|
|
| |
This allows me to use line-breaking to keep the file readable.
|
|
|
|
|
| |
This makes the block work correctly when 'compatible' is set and 'C' is
in 'cpoptions'.
|
|
|
|
|
| |
This will mean they load correctly when the 'C' flag preventing
line-breaking is in 'cpoptions', and 'compatible' is set.
|
|
|
|
|
|
|
|
| |
It seems unlikely that I'll ever edit a MacOS encoded file in my
lifetime on the Unix and Windows systems to which these dotfiles are
deployed, and when 'compatible' is set, the default empty value for this
option breaks everything with a bunch of ^J characters in every
god-fearing file. Not worth the trouble.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order for the configuration to be successfully loaded, the only
option in the vi 'cpoptions' settings for 'compatible' is "C". From
:help 'cpoptions':
> C Do not concatenate sourced lines that start with a backslash.
> See line-continuation.
With this flag removed from 'cpoptions' if 'compatible' does happen to
be set, the configuration parses just fine, and then we can put it back
at the end if we need to.
This is a less aggressive approach than just turning off 'compatible'
entirely if it happens to be set, whether because the user wanted it
that way before loading the configuration or because Vim was started as
ex(1).
My plugins and ftplugins are all conditional on 'compatible' not being
set, anyway.
|
|
|
|
|
| |
Don't claim that syntax files tend to assume 'autoindent' is set, as it
doesn't seem to be true.
|
| |
|
|
|
|
|
|
|
|
|
| |
Per an oft-made recommendation on /r/vim .vimrc review threads:
<https://www.reddit.com/r/vim/comments/6znskl/vimrc_review_thread/dnbmvxv/>
> Re-sourcing the vimrc won't clobber any of your personal highlight
> settings and the if part helps avoid unneeded re-execution/reprocessing.
|
|
|
|
| |
No functional changes here, just removing a little duplicate code.
|
|
|
|
|
| |
The things they were intended to fix aren't actually that bad, on
review.
|
| |
|