Personaly I use KeepassXC autotype functionality for this kind of thing (since I’m already using it as a password manager anyway)… I have entries that are just notes and then have the autotype command be: {NOTES}{ENTER} so it types the content of the note and presses enter.

The nice thing is that I can leverage the autotype dialogs from Keepass so I just need to remember 1 shortcut and it will open a dialog showing different Note options based on the title of the window I’m in. It also works across platforms (which is great if at work you still need to use Windows). However, Wayland is still not supported well.

I haven’t tried to use date/time placeholders, but in theory, they are suported in the keepass documentation (no idea if keepassXC in particular supports them): https://keepass.info/help/base/placeholders.html (check out the {CMD:/CommandLine/Options/} placeholder that lets you run arbitrary commands and optionally have their output replace the placeholder, which is very powerful)

In the auto-type docs they also have placeholders that even allow you to add delays, switch active windows, and press all kind of key combinations. Again, I’ve not tested if all of that works in KeepassXC but if not you can always use the official keepass app.

A compositor is normally a component in a DE, not a DE on its own. For it to be a DE in my book the “standalone” installation needs to, at minimum, provide: a launcher to execute apps, a toolbar/statusbar, and maybe a terminal emulator (or at least call some generic wrapper to automatically hook into one, something like xdg-terminal-exec).

I mean… openbox is used in X11 desktop environments like LXDE… I don’t see why labwc (essentially wayland’s openbox) should be treated like it cannot be a component of one.

And river has almost as a mission statement to become more of a framework than a DE on its own… they even have the goal in the long term to remove things from it and instead expose more to the commands/API to make it more modular… it’s definitely not something intended to work standalone and they expect people to develop third party layout generator programs.

Maybe sway is the one in that list that might be the most “standalone”, since it does have swaybar built-in… but the default configuration still expects you to provide at least something like dmenu to use as launcher, as well as making sure you have your terminal, etc, since it does not list them as specific dependencies of the sway package, so officially they aren’t really part of sway as if it were a DE suite.

It was just an example of what I’m doing for my particular situation where I don’t have root access and I want some personal scripts for myself, I’m not saying you should choose the same location. If everyone is already sourcing the same file, I expect there’s already a shared storage you are maintaining that everyone has access to.

About something breaking, I guess it’s up to you and your team if you prefer functions, but it also means not everyone will need to be annoyed when someone else’s code has a small syntax error. And also I expect the only errors you are able to get feedback about right now would be only structural syntax errors for the function declaration (I expect you don’t have unit tests or anything like that for your bash functions…) so technically a function could still be broken and you wouldn’t know until you use it.

Scripts also give the advantage of being able to use other languages beyond bash, if perl/python or others are available.

Anyway, you are free to have your reasons, I was just saying that root access is not necessarily needed.

The thing is that, if you are not sticking to POSIX, you might as well use more widely available alternative scripting languages like perl or python, which are often included in most workspaces by default, so I’d say it’s more useful to get experienced in those than to get experienced in fish.

It still limits where / how you use them.

For example, it’s easier / more efficient to call a shell script from sway (or whichever other software that might be running without a bash login session behind) than to try and force it to load a whole shell login session that includes those functions (which might also slow down the startup of the program and make it need a bit more ram without much of a benefit).

Scripts can reliably be run from everywhere (specially if placed somewhere in $PATH), functions require some preloading for every single new shell process and making sure the program invoking the shell (be it a terminal emulator or something else) is actually loading it. So as someone who likes to automate everything and often assigns hotkeys to particular commandline oneliners, scripts are much better… even a symlink might be more reliable than an alias.

You don’t need root level access though. What I usually do is stick a PATH="$PATH:$HOME/.local/bin and then place all the scripts in there.

And remember that Mozilla is supposed to be a non-profit.

I don’t understand how it makes sense for a nonprofit to make it so profitable to their executives to manage it… why is that not regulated?

I think that’s the point, he’s saying he’d rather use USA-linked FOSS than non-USA proprietary software.