naggie / dstask

Git powered terminal-based todo/note manager -- markdown note page per task. Single binary!
https://calbryant.uk/blog/dstask-a-taskwarrior-alternative/
MIT License
801 stars 47 forks source link

Config file #75

Closed ejiektpobehuk closed 3 years ago

ejiektpobehuk commented 3 years ago

There is a config file location discussion (#49) but no issue to discuss config itself. So here it goes 🚀

I see two main topics:

ps. I would really love to configure colors. pps. Imagine having different colors for different projects with direnv...

naggie commented 3 years ago

I think colours is the killer feature of a dstask config file. I'm unconvinced about allowing a choice of file format, yaml works fine and I'd rather not increase the code complexity/size for no real benefit.

ejiektpobehuk commented 3 years ago

I'm not sure there is any gain from writing cutom config parsing. We can use something like spf13/viper.

Dieterbe commented 3 years ago

regarding colors, i would suggest this approach: 1) a file per theme, where a theme defines all colors used and similar visualization settings 2) in the config file, you define which theme you want to use.

this way, people can easily share and diff themes, and you can easily try out many

i note that viper is fairly heavyweight. i presume we probably just want to read a simple file with some fields, so a simple toml library will do the job potentially we may want to allow to control some, or all, of the config values via environment variables. this is where a more advanced library starts to become relevant.

ejiektpobehuk commented 3 years ago

cristalhq/aconfig is a much lighter alternative to viper which still allows to get values from files, arguments, envs. Man-oh-man, I love the ability to override stuff with direnv

ghistes commented 3 years ago

To add my 2 cents as a new user:

In general I love the idea of configuration via environment-variables. No need for config-file parsing and all that could go wrong there. It's easy to say a config-file has a syntax-error. But if you want to provide proper error reporting that would be useful to the user it amounts to work - for what benefit?

So I would use something like (eg) DSTASK_P2_FG=red in the environment to configure the colours.

naggie commented 3 years ago
* Configuring the location of the repo would be nice, but if you want it somewhere else, I assume you could simply use a symlink.

Already supported with DSTASK_GIT_REPO (just not documented yet -- it's used by the tests)

* I cannot see any value in making the format configurable. It adds complexity for no benefit (at least I cannot see any). yaml is perfect (as would be toml or json or whatever). dstask is supposed to be opinionated and should have an opinion about the format. No need for any change here as far as I am concerned.

Yes I have no intention of supporting multiple configuration formats for that reason. In fact, I think environment variables may do considering there isn't (and won't be) much to configure.

* Configuring the colours would have a big benefit. But I think there is only a handful of colours to be configured - no need for a config-file.

So I would use something like (eg) DSTASK_P2_FG=red in the environment to configure the colours.

I was thinking something like how LS_COLOURS works. Maybe DSTASK_COLOURS=32:52:23:23:52:93 or something.

ghistes commented 3 years ago

Good idea. I would like to have a way to both configure the colours and to turn them off completely.

Mayby check if stdout is a tty.

If no tty => no colours. If tty and no DSTASK_COLOURS => use defaults If tty and DSTASK_COLOURS=... => use that If tty and DSTASK_COLOURS=none => no colours

Dieterbe commented 3 years ago

Maybe DSTASK_COLOURS=32:52:23:23:52:93 or something.

so cryptical. if we're going to have a config directory (as per XDG), then having a file that defines colors in a human friendly way has no real cost.

naggie commented 3 years ago

Sure, if we actually want a config file. I'm on the fence atm; though it does seem we'll eventually need one due to the number of options required; that said I'd rather not make dstask too configurable.

naggie commented 3 years ago

Closing as no need for a config file at present. Please open a separate issue for DSTASK_COLOURS

naggie commented 3 years ago

Oh, there is one https://github.com/naggie/dstask/issues/110