dotfiles VS bemenu

I've enabled filetype.lua using g.do_filetype_lua = 1 and disabled filetype.vim using g.did_load_filetypes = 0. I'm using the markdown treesitter parser. Here's the --startuptime log file when a markdown file is opened. Here's my ~/.config/nvim.

You can use my dotfiles for reference if you want.

Here's my simple systemd timer to rotate wallpapers in case you're using a distro with systemd.

> Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it.

I don't know about others but I'm not a fan of monstrosity like this

https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf...

If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts.

> I'm a big fan of following the 12factor[1] approach.

I guess if you don't want state associated with your deployments, environment variables are better but I would still argue that they aren't manageable when their values become large as shown above or if their numbers start approaching double digits because when that happens, you're essentially emulating config files anyways.

I really like using something like fuzzy search for menus like these. https://github.com/Cloudef/bemenu is pretty cool in that it works both in a terminal, X11 and on Wayland, so if you want to do something graphical later you can easily migrate. There's also fzf and skim, which work similarly but are only for the terminal.

I know that dmenu won't work on wayland, hence I installed bemenu as a drop-in replacement. Now I want to configure keybindings for my scripts using the default settings, but they don't seem to work. Running my scripts from the terminal work, but not when running them via keybinding.

bemenu (i. e. bemenu-run) is a simple launcher that has command line interface (set with BEMENU_BACKEND environment variable), also fzf can be useful in this regard but it will most likely require writing additional scripts to work as a launcher.

I've already highlighted how using environment variables to change themes is a horrible user experience. The bemenu program suffers from the same flaw. Environment Variables should never be used in any way for values that might change inside a running session.

bemenu

Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absolutely awful when used to configure values that will probably change inside a session. A good example is BEMENU_OPTS from the bemenu program, which is used to change colors, font etc. Should I relogin into my session just to make a program use dark mode colors?

https://github.com/Cloudef/bemenu#environment-variables

In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.

Bemenu - "Dynamic menu library and client program inspired by dmenu"

Instead of rofi, bemenu[2] is nice too.

[1] https://github.com/dunst-project/dunst/issues/264

[2] https://github.com/Cloudef/bemenu

tessen can use either bemenu, the wayland fork of rofi, or wofi to show password store data. It relies on wtype for autotyping instead of using ydotool because ydotool needs root privileges.