Comments (10)
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.
Related Issues (20)
- A lot of strange problems with colors HOT 2
- A couple of patches HOT 1
- Delete key does not work in bash after using abduco to reconnect to dvtm HOT 3
- KEY_LEFT KEY_RIGHT and KEY_HOME don't work in separate st with abduco HOT 3
- Doesn't display all 256 colors, only 204 or 209 HOT 2
- attachaside patch HOT 6
- Call for Project Maintenance HOT 17
- Jump for backward/fordward (word) with ctrl+arrow key doesn't work. HOT 2
- Option to hide title bars HOT 2
- Segmentation faults HOT 6
- Building on OpenBSD
- Two Patches and Escape Questions HOT 1
- mod+c not creating a new window HOT 2
- Unable to change cursor type with escape sequences HOT 1
- Paste does not seem to work on OpenBSD
- Behavior when cmd is passed HOT 1
- Terminal colors change as I type when in dvtm HOT 1
- Anyone able to build on MSYS2 Windows 11 ?
- togglebar() doesn't work with #define BAR_POS BAR_OFF in config.h
- Large copy buffer deadlock
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dvtm.