| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Way better, and more generally useful.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Rearranging order where logical, adjust comments, remove line
continuation guard and just join all relevant lines.
|
|
|
|
| |
And add .vim/script.vim, to be composed in the next commit
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Otherwise, the line-continuation in the ~/.vimrc fails if compatibility
mode survives the invocation step, for example if the vimrc file is
sourced directly with the -u option, or if vim is invoked as "ex".
|
|
|
|
|
|
|
|
|
|
| |
From :help mapleader:
> Note that the value of "mapleader" is used at the moment the mapping
> is defined. Changing "mapleader" after that has no effect for already
> defined mappings.
So the order of evaluation matters.
|
|
|
|
|
|
|
|
|
|
|
| |
The Google VimScript Guide says:
<https://google.github.io/styleguide/vimscriptfull.xml#Portability>
> Always use case-explicit operators for strings (=~# and =~?, never =~).
>
> This also applies to !~ == != > >= < and <=
> This only applies for strings. == and >= are fine for numbers, but ==#
> and >=# must be used for strings.
|
|
|
|
|
| |
This setting is already in vim/config/encoding.vim, having been copied
there in 505a2c2; it was intended to be moved rather than copied.
|
|
|
|
|
|
|
| |
There aren't actually any characters outside ASCII in any of the
configuration, and for this to work they would need to have the
`scriptencoding` at the head of that file, not at the top of the
`.vimrc` as here, so I've just removed it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vim-vint says:
>Do not use nocompatible which has unexpected effects (see :help
>nocompatible)
I can't actually find anything in the help item it references that says
that setting 'nocompatible' is bad, but the situation in which it's
needed is very niche anyway; per the removed comment:
>Don't make any effort to be compatible with vi, use more sensible
>settings. This is only here in case this file gets loaded explicitly
>with -u; the mere existence of a ~/.vimrc file already turns this off.
We'll just leave it out, and see if anything bad happens..."if in doubt,
rip it out".
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got a set of warnings from vim-vint about using just "==" for these
comparisons:
>Use robust operators `==#` or `==?` instead of `==` (see Google
>VimScript Style Guide (Matching))
It does seem a lot more sensible to be explicit about case sensitivity,
and not to lean on the configured 'ignorecase' value, especially if the
user changes it.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for config in vim/config/syntax.vim that will do
a more comprehensive job of applying heuristics to figure out if the
background is light or dark and hence what colours should be loaded for
the appropriate scheme.
The test for the GUI or 256 colours is repeated in the colorscheme code
itself, but I think that's OK given that sahara.vim is distributed
separately and others probably wouldn't use the kind of guards
introduced in this commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per this suggestion from the `vim-pathogen` FAQ:
<https://github.com/tpope/vim-pathogen#faq>
>>Can I put pathogen.vim in a submodule like all my other plugins?
>
>Sure, stick it under `~/.vim/bundle`, and prepend the following to
>your vimrc:
>
> runtime bundle/vim-pathogen/autoload/pathogen.vim
This method avoids using symbolic links, which is desirable in general,
and also removes the need for the `install-vim-pathogen` dependency of
the `install-vim-plugin` target, since this is now done in Vim
configuration.
This also takes away another of the steps required for setting up the
Vim configuration on Windows.
|
|
|
|
|
|
|
| |
This is an awkward filename and very unlikely to ever have anything but
this one setting in it, but I can't think of any logical other place to
put it. number.vim applies to line numbering, which is a distinct
concept.
|
| |
|
|
|
|
|
|
| |
This is an awkward filename and very unlikely to ever have anything but
this one setting in it, but I can't think of any logical other place to
put it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Just the 'shortmess' setting for now.
|
|
|
|
|
|
|
|
|
| |
Some refactoring is done here, because as noted in 5caa13c, my custom
colorscheme is implemented as a plugin to be loaded by Pathogen, and
hence isn't available into after it's done its work.
I've removed the :set background line for now until I'm sure it's
needed, because at the moment I'm not sure.
|
|
|
|
|
|
| |
Only one setting at the moment, but there's enough completion stuff even
just in core Vim that I'm barely using, so this could be expanded upon
later on.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Not completely sure this grouping is meaningful; I may refactor it a bit
more later on.
|
|
|
|
|
|
| |
"Matching" here refers to using % as a motion to the matching character
or closing statement for a block, as enabled by Vim and enhanced by the
optional matchit.vim included with the distribution.
|
| |
|
| |
|
|
|
|
|
| |
A little bit iffy on the grouping here, but it's still better than
having it all lumped in the one file.
|