| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 directory was created in commit 4c46c80, but its contents haven't
been linted with `vint` until now.
|
|
|
|
|
|
|
| |
This ensures that new plugin code gets tested before being released.
We don't add the new vim/doc directory, as it's plain text rather than
VimL.
|
|
|
|
|
| |
I'm going to pretend this is a crucially important production fix, in
order to try out the "hotfix" part of the "Git flow" workflow.
|
|
|
|
| |
Just for consistency.
|
|
|
|
|
| |
This makes them more consistent with the work already done on the check
and lint scripts for the other targets.
|
|
|
|
|
|
|
|
|
| |
Use a positive list of things to check rather than just excluding
`bundle`; it's a little clearer what it's doing that way, and easier to
add paths to check rather than paths to exclude.
We also correctly leverage `vint` accepting multiple arguments, like
`shellcheck`.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Adding the option terminator "--" directly after the `set` call ensures
that all following arguments will be interpreted as new arguments for
the list.
This is probably not strictly applicable here, because the paths that
will be stacked up don't start with dashes by definition, but it's
likely good practice.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce each one to target only the dotfiles specifically for that shell,
as opposed to previously where for example the `check-sh` target was
checking shell shims in for `mpd` and `plenv`.
I'm still not completely sure that's the right approach, but it's at
least less conceptually muddy than what we had before.
Notably, the check and lint for Korn shell includes a single POSIX shell
script file in its `shrc.d` subdirectory, so that check is executed
separately.
|
|
|
|
| |
This is a little bit clearer and nicer to read, I think.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Use consistent variable names, and strip the correct suffix from the
Bash scripts on iteration.
|
|
|
|
|
|
| |
Both blocks are analogues of the POSIX checks, but are wrapped in a
conditional so that bash(1) doesn't become a hard dependency of the
default `make install` target.
|
|
|
|
|
| |
We add an `|| exit` short-circuit for the case of `shellcheck` exiting
non-zero.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I forgot that the `lint` tools here need to check the *built* files, and
that that's the reason the `perlcritic` check against the source .pl
file was failing.
While it's still true that it would be preferable to test the files
found in a deterministic order, this branch's attempt to address that
issue is pretty much nonsense and can be abandoned.
This reverts commit 196155499c04b2c2050302e6575f1bcbbed052f1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using find(1) to run the appropriate lint program over a set of files
allows us to be terse and deal a little more dynamically with new files
placed in the directories, but the downsides are that it's error-prone
and that the order of testing is not predictable, and we'd ideally like
the testing to be a little more deterministic than that.
Case in point: writing the code for this commit unintentionally
uncovered a longstanding issue where the URxvt Perl script `select.pl`
was actually not being checked at all, due to an unneeded exclamation
mark inverting the `-name` test for `*.pl` files. `select.pl` is
presently not passing `perlcritic --brutal` on my machine, and likely
has not been compliant since as early as commit 5000365 in March this
year:
>commit 500036564541ff2d65a7b2f6f6f556202d72d6ce
>Author: Tom Ryder <tom@sanctum.geek.nz>
>Date: Fri Mar 24 11:01:05 2017
>
> Lots of Makefile tidying
>
> ...
> * Favour find(1) calls over shell loops
> ...
This commit also more clearly delineates between the language being
"linted" and the target for which it's being linted. The latter is
likely more desirable. This needs clarification.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This has been neglected. Switch to per-user mpd process instantiated on
login via .profile.d. Cut back ncmpcpp config until I have time to write
one that's compatible with 0.8.
|
|
|
|
| |
I never use it
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
As part of a foray into more active use of ksh and derivatives.
|
|
|
|
|
|
| |
I know almost nothing about Yash yet, but reading the manual page on its
startup behaviour implies a little coaxing is necessary to make it play
nicely with my file layout.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Because it prevents testing directories, of course
|
| |
|
| |
|
|
Much nicer than having them embedded in the Makefile. Might do this for
some of the more complex install targets too. Or maybe all of them ...
|