| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
No advantage to making them autoload
|
|
|
|
|
|
|
|
| |
* Add a function to suspend autoformatting for the duration of pasting
lines.
* Factor the ftplugin's functions out to be autoloaded; this requires
Vim >=7.0, but it already needed that.
* Add Makefile infrastructure for new autoload directories/files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements only the syntax highlighting for file types I regularly
use and care about, implemented in the way I want them to work, with
files named per type in ftdetect/*.vim.
I have chosen only file types with which I regularly deal and for which
syntax highlighting and filetype/indent plugins are actually useful.
Most other files, e.g. system config files I edit infrequently and only
with sudoedit(8), don't really benefit from that.
Much of this is just copied from the distribution filetype.vim file, but
some of it I do specifically in a way I want, such as the shell decision
logic.
We'll see how well this works.
|
| |
|
|
|
|
|
|
| |
Intelligently choose how to load matchit.vim, and clean up the
short-circuit variables for the unwanted distribution plugins in an
"after" plugin script.
|
| |
|
|
|
|
| |
Functionality merged into new plugin auto_cache_dir.vim.
|
|
|
|
| |
Renamed as uncap_ex.vim.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It's too complicated and confusing, and doesn't do enough to justify
wrecking Vim's own logic for doing this sort of thing. Better to just
say `:set background=dark` and be done with it.
This is the only one of my inline plugins with an `autoload` file, so we
can get rid of that, too.
Not worth packaging/publishing to www.vim.org.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
A cursory test suggests that all of this configuration works well on
Neovim, or at least the bad stuff is gracefully ignored. Allow changing
the destination path for ~/.vimrc and ~/.vim/config to suit Neovim's
paths, including some instructions and some bloviating in README.md.
|
| |
|
|
|
|
|
|
|
| |
Per the comment in the new file, this is to avoid loading in HTML
ftplugins as well, a curiosity of the stock ftplugin/php.vim file that's
probably a well-intentioned way of accommodating templated files with a
mix of PHP and HTML in them.
|
|
|
|
|
|
| |
Create the plugin directory hierarchy first, and then copy the files in
as long as they're at least one file deep. This prevents files like
README.markdown landing in ~/.vim.
|
|
|
|
| |
It was mistakenly removed in 3e2740f for v0.26.0.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Old versions of gpg(1) don't support "none" as a --keyid-format; allow
specifying it as a Makefile variable KEYID_FORMAT.
|
|
|
|
| |
The manual page for gpg(1) says this is the safest way to do it.
|
|
|
|
|
|
| |
Newsbeuter is no longer maintained:
<https://github.com/akrennmair/newsbeuter/commit/7c981f460d6c8c3690f140cbb279c277dc8f55fe>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I didn't know about :compiler until now. From :help
write-compiler-plugin:
> A compiler plugin sets options for use with a specific compiler. The
> user can load it with the |:compiler| command. The main use is to set
> the 'errorformat' and 'makeprg' options.
Vim even has "perl" and "tidy" compilers already that seem to work
really well. I'll just add in my own and install them.
|
|
|
|
|
|
|
|
| |
This is just an experiment to see how well an automated process can make
independently distributable versioned tarballs of my Vim plugins.
These are not part of the default `all` or `install` target. They create
distribution vim-$name-$ver.tar.gz files in vim/dist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a relatively drastic change that should have been done
progressively, but I got carried away in ripping everything out and
putting it back in again.
Reading the documentation for writing a Vim script (:help usr_41.txt), I
am convinced that all of the content that was in the vim/ftplugin
directory and some of the vim/indent directory actually belonged in
vim/after/ftplugin and vim/after/indent respectively.
This is because the section on filetypes makes the distinction between
replacing the core filetype or indent plugins and merely adding to or
editing them after the fact; from :help ftplugin:
> If you do want to use the default plugin, but overrule one of the
> settings, you can write the different setting in a script:
>
> setlocal textwidth=70
>
> Now write this in the "after" directory, so that it gets sourced after
> the distributed "vim.vim" ftplugin after-directory. For Unix this
> would be "~/.vim/after/ftplugin/vim.vim". Note that the default
> plugin will have set "b:did_ftplugin", but it is ignored here.
Therefore, I have deleted the user_indent.vim and user_ftplugin.vim
plugins and their documentation that I wrote, and their ftplugin.vim and
indent.vim shims in ~/.vim, in an attempt to make these plugins
elegantly undo-ready, and instead embraced the way the documentation and
$VIMRUNTIME structure seems to suggest.
I broke the ftplugin files up by function and put them under
subdirectories of vim/after named by filetype, as the 'runtimepath'
layout permits. In doing so, I also carefully applied the
documentation's advice:
* Short-circuiting repeated loads
* Checking for existing mappings using the <Plug> prefix approach
* Avoiding repeated function declarations overwriting each other
* Guarding against 'cpotions' mangling things (by simply
short-circuiting if 'compatible' is set).
I've made the b:undo_ftplugin and b:undo_indent commands less forgiving,
and append commands to it inline with the initial establishment of the
setup they're reversing, including checking that the b:undo_* variable
actually exists in the first place.
For the indentation scripts, however, three of the four files originally
in vim/indent actually do belong there:
1. csv.vim, because it doesn't have an indent file in the core.
2. tsv.vim, because it doesn't have an indent file in the core.
3. php.vim, because it does what ftplugins are allowed to do in
preventing the core indent rules from running at all.
The indent/vim.vim rules, however, have been moved to
after/indent/vim.vim, because the tweaks it makes for two-space
indentation are designed to supplement the core indent rules, not
replace them.
Finally, I've adjusted Makefile targets accordingly for the above, given
the vim/ftplugin directory is now empty and there are three new
directories in vim/after to install. We wrap these under a single
`install-vim-after` parent target for convenience. The
`install-vim-after-ftplugin` target accommodates the additional level of
filetype directories beneath it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* feature/spin-vim-plug:
Rename toggle plugin again, use commands not funcs
Add short documentation for new custom plugins
Use same comment boilerplate for custom plugins
Check 'eval' feature for loading command_typos.vim
Wrap detect_background.vim func call in 'silent!'
Rename and refactor option toggle plugin
Don't suggest mappings in Vim plugin comments
Move Vim background detection logic into plugin
Specify an install-vim-autoload target
Spin 'fo' toggle out into new flag toggler plugin
Spin copyable linebreak config into new plugin
Spin stable join config out into new plugin
Use <Plug> prefix, make space strip configurable
Rename a misnamed variable in big_file.vim
Rename bigfile plugin to big_file
Move trailing space strip config into plugin
Separate command typos config to plugin
|
| |
| |
| |
| |
| | |
We'll use this for defining Vim functions that should be dynamically
loaded when required, rather like how pathogen.vim does it.
|
|/
|
|
|
|
|
|
|
| |
This target also installs a short shell script in ~/.profile.d to set
and export the HTML_TIDY environment variable that defines the path to
the configuration file. tidy(1) seems to need this to be explicitly set
with a default build, as far as I can tell.
This pairs nicely with the settings in vim/ftplugin/html.vim.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
This is mostly just for fun, but could be handy later on when I'm
playing with distributed or automated deployments of tagged and verified
releases.
Like a few of the other shell scripts, this is built by abusing my
mi5(1df) wrapper to get static details baked into the shell script that
are only known at runtime.
|
|
|
|
|
|
| |
Require that the URxvt Perls are built correctly. There's only one at
the moment, so I'll make that the single prerequisite for the
`check-urxvt` target.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies the same stable approach to testing the actual built
games that are shebannged with #!/bin/sh as has been applied to the
shell scripts in the `check-bin` and `lint-bin` targets.
There are no GNU Bash games in these directories, so the latter block of
code from the `bin` analogues to check or lint those is not needed.
The same applies here; this is not as complete a checking or linting of
the games directory as it could be; ideally we would check the sed(1)
and awk(1) scripts too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the `$(BINS)` target a prerequisite of `check-bin` so that all of
the scripts with a #!/bin/sh shebang are built, and then check them all
by iterating through a glob (and hence an order according to LC_COLLATE)
and stripping the `.sh` suffix to find the name of the matching
shebanged script.
Leverage `shellcheck`'s support of multiple check arguments to build an
argument list of the binscripts first before passing all of those to a
single call, simply for speed.
We don't have anything in this target to test the scripts of any other
type, such as the `.awk` or `.sed` scripts. `gawk` has a `--lint` mode
that might apply.
|
|
|
|
|
|
|
|
|
| |
Since I know there's a usable tool for this now in vim-vint, I may as
well make a target for my own convenience later.
Updated the README.markdown documentation of the `lint-*` targets,
restructuring the paragraph into a nested list for clarity. Also updated
the `dotfiles(7)` manual page to reflect those changes.
|
|
|
|
|
|
|
|
|
|
|
| |
The `install-vim-bundle` target shouldn't also be installing files in
vim/after; move that out into a separate target. We have to use a
couple of find(1) calls rather than a simple glob copy like e.g.
`install-vim-config`, because it's a multi-level hierarchy.
At present however there are only vim/after/syntax files left, which I
am pretty sure do actually need to run after the core syntax files are
loaded in order to correct or repair things I don't like.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
It's misleading to label this target as installing plugins when what it
actually does at a directory level is install the Vim plugin submodules
into ~/.vim/bundle for loading by Pathogen.
This also allows scope for an `install-vim-plugins` target to actually
install into ~/.vim/bundle, if I do need that at some point.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 70fcb35 incorrectly built the dotfiles(7) manual without the
header required by the Pandoc converter. Rebuilt it properly by making a
script in a new directory "dist" which is to be run by the maintainer
whenever its source file README.md is updated. This should probably be
automated on my end with Git hooks.
The reason we don't include the Pandoc recipe for making this manual as
a target in the Makefile is to do with the heavy dependency of Pandoc,
for which packages are not available on some desirable operating
systems, as arranged in a8ab2cf.
Also added the new install-man target as one of the default subtargets
of `install`.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before loading up all the plugins proper from ~/.vim/bundle with
Pathogen, apply :runtime to load all .vim files in a new config
directory, installed by the Makefile.
I hope that this will enable me to break most of my .vimrc up into
logically-arranged subfiles.
This is just a guess at a good way of doing this that will almost
certainly need refinement and restructuring later.
|
|
|
|
|
| |
Looks like awk(1) implementations vary in how they interpret option
arguments.
|
|
|
|
|
| |
Removes the need for the temporary file. Also refactor pks(6df) to
accommodate it.
|
|
|
|
| |
I've got a better idea, though
|