aboutsummaryrefslogtreecommitdiff
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Add install target for vim-vintTom Ryder2017-12-081-0/+4
|
* Use :compiler scripts for makeprg setupTom Ryder2017-11-191-0/+6
| | | | | | | | | | | | 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.
* Add Makefile targets for Vim plugin distsTom Ryder2017-11-141-2/+89
| | | | | | | | 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.
* Move lots of local Vim config into vim/afterTom Ryder2017-11-121-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add user_ftplugin.vim and user_indent.vim pluginsTom Ryder2017-11-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge branch 'feature/spin-vim-plug' into developTom Ryder2017-11-041-0/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * Specify an install-vim-autoload targetTom Ryder2017-11-041-0/+6
| | | | | | | | | | We'll use this for defining Vim functions that should be dynamically loaded when required, rather like how pathogen.vim does it.
* | Add ~/.tidyrc and accompanying Makefile targetTom Ryder2017-11-041-0/+5
|/ | | | | | | | | 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.
* Move Vim big file options config into pluginTom Ryder2017-11-021-1/+11
| | | | | | | | | | | 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.
* Add dfv(1df) version-printing toolTom Ryder2017-11-011-0/+4
| | | | | | | | | | 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.
* Check and lint URxvt Perls correctlyTom Ryder2017-10-311-1/+1
| | | | | | 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.
* Apply stable check and lint methods to games shellTom Ryder2017-10-311-1/+1
| | | | | | | | | | | | | 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.
* Adjust `check-bin`, `lint-bin` for built scriptsTom Ryder2017-10-311-1/+1
| | | | | | | | | | | | | | | | 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.
* Add a `lint-vim` target for linting Vim configTom Ryder2017-10-301-0/+5
| | | | | | | | | 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.
* Remove vim/after installation from vim/bundleTom Ryder2017-10-301-2/+9
| | | | | | | | | | | 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.
* Move vim/after/ftplugin files into vim/ftpluginTom Ryder2017-10-301-0/+6
| | | | | | | | | 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.
* Rename Makefile target for Vim plugin bundlesTom Ryder2017-10-301-9/+9
| | | | | | | | | 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.
* Move PHP indent nixing into ~/.vim/indentTom Ryder2017-10-301-0/+6
| | | | | | | | | 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.
* Move vim/after/ftdetect to vim/ftdetectTom Ryder2017-10-301-0/+6
| | | | | | | | | 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.
* Load Vim Pathogen with :runtimeTom Ryder2017-10-291-7/+1
| | | | | | | | | | | | | | | | | | | | 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.
* Restore dotfiles(7) manual as pre-built dist fileTom Ryder2017-10-291-0/+6
| | | | | | | | | | | | | | | | 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`.
* Set up .d-style vimrc subdir for config breakupTom Ryder2017-10-281-0/+2
| | | | | | | | | | | | 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.
* Break pks(6df) and philsay(6df) in twoTom Ryder2017-07-021-0/+1
| | | | | Looks like awk(1) implementations vary in how they interpret option arguments.
* Reimplement rndl(1df) in AwkTom Ryder2017-07-011-3/+0
| | | | | Removes the need for the temporary file. Also refactor pks(6df) to accommodate it.
* First attempt at pks(6df)Tom Ryder2017-07-011-0/+1
| | | | I've got a better idea, though
* Solve Pandoc issue by not building page at allTom Ryder2017-07-011-9/+0
|
* Add oii(1df)Tom Ryder2017-06-291-0/+4
|
* Revert "Allow MYSQL_* my.cnf vars"Tom Ryder2017-06-261-10/+1
| | | | | | | | This reverts commit bc204d546eacaf82ced744838cd5a06ff8bcdde0. Scratch that; this approach doesn't work because if the strings are empty from the Makefile macro, m4 still considers them defined. A different approach is needed here.
* Add dependency to install-mysql targetTom Ryder2017-06-261-1/+1
|
* Allow MYSQL_* my.cnf varsTom Ryder2017-06-261-0/+9
| | | | Experimental
* Correct silly error in MakefileTom Ryder2017-06-251-1/+1
|
* Add install-conf targetTom Ryder2017-06-251-0/+3
| | | | | | | Allows you to have a ~/.dotfiles.conf specifying targets to run in addition to `install`, e.g. `install-tmux` for applicable machines. Won't document this one just yet.
* Remove deprecated keyserver optionsTom Ryder2017-06-251-3/+1
| | | | | | | | | | | | | | | | | | | | > gpg: keyserver option 'check-cert' is obsolete > gpg: keyserver option 'ca-certfile' is unknown > gpg (GnuPG) 2.1.18 > libgcrypt 1.7.6-beta > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: /home/tom/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2
* Add a simple wgetrcTom Ryder2017-06-231-0/+4
| | | | Mostly use cURL admittedly, but these look sensible
* More segmentation/tidyingTom Ryder2017-06-181-4/+7
|
* Break plenv stuff into its own targetTom Ryder2017-06-181-1/+6
|
* Refactor mpd/ncmpcpp stuff completelyTom Ryder2017-06-181-1/+7
| | | | | | 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.
* Remove now-unused TMUX_BG/FG varsTom Ryder2017-06-151-3/+0
|
* Remove color/colour templating from tmux.confTom Ryder2017-06-151-8/+0
| | | | | | | | | | tmux 2.4 added support for globs, which makes all of this templating nastiness go away: <https://github.com/tmux/tmux/blob/master/CHANGES#L192> A user who wants custom settings (such as me on my work system) can just drop overrides into ~/.tmux.conf.d/something.conf and go home.
* Restore previous TMUX_BG/FG varsTom Ryder2017-06-151-2/+2
| | | | Bad decision
* Correct GTK3 rc pathTom Ryder2017-06-151-2/+2
|
* Refactor m4 macro namesTom Ryder2017-06-131-6/+10
| | | | mi5(1df) means I can simplify these quite a bit now
* Add fnp(1df)Tom Ryder2017-06-121-0/+1
|
* Makefile refactorTom Ryder2017-06-101-19/+21
| | | | | | Tried using the POSIX make on OpenIndiana and it got confused by the implicit dependencies, being a little more explicit seems to have coaxed it into working.
* Add rep(1df)Tom Ryder2017-06-031-0/+1
|
* Tidier implementation for mi5 shTom Ryder2017-06-021-9/+11
|
* Use mi5 to make templated shell scriptsTom Ryder2017-06-021-24/+53
|
* Move existing .m4 to .m4.mi5Tom Ryder2017-06-021-1/+7
| | | | Along with accompanying Makefile rules and .gitignorances
* Add mi5(1df)Tom Ryder2017-06-021-0/+1
|
* Add p(1df)Tom Ryder2017-05-281-0/+1
|