| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tiny builds of Vim that exclude the eval feature throw errors at the
:let commands in this file:
$ vim.tiny
Error detected while processing /home/tom/.vim/config/netrw.vim:
line 2:
E319: Sorry, the command is not available in this version: let g:netrw_banner = 0
line 5:
E319: Sorry, the command is not available in this version: let g:netrw_silent = 1
line 8:
E319: Sorry, the command is not available in this version: let g:netrw_liststyle = 3
line 11:
E319: Sorry, the command is not available in this version: let g:netrw_list_hide = '^\.$,^tags$'
Press ENTER or type command to continue
This code was not being run on such builds before commit 538b71c,
because it was in an "after" directory for the netrw plugin and would
have been skipped.
Wrapping a check for has('eval') around this whole file fixes the
problem. netrw.vim won't run without this feature anyway.
|
|
|
|
|
|
|
| |
Commit 92f2c78 added these suffixes to the option settings to show the
value of the option after it had been set, but this isn't actually
appropriate for the autocmd here; it means the value of 'hlsearch' is
echoed every time insert mode is entered or left.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* feature/vim-plugin:
Have bigfileturn local syntax off (configurably)
Make bigfile 'synmaxcol' setting configurable
Refactor plugin function for dependency injection
Rename variable and autocmd to use plugin prefix
Make bigfile size variable an option with default
Expand comment header for bigfile.vim
Move Vim big file options config into plugin
|
| | |
|
| |
| |
| |
| |
| | |
Defaults to 256 columns and only sets it if the option's value isn't
already lower than that.
|
| |
| |
| |
| |
| |
| |
| | |
Pass the filename to check and the size limit into the function directly
from the autocmd hook.
Improve commenting and spacing as we go.
|
| |
| |
| |
| |
| |
| | |
Just removing an underscore from the variable name so that
g:big_file_size becomes g:bigfile_size, and remove the "dotfiles" prefix
from the autocmd.
|
| |
| |
| |
| |
| | |
This arranges for g:big_file_size only to set itself to 10 MiB if the
variable is not already set, presumably by the user in their vimrc.
|
| |
| |
| |
| | |
Include some author and license metadata.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Created targets install-vim-doc and install-vim-plugin with accompanying
subdirectories of "vim".
Added a very short summary of what the plugin does to bigfile.txt.
I intend to spin off at least a couple of the blocks of my Vim
configuration that are starting to coalesce into distinct plugins unto
themselves, and will place the files in these directories.
|
| |
| |
| |
| |
| | |
Since it pertains to the casing of text, and there are potentially other
items that could go in here too.
|
| |
| |
| |
| |
| |
| | |
It makes more sense next to 'shellslash' in vim/config/command.vim than
it does in vim/config/term.vim; the latter file is supposed to describe
settings related to the terminal, not the shell.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
:help 'shellslash' says:
> 'shellslash' only works when a backslash can be used as a path
> separator. To test if this is so use:
> if exists('+shellslash')
This has actually already been done before in 795fd10, but the change
was lost in a merge with a branch that restructured the whole Vim
configuration.
|
|
|
|
|
|
| |
This was unintentionally committed in e36efd4. The correct name of the
variable is b:is_ksh. b:is_kornshell_proper was a rejected first
revision of the name.
|
|
|
|
| |
No functional effect.
|
|
|
|
|
|
| |
Just to be comprehensive, reinstate the global defaults for all the
indenting options via the indent/_GLOBAL.vim stub each time the filetype
is changed.
|
|
|
|
|
|
| |
This method of re-setting the numeric indent local options to their
global analogues looks a bit gross, but seems to work on much older
versions of Vim (6.2 in this testing).
|
|
|
|
|
| |
This setting is already in vim/config/encoding.vim, having been copied
there in 505a2c2; it was intended to be moved rather than copied.
|
|
|
|
| |
This was added in 52671ad, but not finished.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the very weird syntax:
:setlocal option! option?
We can toggle the option and print its new value in the same line. For
the line breaking options, we only show the value of the 'linebreak'
option, because otherwise we print three lines of messages, which
requires an <Enter> press, even if we put all three `option?` calls on
one :setlocal line.
|
|
|
|
|
|
|
|
| |
That is, \h and \i shouldn't change the value of the search highlighting
or incremental search features globally, just per-buffer.
I'm not actually completely sure I want this, but it does seem tidier at
the moment.
|
|
|
|
|
| |
Just in case somebody tried to use it to strip whitespace only from a
selected range. It could maybe be extended to do this somehow.
|
|
|
|
|
| |
It makes much more sense in this file than it did in the whitespace
configuration file.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a tidier method of preserving the cursor position after a
normal-mode join that doesn't involve wiping away a mark, though I don't
use those too often anyway.
It still works with a preceding count via the `v:count1` variable, with
an accidental feature: this joins the *next* v:count1 lines, as opposed
to joining a *total* of v:count1 lines counting the current one. The
latter is what Vim does, but the former is what I'd actually expect,
thinking of it as a "repeated operation", so I'm going to leave it this
way.
|
|
|
|
| |
Just for clarity of reading.
|
|
|
|
| |
Just to do one thing at a time.
|
|
|
|
| |
It's probably best not to use abbreviations in scripts.
|
|
|
|
|
| |
On looking at this again, I was uncomfortable with `eval`ing an
operation. This seems a bit less evil.
|
|
|
|
|
|
|
|
| |
Per Google's VimScript style recommendations
<https://google.github.io/styleguide/vimscriptguide.xml>:
> Always use case-explicit operators for strings (=~# and =~?, never
> =~).
|
|
|
|
|
| |
The actual option settings performed by the function are local, so the
test should be, too.
|
|
|
|
| |
Just to avoid duplication a little; seems a little clearer this way.
|
|
|
|
|
| |
Essentially just breaking up the big block comment at the top into
little pieces.
|
|
|
|
|
|
| |
Because this is a version-based check and shouldn't change any runtime,
we can just calculate it once as a variable local and persistent to this
script, and then store it for reference by the toggling function.
|
|
|
|
|
| |
It makes more sense to discuss how something wraps after configuring
whether it wraps at all.
|
|
|
|
|
| |
Don't change the value of these options for all buffers with the \w and
\b maps, just the current one.
|
|
|
|
|
|
| |
'linebreak', 'showbreak', 'breakindent', and 'breakindent' are only
relevant when 'wrap' is on, so it makes sense for their settings to be
grouped together.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to its existing functionality of removing trailing spaces
from the ends of lines, this change has the function remove lines at the
end of the file afterwards if they contain no non-whitespace characters,
based on its observations during the line iteration.
This uses the older VimL functions line() and col() in preference to the
newer winsaveview() and winrestview() to restore the cursor position
after the range :delete moves it, so that this will hopefully work even
on older versions of Vim; that is not yet tested.
I am surprised that there is no line deletion function to match e.g.
getline(), setline(), but it does seem to be the case:
<https://groups.google.com/d/msg/vim_use/TY9NmJXh8EU/iFjOUg68AekJ>
|
|
|
|
|
| |
No functional changes; this is just to make it a little clearer before I
add some more functionality to it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a slightly more verbose but more compatible `:while` loop to
accommodate very old versions of Vim that do not have `:for`.
Vim 6.2 gives the following terminal output when the `:for` version is
run:
Error detected while processing /home/tom/.vim/config/whitespace.vim:
line 13:
E193: :endfunction not inside a function
However, it accepts this new version with no complaint, and the function
seems to work properly.
|
|
|
|
|
|
| |
With the `scriptencoding` call that was in this file removed in 1834c08,
there's no longer anything that's sensitive to the order in which this
option is loaded relative to any other options.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Google VimScript Style Guide says
<https://google.github.io/styleguide/vimscriptguide.xml#Naming>:
>In general, use plugin-names-like-this, FunctionNamesLikeThis,
>CommandNamesLikeThis, augroup_names_like_this,
>variable_names_like_this.
Adjusted variable, function, and `augroup` names accordingly, including
setting script scope for some of the functions and their calls (`s:` and
`<SID>` prefixes).
Initially I tried using `prefix#`, but it turns out that this is a
namespacing contention for publically callable functions like
`pathogen#infect`, and none of these functions need to be publically
callable.
|
|
|
|
| |
This was mistakenly moved from the monolithic .vimrc file in 07fc8ce.
|
|\
| |
| |
| |
| |
| | |
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.
|