Add support for file based configuration #3

dnkl commented 2020年06月17日 20:03:50 +02:00

Currently, all configuration is done using command line options. This is fine as long as you only use fuzzel in a single context.

But, as we add more options, this approach falls apart.

So, let's add file based configuration (using normal Unix conf syntax). The existing command line options will remain, and if present will override the file based "default" configuration.

Currently, all configuration is done using command line options. This is fine as long as you only use fuzzel in a single context. But, as we add more options, this approach falls apart. So, let's add file based configuration (using normal Unix conf syntax). The existing command line options will remain, and if present will override the file based "default" configuration.

ifreund commented 2020年08月15日 13:31:51 +02:00

My solution to this is a fuzzel.sh script in my path which holds my configuration and passes along stdin and any arguments to fuzzel.

#!/bin/sh
fuzzel -f cozette:size=10 -T footclient -w 64 -b 002b36ff -t 839496ff \
	-m dc322fff -s 073642ff -B 2 -r 0 -C 839496ff $@ <&0

then the script can either be invoked directly, or used in a dmenu like fashion with

$ ls -l | fuzzel.sh -d

For me at least, this makes file-based configuration unecessary.

My solution to this is a `fuzzel.sh` script in my path which holds my configuration and passes along stdin and any arguments to fuzzel. ``` #!/bin/sh fuzzel -f cozette:size=10 -T footclient -w 64 -b 002b36ff -t 839496ff \ -m dc322fff -s 073642ff -B 2 -r 0 -C 839496ff $@ <&0 ``` then the script can either be invoked directly, or used in a dmenu like fashion with ``` $ ls -l | fuzzel.sh -d ``` For me at least, this makes file-based configuration unecessary.

dnkl commented 2020年08月15日 21:25:55 +02:00

@ifreund thanks! Perhaps it is time I added a wiki for fuzzel; that script would certainly be worth mentioning there.

Oh, and I see cozette is a bitmap font! That I have never heard of. Going to have to try it out :)

@ifreund thanks! Perhaps it is time I added a wiki for fuzzel; that script would certainly be worth mentioning there. Oh, and I see cozette is a bitmap font! That I have never heard of. Going to have to try it out :)

folliehiyuki commented 2021年03月08日 23:30:39 +01:00

I would suggest using an environment variable (for example FUZZLE_DEFAULT_OPTS) like fzf to define a default setting. Those can be overwritten by the the user if fuzzel is run with options that were defined inside the variable.
That can be another nice choice too, besides having a proper config file.

I would suggest using an environment variable (for example FUZZLE_DEFAULT_OPTS) like `fzf` to define a default setting. Those can be overwritten by the the user if `fuzzel` is run with options that were defined inside the variable. That can be another nice choice too, besides having a proper config file.

markstos commented 2022年01月04日 18:49:44 +01:00

I want to expand on the idea of the wrapper that @ifreund posted. I keep my configuration in a shell script I named fuzzel-configured that passes through additional arguments, like above:

fuzzel-configured

#!/bin/sh
fuzzel \
 --dpi-aware=no\
 --width=25\
 --font='Hack:weight=bold:size=36'\
 --background-color='282a36fa'\
 --selection-color='3d4474fa'\
 --line-height=50\
 --border-radius=20\
 $@

Then I have two more wrapper scripts-- one with args specific to dmenu mode and one with argumement specific to launcher mode.

fuzzel-dmenu

#!/bin/sh
fuzzel-configured --dmenu --no-run-if-empty

This dmenu script serves a second purpose as well. With it, I can create a symlink from dmenu to this binary, so it can handle scripts that expect dmenu to exist.

Fuzzel could make this smoother by recognizing when it has been called as a binary named dmenu and automatically enabled --dmenu mode in that case. This is a feature of Rofi.

fuzzel-launcher

#!/bin/sh
fuzzel-configured --show-actions

Working with and without configuration

In scripts, it's possible to check to see if there's a fuzzel wrapper present and if so use it:

_fuzzel_exec=fuzzel
if which fuzzel-configured &>/dev/null; then
 _fuzzel_exec=fuzzel-configured
fi

