| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This file is rather short; it may turn out to make more sense to put
these settings elsewhere a bit later.
|
| |
|
|
|
|
| |
The StripTrailingWhitespace() function should perhaps be its own plugin.
|
|
|
|
|
| |
By "list" here I am referring to options for Vim's 'list' display
setting, showing control characters visually.
|
|
|
|
|
|
| |
Also add a note to IDEAS.md for later to consider packaging this as a
proepr plugin, even if it doesn't actually leave the dotfiles repository
just yet.
|
|
|
|
|
| |
The ToggleFormatFlag function might actually be better implemented as
some sort of plugin.
|
|
|
|
|
|
| |
I'm not quite so sure about this one. The ToggleBreak() function might
actually be better in a plugin on its own. The rest of it makes sense
though.
|
|
|
|
| |
Not the operating system; Vim editor windows.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5dba4c.
The order of the configuration matters more for these settings, because
the "sahara" colorscheme is only available after loading it as a plugin.
I'll divest some other stuff that should be less sensitive to the order
in which it's loaded first, and then tackle this one afterwards.
|
|
|
|
|
|
| |
This appears to break my choice of syntax colorscheme; the order of
loading some of the previous directives in the configuration may have
been relevant.
|
| |
|
| |
|
|
|
|
|
|
|
| |
From :help :runtime:
> When [!] is included, all found files are sourced. When it is not
> included only the first found file is sourced.
|
|
|
|
|
| |
Interestingly, this does not seem to work, and this configuration
doesn't get loaded; I suspect the :runtime line is not quite right.
|