Does handlr need to rely on mimeapps.list?

[postsolar]

Why not forego this spec altogether?

[Anomalocaridid]

I guess technically in theory we could forgo it and use some other way to configure mime associations, but I do not see the point in doing so.

It's an established open standard used by other file openers, so it is simple to migrate configs to and from other tools and anyone that cares enough about how their files are opened to the degree that they would use handlr is probably already somewhat familiar with it.

Also I do not know of any comparable standard and I would rather not have to come up with something myself, because that would be a lot more work than adopting an existing standard.

Are there any reasons in particular why you think mimeapps.list should be forgone with?

[postsolar]

Thanks for explaining.

Are there any reasons in particular why you think mimeapps.list should be forgone with?

Not exactly, but yes, sort of. I did find it a bit confusing that handlr set writes to mimeapps.list unless it's something regex-based, in which case it writes to its own config. See, I'm also a user of NixOS where you're mostly expected to define your configuration in advance and programs are not expected to write to configuration files (these would typically be root-owned and with read-only access even for root), so handlr set is not helpful and I end up just defining my mimeapps.list myself. On top of that mimeapps.list's format doesn't allow to just set the preferred text editor as the app for all text files, every now and then I find out that there's another application/x-*script or something else that needs to be added. I could maybe just not use handlr then and instead use a simple script with file (which distinguishes between binary and text files), but handlr has regex, could open multiple files at once, has selector, etc. This all could be implemented in a script but then it's not anymore as simple of a script as I'd like it to be and I'd have to re-implement handlr but without mimeapps.list.

So the situation is a tad more complex than what I'd think it's supposed to be, and I thought whether it's mimeapps.list spec that is to blame. I feel like handlr has some powerful machinery already implemented but is ultimately limited by this spec.

[Anomalocaridid]

Thanks for explaining.

Happy to help! :)

I did find it a bit confusing that handlr set writes to mimeapps.list unless it's something regex-based, in which case it writes to its own config.

handlr set only writes to mimeapps.list. To add regex handlers, you need to edit handlr.toml manually.

See, I'm also a user of NixOS where you're mostly expected to define your configuration in advance and programs are not expected to write to configuration files (these would typically be root-owned and with read-only access even for root), so handlr set is not helpful and I end up just defining my mimeapps.list myself.

You are not actually required to use handlr set to edit mimeapps.list. It is essentially just a convenience feature for those who find it helpful to edit their mimeapps.list.

I use NixOS too and I always manage mimeapps.list with nix rather than use handlr set.

You can use this file in my dotfiles as an example on how to create a handlr config using nix.

On top of that mimeapps.list's format doesn't allow to just set the preferred text editor as the app for all text files, every now and then I find out that there's another application/x-*script or something else that needs to be added.

Technically true, but even since before I forked it, handlr has slightly diverged from the mimeapps.list spec and supports wildcards in mimetypes.

So you can use text/* and application/x-*script as mimetypes and it will set every mimetype that matches those to whatever program you associate with them.

Note that these are not to be confused with regexes and will never support anything beyond the * wildcard character.

[postsolar]

Yep, your Nix setup matches what I was doing. Thanks for affirming it's the expected way to do things. I think we could call this discussion resolved then ☺️.