But a config file would still be nicer

The above pattern allows you to keep fuzzel configs in a single file, the wrapper file. But if the configuration could be loaded from ~/.config/fuzzel/fuzzel.conf, that would be a welcome convenience and standization.

I want to expand on the idea of the wrapper that @ifreund posted. I keep my configuration in a shell script I named `fuzzel-configured` that passes through additional arguments, like above: ## fuzzel-configured ```sh #!/bin/sh fuzzel \ --dpi-aware=no\ --width=25\ --font='Hack:weight=bold:size=36'\ --background-color='282a36fa'\ --selection-color='3d4474fa'\ --line-height=50\ --border-radius=20\ $@ ``` Then I have two more wrapper scripts-- one with args specific to dmenu mode and one with argumement specific to launcher mode. ## fuzzel-dmenu ```sh #!/bin/sh fuzzel-configured --dmenu --no-run-if-empty ``` This dmenu script serves a second purpose as well. With it, I can create a symlink from `dmenu` to this binary, so it can handle scripts that expect `dmenu` to exist. Fuzzel could make this smoother by recognizing when it has been called as a binary named `dmenu` and automatically enabled `--dmenu` mode in that case. This is a feature of Rofi. ## fuzzel-launcher ```sh #!/bin/sh fuzzel-configured --show-actions ``` ## Working with and without configuration In scripts, it's possible to check to see if there's a fuzzel wrapper present and if so use it: ```sh _fuzzel_exec=fuzzel if which fuzzel-configured &>/dev/null; then _fuzzel_exec=fuzzel-configured fi ``` ## But a config file would still be nicer The above pattern allows you to keep fuzzel configs in a single file, the wrapper file. But if the configuration could be loaded from `~/.config/fuzzel/fuzzel.conf`, that would be a welcome convenience and standization.

markstos commented 2022年01月12日 19:30:23 +01:00

For me at least, this makes file-based configuration unecessary.

With file-based configuration it would be easier themes, especially if there was an include-file syntax, so you could import a theme file that might be published by a third party and add some personal overrides.

Imagine a WM or DE that wanted to ship a themed version of Fuzzel

> For me at least, this makes file-based configuration unecessary. With file-based configuration it would be easier themes, especially if there was an include-file syntax, so you could import a theme file that might be published by a third party and add some personal overrides. Imagine a WM or DE that wanted to ship a themed version of Fuzzel

ayushnix commented 2022年02月03日 18:10:42 +01:00

I'm trying to support fuzzel for tessen and the lack of a file based configuration is a problem. The same issue is present in bemenu.

For some context, some users prefer to use different options for their dmenu operations when used with different programs. This isn't easy to implement using wrapper shell scripts and seems like an ugly hack. Environment variables don't really help either. Yeah, a user can do something like env FUZZEL_FONT=... FUZZEL_BG=... tessen -b fuzzel but that is even more ugly and messy. As @dnkl wrote in the very first comment, when multiple contexts are involved, wrapper shell scripts and environment variables don't work.

The support for environment variables in bemenu feels like a hack and completely unneccesary so I'd suggest not to go down that route with fuzzel, unless someone fancies having monstrosity like this in their wrapper shell scripts or in their .profile file.

If fuzzel would support using a configuration file for its configuration, that would go a long way in wayland having a decent dmenu program. Allowing users to do fuzzel -c $XDG_CONFIG_HOME/fuzzel/whatever-you-want-depending-on-the-context.ini solves this issue.

I'm trying to support fuzzel for [tessen](https://github.com/ayushnix/tessen) and the lack of a file based configuration is a problem. The same issue is present in [bemenu](https://github.com/Cloudef/bemenu/issues/15). For some context, some users prefer to use different options for their dmenu operations when used with different programs. This isn't easy to implement using wrapper shell scripts and seems like an ugly hack. Environment variables don't really help either. Yeah, a user can do something like `env FUZZEL_FONT=... FUZZEL_BG=... tessen -b fuzzel` but that is even more ugly and messy. As @dnkl wrote in the very first comment, when multiple contexts are involved, wrapper shell scripts and environment variables don't work. The support for environment variables in bemenu feels like a hack and completely unneccesary so I'd suggest not to go down that route with fuzzel, unless someone fancies having [monstrosity like this](https://github.com/ayushnix/dotfiles/blob/a65472d1ea80e350c9bff56df3a58a730f8e9127/dot_bash_profile#L37) in their wrapper shell scripts or in their `.profile` file. If fuzzel would support using a configuration file for its configuration, that would go a long way in wayland having a decent dmenu program. Allowing users to do `fuzzel -c $XDG_CONFIG_HOME/fuzzel/whatever-you-want-depending-on-the-context.ini` solves this issue.

