Better functionality for 'termux-file-editor' & 'termux-url-opener'

Feature description

Combine `termux-url-opener` and `termux-file-opener` into one simple bash binary called `termux-opener`, it will be basic, make it a builtin or `termux-api` pkg, users may modify it or make their own still, if exists then `$HOME/bin` takes precedence over the builtin one at `$PREFIX/bin` and dont have the current java implementation determine what is being shared first. This allows the user to fully control its behaviour and still able to maintain both functions, to open a URL or file.

Reason?
I recently made a very advanced termux-url-opener, by far the most advanced I have seen on Github & r/termux whilst doing so I noticed its restrictions/caveats, heres just a couple examples, I can share more if needed:

• termux-url-opener
  • Quite a few apps contain other than just the URL when sharing, a good example is Spotify, sharing a link looks like this: Here’s a song for you… 44 More by Logic https://open.spotify.com/track/3e7Y6sfFlIdBMJhX7wpqVO?si=2tY4mUslRTKkUKzLYlyu1w
    This invokes termux-file-opener but this isnt what we want. First thought... easy, lets just: echo "$1" | awk 'NF>1{print $NF}' to remove all the text first before streaming/downloading it, but unfortunately this is not possible as java already said "this is a file" and opened termux-file-opener instead.
• termux-file-editor
  • Even less customisable, defaults to $HOME/downloads is another process to move it elsewhere, has potential to do much more, a quick example off the top of my head:

echo "Title:"
read TITLE
if '.hex' || '.apk' || '.blahblah' ; then
  kak "$@" > "$HOME/storage/downloads" || \
  kak "$@" > "/sdcard/Downloads"
else
  micro "$@" > "$HOME/storage/downloads" || \
  micro "$@" > "/sdcard/Downloads"
fi

Even this would be a quick fix/improvement...

select opts in 'termux-url-opener' 'termux-file-editor'; do
case "$opts" in
     'termux-url-opener')
          .....
      'termux-file-editor')
          .....
  esac
done

This asks us which we want to invoke, obviously we could add dialog etc.
That and possibly an optional environment variable for our .termux.properties like "TERMUX_OPENER_DIR" to allow users to use another "default" directory if they need and "TERMUX_OPENER_INTERACTIVE" just in case being asked first is annoying to someone and they want default/legacy behaviour.

Solution?
Apart from what I already stated....
If java didnt pre-determine, you could keep functionality of both files (url-opener/file-editor) in one, its simple, a URL will never have spaces in it, so this is what I suggest the new builtin/api pkg "termux-opener" should contain...

if [[ "$#" -eq 1 ]]; then
  termux-url-opener
else
  termux-file-editor
fi

"Have scripting do the talking to java, not the other way around, bash/python/lua/perl scripting are much more flexible, we can use them from Termux freely, much more we can a compiled/dexed java APK, even xdg-open is better than current java solution, I see no need for it, if this java-fu is really needed, make it a termux-api solution, atleast then, once again, we can hack at the scripts easily, possibly leading to further contributions from the public.
Also ranger uses a "rifle.conf" (there are many like it) that configure opening any file type with any program, this and the fact that Termux is an app (which means it can list other installed apps and get their launchable activities) makes the possibility of a similar "rifle.conf" that could pick exactly what we want to with, e.g: 'txt = micro' (a CLi app) but also 'hex = com.mixplorer/.activities.HexViewerActivity' (an Android app)'

Note
My python isnt amazing, but I am more than happy to contribute to the termux-opener binary.

Finally...
A HUGE thank you to you all, it truly is appreciated!

Reference implementation

Have you checked if the feature is accessible through the Android API? yes
Do you know of other open-source apps that has a similar feature as the one you want? (Provide links)

Start by locating the current Java implementation and the termux-url-opener and termux-file-editor entry points, then check how the Android API currently distinguishes shared URLs from files. The proposed work is done when one user-controllable termux-opener preserves both behaviors and its precedence and optional configuration are defined.