| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
For plugin-specific configuration.
|
|
|
|
|
| |
This will allow the Windows-specific stuff in my new auto_* plugins to
quote filenames correctly.
|
|
|
|
| |
For OS-dependent config.
|
|
|
|
| |
I never use it. May as well defer to the vi default.
|
| |
|
|
|
|
| |
'paste' is specific to the terminal only anyway.
|
| |
|
|
|
|
| |
Clearer filename and more consistent to use the noun.
|
|
|
|
| |
A little clearer and a needless abbreviation anyway.
|
|
|
|
| |
More likely to share options this way.
|
| |
|
|
|
|
|
| |
More accurate given the content, and more likely to have other options
set in it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
:help 'tabstop' says that setting it may be a bad idea:
> Note: Setting 'tabstop' to any other value than 8 can make your file
> appear wrong in many places (e.g., when printing it).
On thinking about it, it's actually probably better to show literal tabs
as eight screen spaces, as it will make it very obvious when there are
tabs in the file.
|
|
|
|
|
|
| |
The syntax highlighter flags this code with an error on the final square
bracket: `case $foo in [![:ascii:]]) ;; esac`, but that's all legal. I'm
not yet sure how to fix it, so will just turn the error group for now.
|
|
|
|
|
|
|
| |
These two changes coax syntax/sh.vim into realising that POSIX shell
does not specify 'until' as a builtin (that's a Bash/Ksh thing), and
that POSIX shell is able to nest 'while' loops within other blocks
(that's not a Bash/Ksh thing).
|
|
|
|
| |
This was causing nasty errors whenever I started editing a Perl file.
|
|
|
|
| |
We only want to remove the normal mode mapping, since that's all we set.
|
|
|
|
|
| |
I didn't realise that a null command at the front of .e.g '|cmd|cmd2'
printed the current line! Removed that.
|
|
|
|
| |
Unload all maps too, with silent! in case they don't exist.
|
|
|
|
|
|
| |
This is what was missing after I initially redefined these groups and
stopped all POSIX shell scripts thinking they were POSIX. The words now
highlight correctly when within control structures again.
|
|
|
|
|
| |
It's not a shell builtin in `dash`, but it is in `Bash`, and I kind of
think of it that way.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The defaults for these groups don't make much sense to me, so I
completely reset them.
This isn't quite complete yet; for some reason as soon as e.g. an IFS=
setting is contained in e.g. an "if" or "while" block, they don't
highlight correctly anymore. There's probably some other part of the
core syntax/sh.vim file I need to include here.
|
| |
|
|
|
|
| |
Just for legibility.
|
|
|
|
|
| |
Just to reduce the chance of colliding with existing buffer variable
names.
|
|
|
|
|
|
| |
syntax/sh.vim only uses the existence of these variables for its checks
and as far as I can see never their actual values, so let's not overdo
things.
|
| |
|
| |
|
|
|
|
| |
This was likely a copy-paste error.
|
|
|
|
|
|
|
|
|
|
| |
From :help ftdetect, item 2:
> 2. Create a file that contains an autocommand to detect the file type.
> Example:
> au BufRead,BufNewFile *.mine set filetype=mine
> Note that there is no "augroup" command, this has already been done
> when sourcing your file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than setting g:is_posix and working around core syntax/sh.vim's
ideas about Korn and POSIX shells, forego sh.vim's efforts to guess what
shell the system /bin/sh is entirely. It's irrelevant to me anyway,
since I'll often be writing shell scripts to run on an entirely
different system.
Instead, if we have a #!/bin/sh shebang reflected in the b:is_sh
variable set by core filetype.vim, and we don't have any other
buffer-level indication of what shell this is, assume it's POSIX,
because I very rarely write Bourne.
Then, after the syntax file is loaded, clear away all but one of the
resulting b:is_* variables.
I have a feeling this is going to end with me re-implementing this
syntax file, possibly as separate sh.vim, bash.vim, and ksh.vim files.
|
|
|
|
|
|
| |
I didn't realise that using asterisks for emphasis in VimL documentation
in the middle of a paragraph counted as a help tag. This was causing a
call to `:helptags ~/.vim/doc` to error out.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* feature/vim-plug:
Add user_ftplugin.vim and user_indent.vim plugins
Use b:undo variables correctly
Update <Leader>b mapping to use new mapping name
Add commands to copy_linebreak.vim
Give copy_linebreak.vim enable/disable funcs, maps
Add :FixedJoin command
Add :StripTrailingWhitespace command
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 09b83b6 and replaces it with a working version.
Because of the order in which the autocmd hooks run, the attempted
method of adding unloading instructions for my custom ftplugin and
indent rules to the b:undo_ftplugin and b:undo_indent doesn't actually
work.
This is because the custom rules for both groups from ~/.vim are sourced
*first*, before their core versions, so the changes the custom rules
made to b:undo_ftplugin and b:undo_indent are simply clobbered by the
core version when it loads itself.
Therefore we need to arrange for two things:
1. A custom variable needs to be checked and executed when the filetype
changes to revert the changes for the custom ftplugin or indent
rules.
2. That execution needs to take place *first* when the filetype
changes.
I wrote two simple plugins with very similar code that are designed to
run as a user's custom ftplugin.vim and indent.vim implementations,
running before their brethren in the Vim core, and setting up an autocmd
hook to :execute b:undo_user_ftplugin and b:undo_user_indent plugin
respectively.
This seemed to work well, so I've implemented it. It involves adding a
shim to ~/.vim/indent.vim and ~/.vim/ftplugin.vim to "preload" the
plugin when the `filetype indent plugin on` call is made. I've added
that to the relevant Makefile targets.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Setting or adding to b:undo_indent and b:undo_ftplugin variables, which
I only learned about just now, allows me to avoid the _GLOBAL.vim hack
and remove some files from both vim/indent/ and vim/ftplugin/.
These variables aren't subjected to :execute automatically in anything
older than Vim 7.0, but I don't think that's too much of a concern as
the only real reason they're needed are for changing filetypes in the
same buffer, which doesn't happen that often anyway.
|
| |
| |
| |
| | |
The name of this mapping was changed in commit 44bd9a8.
|
| |
| |
| |
| |
| |
| | |
Just to be thorough; if +user_commands are available, offer
:CopyLinebreakEnable, :CopyLinebreakDisable, and :CopyLinebreakToggle
commands.
|
| |
| |
| |
| |
| | |
Add s:CopylinebreakDisable() and s:CopylinebreakEnable functions, and
mapping targets for each of them, just to be thorough.
|
| |
| |
| |
| |
| | |
This is optiona; if the user's Vim doesn't have the 'user_commands'
feature, the command will just quietly not be created.
|
| |
| |
| |
| |
| | |
This is optional; if the user's Vim doesn't have the 'user_commands'
feature, the command will just quietly not be created.
|
| |
| |
| |
| |
| |
| | |
I think this option has become overloaded in recent versions and that
these would make more sense and be more manageable as separate but
interacting options.
|
| |
| |
| |
| | |
\d adds local time, \D adds UTC time.
|
|/ |
|