request: allow for using a custom handler/opener, or xdg-open as an alternative to the current way(which opens the wrong browser for me)

[erikLundstedt]

I use a custom setup on my system that uses a program called jaro instead of xdg-open to open links(and other things too, its an xdg-open alternative)

however, when I try to open a link in tym, it opens the wrong program(firedragon (firefox-fork installed for testing) rather than vivaldi or firefox (depending on url as i have it open some things in firefox and the rest in vivaldi)

so my question now is: would it be possible to have something like a wrapper around os.execute() or io.popen() that wont freeze tym

(probably) relevant parts of the code:

context.c: https://github.com/endaaman/tym/blob/edc342d38a308e45064a7f33abc7c52000383cc2/src/context.c#L450 called by builtin.c: https://github.com/endaaman/tym/blob/0d5585cae41d347b691f9e3712875a97945c4cd4/src/builtin.c#L435 github-search-result: https://github.com/endaaman/tym/search?q=context_launch_uri

[endaaman]

Talking about the behavior when clicking an URI? If so, one solution is to set clicked hook to invoke a custom opener.

tym.set_hook('clicked', function(button, uri)
  if button == 1 then -- left click
    if uri then
      -- invoke a custom opener here
      return true
    end
  end
end)

[erikLundstedt]

my question is mostly how to make it not freeze tym itself(Im assuming here that os.execute("jaro" .. uri ) isnt safe to use , although I have not actually tried it)

[TorchedSammy]

io.popen? popen doesn't block

[js-everts]

@erikLundstedt

The simplest thing would be add an ampersand to make it non blocking:

os.execute("jaro " .. uri .. "&")

[erikLundstedt]

@erikLundstedt

The simplest thing would be add an ampersand to make it non blocking:

os.execute("jaro " .. uri .. "&")

Thanks

I'm usually extra careful when Lua is called from a different program.

Because I know that the implementations used by booth awesome (windowmanager, C/C++) and xplr (TUI file-explorer, rust) have special ways of doing shell command execution

[endaaman]

I think tym should provide only minimal APIs. I can provide some API to launch shell command, but if it isn't related to tym, it should not be implemented in tym. We can also use LuaRocks in Lua context and there maybe a good library.

The problem is what is considered safe. To achieve safety, if we need tym application dependent information, the API should be implemented in tym.

[erikLundstedt]

I think tym should provide only minimal APIs. I can provide some API to launch shell command, but if it isn't related to tym, it should not be implemented in tym. We can also use LuaRocks in Lua context and there maybe a good library.

The problem is what is considered safe. To achieve safety, if we need tym application dependent information, the API should be implemented in tym.

I'm thinking there could be a way to utilize the daemon in some way (like running a tym-instance ,without the UI), I don't know though

[endaaman]

To daemonize processes, we should use the propert apps to daemonize.