dnkl commented 2022年02月03日 18:15:32 +01:00

There weren't that many options when this ticket was opened. Today, there are quite a few more, and that has made my start to tip over in favor of file-based configuration.

There weren't _that_ many options when this ticket was opened. Today, there are quite a few more, and that has made my start to tip over in favor of file-based configuration.

markstos commented 2022年02月03日 19:22:13 +01:00

Until this gets implemented in C, a workaround is to create a shell script called fuzzel-configured, which reads ~/.config/fuzzel/fuzzel.ini then transforms the arguments into CLI arguments that are passed to fuzzel.

It's still ugly, but will be close to 100% forward-compatible with a proper fix. For example, consider a ~/.config/fuzzel/fuzzel.inithat exactly mirrors the command line args:

width=25
font='Hack:weight=bold:size=36'

That can be parsed and convered into arguments for fuzzel like this:

❯ awk 'BEGIN{ORS=" "; print "fuzzel"} /=/ { print "--"0ドル }' ~/.config/fuzzel/fuzzel.ini 
fuzzel --width=25 --font='Hack:weight=bold:size=36' ⏎ 

To avoid having a wrapper named "fuzzel-configured", you could also name the binary ~/.local/bin/fuzzel" and make sure this "bin" directory comes first in $PATH. Then have your awk script print out /usr/bin/fuzzel to call the "real" fuzzel.

In this way, it will appear to other apps that fuzzel supports file-based configuration.

Until this gets implemented in C, a workaround is to create a shell script called `fuzzel-configured`, which reads `~/.config/fuzzel/fuzzel.ini` then transforms the arguments into CLI arguments that are passed to `fuzzel`. It's still ugly, but will be close to 100% forward-compatible with a proper fix. For example, consider a `~/.config/fuzzel/fuzzel.ini`that exactly mirrors the command line args: ``` width=25 font='Hack:weight=bold:size=36' ``` That can be parsed and convered into arguments for `fuzzel` like this: ``` ❯ awk 'BEGIN{ORS=" "; print "fuzzel"} /=/ { print "--"0ドル }' ~/.config/fuzzel/fuzzel.ini fuzzel --width=25 --font='Hack:weight=bold:size=36' ⏎ ``` To avoid having a wrapper named "fuzzel-configured", you could also name the binary ~/.local/bin/fuzzel" and make sure this "bin" directory comes first in $PATH. Then have your awk script print out `/usr/bin/fuzzel` to call the "real" fuzzel. In this way, it will appear to other apps that fuzzel supports file-based configuration.

ayushnix commented 2022年02月03日 19:28:27 +01:00

Thanks for suggesting this but I don't think a lack of workarounds is an issue at this moment. I can use them personally but I can't recommend them in a README page or add support for them in another project.

Thanks for suggesting this but I don't think a lack of workarounds is an issue at this moment. I can use them personally but I can't recommend them in a README page or add support for them in another project.

tinywrkb commented 2022年02月05日 18:23:12 +01:00

I suggest that this feature will include a logic that will fall back to a global system config file before loading the compiled defaults. That's in case that a config file wasn't detected in the user's home.

I suggest that this feature will include a logic that will fall back to a global system config file before loading the compiled defaults. That's in case that a config file wasn't detected in the user's home.

dnkl commented 2022年03月21日 21:04:22 +01:00

Based on the input here, my plan moving forward is:

• ini-file syntax (like foot)
• look for fuzzel/fuzzel.ini in:
  • $XDG_CONFIG_HOME (~/.config if unset)
  • XDG_CONFIG_DIRS (/etc if unset)
  • builtin defaults
