| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| | |
The Vim configuration, excluding the submodule plugin bundles, now
passes a strict run of the vim-vint tool. There's also now a `lint-vim`
target in the Makefile.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
vim-vint says:
>Do not use a command that has unintended side effects (see Google
>VimScript Style Guide (Dangerous))
>Avoid commands that rely on user settings (see Google VimScript Style
>Guide (Fragile))
In both cases, it's referring to the use of :substitute in this file.
The Google style guide on which vim-vint is based says <https://google.github.io/styleguide/vimscriptguide.xml?showone=Fragile_commands#Fragile_commands>:
>Avoid :s[ubstitute], as its behavior depends upon a number of local
>settings.
It also says <https://google.github.io/styleguide/vimscriptguide.xml?showone=Dangerous_commands#Dangerous_commands>:
> Avoid using :s[ubstitute] as it moves the cursor and prints error
> messages. Prefer functions (such as search()) better suited to
> scripts.
>
> For many vim commands, functions exist that do the same thing with
> fewer side effects. See :help functions() for a list of built-in
> functions.
I reimplemented the function based on an answer I found by `romainl` to
a similar question: <https://vi.stackexchange.com/a/5962>
There are plenty of other trailing-whitespace-stripping solutions out
there, but this one can be mine. It now passes vim-vint. I'll make a
plugin out of it at some point.
The \m\C shibboleth at the front of the regular expression is to enforce
the 'magic' setting for the regular expression, and to enforce
case-sensitivity. This is recommended by the style guide:
<https://google.github.io/styleguide/vimscriptguide.xml?showone=Dangerous_commands#Regular_Expressions
> Prefix all regexes with \m\C.
>
> In addition to the case sensitivity settings, regex behavior depends
> upon the user's nomagic setting. To make regexes act like nomagic and
> noignorecase are set, prepend all regexes with \m\C.
>
> You are welcome to use other magic levels (\v) and case sensitivities
> (\c) so long as they are intentional and explicit.
Before I committed this, I checked with vint -s to include stylistic
recommendations as well, and it insisted on l: prefixes to the `li` and
`line` variable to make them explicitly local to the function, so I did
that, too.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
vim-vint says:
>Avoid commands that rely on user settings (see Google VimScript Style
>Guide (Fragile))
The style guide explains:
>Always use normal! instead of normal. The latter depends upon the
>user's key mappings and could do anything.
Can't argue with that...
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
vim-vint says:
>Prefer single quoted strings (see Google VimScript Style Guide
>(Strings))
Perl::Critic warns about a similar thing; don't use doublequotes if you
don't need to expand e.g. \n, \r or interpolate variables. Makes sense
to me.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 was mistakenly moved along with some indentation settings in
9858af6.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had four spaces, but with a 'shiftwidth' of 2, 6 is the conventional
value.
From :help ft-vim-indent:
>For indenting Vim scripts there is one variable that specifies the
>amount of indent for a continuation line, a line that starts with a
>backslash:
>
> :let g:vim_indent_cont = &sw * 3
>
>Three times shiftwidth is the default value.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the rule setting the custom b:is_ksh variable used for this
workaround (established in 52615f6) into an ftplugin file, rather than
into ftdetect; the latter seems a much more appropriate place since by
this point we've definitely decided the file type is "sh".
From the revised comment in this changeset:
>Setting g:is_posix above also prompts Vim's core syntax/sh.vim script
>to set g:is_kornshell and thereby b:is_kornshell to the same value as
>g:is_posix.
>
>That's very confusing, so before it happens we'll copy b:is_kornshell's
>value as determined by filetype.vim and ~/.vim/ftdetect/sh.vim into a
>custom variable b:is_ksh, before its meaning gets confused.
>
>b:is_ksh as a name is more inline with b:is_bash and b:is_sh, anyway,
>so we'll just treat b:is_kornshell like it's both misnamed and broken.
>
>We can then switch on our custom variable in ~/.vim/after/syntax/sh.vim
>to apply settings that actually *are* unique to Korn shell and its
>derivatives.
|
| |
|
|
|
| |
This and the other files in the now-removed vim/after/ftdetect directory
were moved to vim/ftdetect in f8af47b.
|
| | |
|
| |
|
|
|
|
| |
These trailing equals signs were vestigial from an attempt in f33111b to
use what I thought was a backwards-compatible syntax for resetting a
local option to its global state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
My old 6.2 version of Vim tolerates neither `option<` nor `option=`
syntax for resetting local versions of these options, so I'm just going
to have to guard against running those commands on ancient Vim for now.
They seem to work correctly on 7.0.
:setlocal shiftwidth<
Number required after =: shiftwidth<
:setlocal shiftwidth=
Number required after =: shiftwidth=
:setlocal shiftwidth=0
Argument must be positive: shiftwidth=0
|
| |
|
|
|
|
|
| |
For compatibility with older versions of Vim, string-based (not boolean)
options need to be reset with `setlocal option=`, rather than `<`. New
versions of Vim tolerate the latter for the string values, and do what
you meant.
|
| |
|
|
|
|
| |
This will mean the correct value is restored for filetypes that source
this file as part of their indent processing, and won't stay broken if
we switched from e.g. CSV or TSV.
|
| |
|
|
|
|
| |
Remove the duplicated code instated to use the global defaults for
indent-related options and put it into a common file to source with
:runtime.
|
| |
|
|
|
|
| |
I'm still getting used to the structure of the configuration here, and
had mistakenly put these indent-related settings into files in the
ftplugin directory.
|
| |
|
|
|
|
|
|
|
|
| |
For some languages in which I write often: C, HTML, Perl, PHP, and
shell scripts.
All of these values presently match the defaults specified in
config/indent.vim, but for languages I commonly use it's probably
appropriate to have files to set the indent settings explicitly anyway,
especially if we switched from a filetype with different values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vim does not seem to have any built-in detection or settings for CSV or
TSV files, so I've added a couple here, based on filename patterns
matching the .csv and .tsv extensions.
If either of these types are detected, the 'autoindent' and 'expandtab'
options are both switched off, as they're undesirable, especially in
TSVs where a literal tab is almost certainly what's intended.
Ideally, these same two setting would apply to any filetype not
otherwise categorisable, but I can't figure out a way to do that safely
yet; there was an attempt made in d3d998c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use this recommended syntax in the custom ftplugin settings.
Seems to be the recommended way to set filetype idempotently, and is
present even in very old Vim (6.2 tested).
From the Vim documentation for :setfiletype:
>Set the 'filetype' option to {filetype}, but only if not done yet in a
>sequence of (nested) autocommands. This is short for:
> :if !did_filetype()
> : setlocal filetype={filetype}
> :endif
>This command is used in a filetype.vim file to avoid setting the
>'filetype' option twice, causing different settings and syntax files to
>be loaded.
|
| |
|
|
|
|
| |
Use four spaces for the indent of lines that are continuations of the
previous line, using VimL's bizarre backslashed syntax, to keep them
distinct from the indentation to show control structures.
|
| |
|
|
|
|
| |
Put the patterns together with a comma to keep them in the same rule. I
suspect my original intention was to keep things clear, but this doesn't
seem so bad now.
|
| |
|
|
|
|
|
|
|
|
| |
Clear autocommand definitions for each of the ftdetect augroups with
`autocmd!` as the first command within them. This avoids ending up with
doubled-up autocmd definitions if the configuration file is re-sourced,
and is pretty standard good Vimscript practice.
It's done correctly elsewhere in my Vim configuration, for example in
config/undo.vim, but it's been unintentionally omitted here.
|
| |
|
|
|
|
|
| |
This requires more careful thought to avoid stale local options
(:setlocal) for appropriate filetypes.
This reverts commit d3d998c68c335b35525172c700ff958d5a016399.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a new buffer is created with no filename, it's often because I want
to paste text into it without being bothered by autoindent or tab
translation, and so I'd rather Vim just accepted the text as literal
input without trying to indent it for me.
Similarly, for CSV files or Vim help files, space-based automatic
indentation is undesirable or not meaningful. It's better to allow Tab
to insert literal tab characters in this case, especially if it's a
classic Unix-style tab-separated file.
However, these settings should definitely be set on buffers which
actually do have virtually any other filetype.
I don't really like that long `if` condition there--it might be better
to find some way to simulate a case/switch structure instead.
I originally wanted to include a "negative match" in the `autocmd`
definition, which I imagined looking something like this:
autocmd FileType '',csv,help,text call FileTypeIndentConfig(&filetype)
autocmd FileType !'',csv,help,text call FileTypeIndentConfig(&filetype)
However I can't find anything in the Vim :help or by searching online
that suggests this is possible. This function-based approach seems good
enough for now.
This hasn't been tested on old versions of Vim yet.
|
| |
|
|
|
|
|
|
|
| |
None of the settings in here need to be run after the core configuration
files are loaded, so I'll put them in a slightly more accessible or
logical place.
This adds a new target `install-vim-ftplugin`, and makes that a
prerequisite of the `install-vim` target.
|
| |
|
|
|
|
| |
Setting these options globally is probably what's been causing me to get
so confused by my indentation level changing to zero when editing other
files in the same Vim instance as a VimL file. This should correct it.
|
| |
|
|
|
|
|
|
|
| |
This method short-circuits the unwanted PHP expression-based indenting
configuration completely, rather than running it all and then undoing it
after the fact.
This involves creating a new direction ~/.vim/indent, and a Makefile
target install-vim-indent to copy everything into it.
|
| |
|
|
|
|
|
|
|
| |
There's no particular reason to run these file detection rules after the
plugins have run, so we'll put them in a more expected directory.
I've created a new Makefile target to install this,
`install-vim-ftdetect`, which is included as a prerequisite of the
`install-vim` target.
|
| |
|
|
|
|
|
|
|
|
| |
There's no particular need to set these options after netrw has loaded;
they can be set before it's loaded, and the plugin will still observe
them.
This empties the vim/after/plugin directory. It doesn't need to be
removed from the Makefile as there are no references to it; it was
installed by a glob cp(1).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On an ancient Vim (6.1), the block of code checking the value of
COLORFGBG does not work at all, raising the following error output:
Error detected while processing function DetectBackground:
line 3:
E117: Unknown function: split
E15: Invalid expression: split($COLORFGBG, ';')
line 6:
E121: Undefined variable: l:colorfgbg
E15: Invalid expression: len(l:colorfgbg) ? l:colorfgbg[-1] : ''
line 9:
E121: Undefined variable: l:bg
E15: Invalid expression: l:bg == 'default' || l:bg == '7' || l:bg == '15'
line 11:
:else without :if: else
line 13:
:endif without :if: endif
I'm unlikely to need such an ancient Vim very often, so I've simply
added an error guard around the block.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that this environment variable is kept and updated in tmux after
54553ae, we should be able to either configure terminals or explicitly
set it during startup if we want to use lighter terminals.
I'm much more comfortable with this than simply hardcoding it in the
configuration.
This doesn't solve the problem of carrying the environment variable over
an SSH session, however, but I'm not really sure there's a solution to
that besides configuring sshd(8) itself to accept these variables in
transit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
While it would be ideal to keep the indentation-related configuration in
the config/indent.vim file, that approach ends up double-loading
filetype.vim from the core, so we'll merge them into a single call in
config/file.vim instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Per 6ca11a5, I've confirmed I do still need this, otherwise the default
colorschemes (not sahara.vim) assume a bright background and show very
dark colours.
|
