Configuration file about dvtm HOT 10 OPEN

Those workarounds are all great but they're not solutions that would make everything so much easier when deploying the software, not just using it on a single personal machine.

from dvtm.

I made a script to compile a programs in ~/.local from simple recipes with this format:

# single line description

tar=http://github.com/martanne/dvtm/master/archive.tar.gz

# This is optional: the default build function can build dvtm with custom config.h
build()
{
    cp ~/.config/dvtm/config.h ./config.h
    make PREFIX="$PREFIX" install
}

If you want to use local libraries, man pages and include headers, you have to source this very same script on your .profile.

You can add recipes in ~/.local/share/build, each one with the name of a package.

Here are my recipes.

Is this what you mean by wrapper srcipt?

from dvtm.

Ah, sorry my bad. Thank you for explaining.

from dvtm.

Could you be a bit more specific what you would like to store in such a configuration file? Why don't shell aliases or a simple wrapper script work for you? I assume your shell configuration file is already under version control, hence these should be easy to deploy?

Generally I'm hesitant to add the complexity for a configuration file parser. For smaller projects like dvtm compile time based configuration (i.e. config.def.h) using the C pre-processor should be sufficient. This also forces us to chose good default values. Besides that, the most important options are already runtime configurable via command line switches (e.g. -m ^a to the change the command key modifier). For projects which justify more extensive configuration (such as my editor) I settled for Lua. Again, this avoids a custom parser and gives you a lot of flexibility. However, for dvtm this is probably already overkill.

from dvtm.

I do versioning on a per-project basis, where all the tools I use have their own repository. I could add an alias to my shell's configuration file but like I said in my previous post I don't like to introduce aliases that have side effects (such as setting configuration variables, as opposed to making typing commands less hard).
Also if I were to deploy a particular configuration of dvtm on several machines with multiple users, things would be much easier if all I had to do was a pull of a repository dedicated to dvtm containing a custom dvtm.cfg, as opposed to modifying the configuration of all the available shells on the system (or compiling a customized version).

I could use a wrapper script, but it looks more like a consequence of not having a configuration file rather than an alternative to having one. That also makes it hard for multiple users to use the same program with different settings, so a configuration file would nullify those issues (which again occur because there's not configuration file).

I get where you're coming from, in theory a single user can get away with a compile-time configuration, but leaving that scope turns the lack of file-based user independent configuration settings into an inconvenience. Hence my proposal to have a configuration file in ${XDG_CONFIG_HOME}/dvtm/config. I'm particularly interested into the cmd-fifo option, it'd be convenient to provide a format used to generate a semi-random name for the FIFO (so that multiple instances of dvtm don't end up using the same command FIFO).

Cheers.

from dvtm.

vis has both a configuration file in lua, and default keybindings in the config.h. Maybe dvtm could have the same kind of configuration.

By adding more actions to the config.h, and creating the command FIFO by default. This would make a binary install of dvtm (through package manager) still customizable.

The tweaking of the config.h would still be useful to add more actions available in the startup file. Maybe even with contributions back to dvtm like for #35.

Maybe we could go with a simple shell script sourced at startup from dvtm-status after all FIFOs creation, with calls to some dvtm-cmd.

Their arguments would be executed by being piped through the dvtm command FIFO.

A shell script could even implement this all.

from dvtm.

I also like to version my configuration files with vcsh so I can deploy my dot files easily to a new system
...
things would be much easier if all I had to do was a pull of a repository
...
I could use a wrapper script, but it looks more like a consequence of not having a configuration file rather than an alternative to having one. That also makes it hard for multiple users to use the same program with different settings

If I understand correctly, a wrapper script would suit your use case perfectly fine; the problems you've stated only apply if you create a system wide wrapper. You can, of course, just create a wrapper for dvtm that exists in your versioned dotfiles and will be just as easy to pull as a config file.

Add a folder .bin to your dotfiles and add that folder to PATH in your .profile. Create your dvtm wrapper there. Now you have a config in your dotfiles which does not require recompiling or otherwise intefering with a multi-user system.

from dvtm.

Or you can also have dvtm compiled and installed in ~/.local/bin or equivalent and backup your config.h in your dotfiles.

And it’s not like dvtm is big (60~90K for amd64) and takes time to compile(less than 1s).

from dvtm.

Going by your own mention of using a wrapper script, I had assumed you were using vanilla dvtm. If that's the case, my suggestion is the literal equivalent of a config file; it is just as easy as having a config.

If you're not using vanilla dvtm, backing up your dvtm binary in dotfiles as @lanodan suggested is just as easy as a config, too.

I also consider the 'ease of deploying' a program from source the responsibilty of your distro build environment. With something like ArchLinux ABS or FreeBSD ports, I can use a config.h as easily as I can use a config.

There are enough solutions to this problem; I don't think it's worth the added complexity or dev time to implement configs.

from dvtm.

When I say 'vanilla dvtm in a wrapper script' I mean installing dvtm from your distro's package manager, and placing a script named 'dvtm' on your PATH which contains your preferred switches.

$HOME/.local/bin/dvtm

#!/bin/sh
/usr/bin/dvtm -M "$@"

I do this with dmenu https://github.com/Link-Satonaka/dotfiles/blob/master/common/home/user/.bin/dmenu

from dvtm.