| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This prevents older versions of Vim like 6.2 from throwing "E1017:
Missing braces" on merely parsing this code, even though they don't
evaluate it.
|
|
|
|
|
|
|
|
| |
Renamed to flag_toggle.vim and placed in autoload using the namespaced
autoload function syntax.
I'm not sure this is the right approach yet, but I seem to pretty rarely
use a Vim earlier than 7.1 these days.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is an experimental new plugin that provides a command to toggle
individual single-character flags in an option with a value of a set of
such flags, in my case 'formatoptions'.
A fair bit of evil eval()ing via :execute here, but I've tried to
control it with some strict patern matching.
|
|
|
|
|
| |
Calling this one copy_linebreak.vim. Renamed both the internal function
and the plugin key.
|
|
|
|
|
| |
Again using the <Plug> mapping abstraction and not defining the mapping
for the user.
|
|
|
|
|
|
| |
This properly abstracts out the StripTrailingWhitespace mapping rather
than forcing it to <leader>x within the plugin itself. A bit nicer this
way.
|
| |
|
|
|
|
|
| |
Tentatively named command_typos.vim. I've just moved this as-is for now,
but it will need review, especially the hardcoded mappings.
|
|
|
|
|
| |
Looks like this was added in a1ee04d for v0.4.0 and was intended to
replace the file in its correct path at vim/config/comment.vim.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|