Handlr no longer opens any files on my mimeapps.list

[charbelnicolas]

After the latest update handlr no longer opens any file on the mimeapps.list. What is the point of having a "handler" if it doesn't open any files? Am I to set manually all the file types handlr should open by handlr set?

[charbelnicolas]

Wow, i used handlr set .png feh.desktop and it wiped my whole curated mimeapps.list with no way of undoing. What a crock of shit.

[Anomalocaridid]

I'm very, very sorry that this happened. What version were you using? Could you tell me what you remember you had in your mimeapps.list? Any information would be helpful.

I don't blame you if you permanently lost trust in my program, but I'll fix this so no one else has to go through this.

[Anomalocaridid]

I have fixed this particular in the fix-discussion-68 branch. Would you be able to clone it and test it? It is alright if you cannot.

[charbelnicolas]

Just because a mimeapps.list doesn't have a fucking [Added Associations] it stops working... what a piece of shit.

[Anomalocaridid]

Again, I am very, very sorry. But this information helps immensely and I appreciate you mentioning it.

[Anomalocaridid]

Also are you using v0.11.0? If so, I might know what could be causing this and I'll should be able to fix it soon.

[charbelnicolas]

Hello, yes I'm using version 0.11 the package just got updated today in Arch Linux and I wasn't able to open any files as I normally do.

[charbelnicolas]

This doesn't work anymore either x-scheme-handler/terminal=org.codeberg.dnkl.foot.desktop; I can't open files with neovim.

text/*=nvim.desktop;

[Anomalocaridid]

I've fixed the issue with the following three commands, and honestly I didn't think it would be this easy:

sudo pacman -Rs handlr-regex, rm /home/charbel/.local/bin/xdg-open and then to finish it off, a simple paru -S mimejs-git.

So much for the blazingly fast rust implementation. It never ceases to amaze me how such a simple program like mimejs can do the neeeded work flawlessly without getting in the way.

A wise man once said it is always best to avoid the "It works on my computer™" developer mentality. How this ended up in the extra repository on arch linux is beyond me.

I am very, very sorry I couldn't figure out the problem preventing you from using nvim, I am glad that you have found an alternative that works for you, and I admit that yes, it is my fault and my fault alone it doesn't work any more.

However, I would prefer that you do not go out of my way to insult me to my face.

I would love nothing more than to fix your problem, but if I can't get the problem to occur on my own system, then how am I supposed to figure out how to fix it? How am I supposed to know if any change I make even affects the problem at all?

That is not "It works on my computer" mentality. That is me trying what I can and failing.

Of course, trying only gets so far, so by all means, use something that actually works for you. Trust me, I've been there. I get it. I couldn't care less if you or anyone else uses something else.

But don't take your frustrations out on me, the sole developer of this project, who maintains this project in my free time.

I hope someday I can fix this issue so others don't have to deal with it and I hope whoever's behind mimejs doesn't ever get a message like this from you.

Thank you for understanding.

[Celti]

I hope someday I can fix this issue so others don't have to deal with it

I can reproduce this issue (or produce a similar one) without nnn by starting handlr without any stdin/stdout, e.g. handlr open ~/test.txt 0<&- 1>&-. Perhaps handlr isn't isolating child processes properly?

[Celti]

Aha, found it:

handlr-regex/src/common/desktop_entry.rs

Line 146 in 65797a7

if self.terminal && config.terminal_output {

That should be !config.terminal_output.

[Anomalocaridid]

I can reproduce this issue (or produce a similar one) without nnn by starting handlr without any stdin/stdout, e.g. handlr open ~/test.txt 0<&- 1>&-. Perhaps handlr isn't isolating child processes properly?

I can reproduce this issue, although it does not look like it creates a persistent background process for me like the problem @charbelnicolas reported.

Aha, found it:

handlr-regex/src/common/desktop_entry.rs

Line 146 in 65797a7

if self.terminal && config.terminal_output {

That should be !config.terminal_output.

Nice catch! I can confirm that fixes it! I'll definitely make sure to add a regression test as well.

[Anomalocaridid]

Ok, this should be solved in v0.11.2. I could not actually add a regression test due to some weirdness with how getting the x-scheme-handler/terminal program is currently implemented, but I intend to resolve it soon by reworking the implementation.

[charbelnicolas]

application/json=nvim.desktop; won't open in neovim either... This is inside neovim's .desktop file:

TryExec=nvim
Exec=nvim %F
Terminal=true
Type=Application

It does have Terminal=true

[charbelnicolas]

It never launches the foot terminal it just launches the nvim process without the actual terminal and you end up with something like this:

A ton of neovim processes lurking in the background...

[charbelnicolas]

Just downgraded to version 0.10.1 and everything is working as expected so I'll keep this version while a fix comes up for version 0.11.