• Have config file sections and options match the command line options, both in name and syntax, as far as possible.
• Command line options obviously override the config file
• Add an include "option" (similar to foot's)

Did I miss something?

Based on the input here, my plan moving forward is: * ini-file syntax (like foot) * look for `fuzzel/fuzzel.ini` in: - `$XDG_CONFIG_HOME` (`~/.config` if unset) - `XDG_CONFIG_DIRS` (`/etc` if unset) - builtin defaults * Have config file sections and options match the command line options, both in name and syntax, as far as possible. * Command line options obviously override the config file * Add an `include` "option" (similar to foot's) Did I miss something?

ayushnix commented 2022年03月21日 22:53:59 +01:00

Did I miss something?

Nope, sounds good to me. The include option would be very useful as well.

> Did I miss something? Nope, sounds good to me. The `include` option would be very useful as well.

chinmay commented 2022年04月07日 09:36:17 +02:00

Not sure if this should be a separate issue because keybindings are only possible in a config file, but custom keybindings please - arrow keys are hard to reach on laptop keyboards

Edit: found out C-n and C-p, don't know how to select an entry other than RET though

In any case, I use C-j/k and C-h for completion in neovim so having a single set of keybindings would be nice (especially as I use fuzzel for vim.ui.select)

Not sure if this should be a separate issue because keybindings are only possible in a config file, but custom keybindings please - arrow keys are hard to reach on laptop keyboards Edit: found out C-n and C-p, don't know how to select an entry other than RET though In any case, I use C-j/k and C-h for completion in neovim so having a single set of keybindings would be nice (especially as I use fuzzel for [vim.ui.select](https://neovim.io/doc/user/lua.html#vim.ui.select()))

dnkl commented 2022年04月07日 11:53:57 +02:00

Not sure if this should be a separate issue because keybindings are only possible in a config file, but custom keybindings please - arrow keys are hard to reach on laptop keyboards

I'd say it's a separate issue, and one that I agree should be implemented.

don't know how to select an entry other than RET though

Right, there isn't one (except tab when there's only a single match).

In any case, I use C-j/k and C-h for completion in neovim so having a single set of keybindings would be nice (especially as I use fuzzel for vim.ui.select)

As long as they don't collide with the existing bindings, I'd be happy to add vim-like bindings.

> Not sure if this should be a separate issue because keybindings are only possible in a config file, but custom keybindings please - arrow keys are hard to reach on laptop keyboards I'd say it's a separate issue, and one that I agree should be implemented. > don't know how to select an entry other than RET though Right, there isn't one (except <kbd>tab</kbd> when there's only a single match). > In any case, I use C-j/k and C-h for completion in neovim so having a single set of keybindings would be nice (especially as I use fuzzel for vim.ui.select) As long as they don't collide with the existing bindings, I'd be happy to add vim-like bindings.

chinmay commented 2022年04月07日 12:23:32 +02:00

I'd say it's a separate issue, and one that I agree should be implemented.

Opened #117

As long as they don't collide with the existing bindings, I'd be happy to add vim-like bindings.

vim defaults are C-n/C-p too (and C-y for selecting) so nvm

> I'd say it's a separate issue, and one that I agree should be implemented. Opened #117 > As long as they don't collide with the existing bindings, I'd be happy to add vim-like bindings. vim defaults are C-n/C-p too (and C-y for selecting) so nvm

dnkl commented 2022年04月07日 12:51:48 +02:00

vim defaults are C-n/C-p too (and C-y for selecting) so nvm

We can add C-y immediately, as an alternative to Return. Then, when we implement custom key bindings, we'll keep it in the default set of bindings.

> vim defaults are C-n/C-p too (and C-y for selecting) so nvm We can add C-y immediately, as an alternative to Return. Then, when we implement custom key bindings, we'll keep it in the default set of bindings.

chinmay commented 2022年04月07日 12:52:38 +02:00

Thanks!

Thanks!

dnkl commented 2022年04月07日 12:56:47 +02:00

#118

https://codeberg.org/dnkl/fuzzel/pulls/118