bug#58626: Proposed changes to implement opening URLs on macOS

[Perry Smith]

NOTE: I am subscribed to this list but I do not receive emails from
the list.  Please CC me on replies and updates.  I will also check in
the archive every few days.

My email to the developers list explains better why I did this.[1] The
short version is an exception thrown by my Ruby on Rails app displays
a stack trace with file names and line numbers.  In the past, it was
possible to click on the line and it would pop into Emacs.  This was
after adding in Mitsuharu Yamamoto mods and other effort.  I wanted to
recreate that facility but in such a way that it might be accepted
into the main Emacs development.

It appears macOS uses the scheme in URLs a lot so these changes seem
to fit in with their general designs.

Attached is my patch file based upon the emacs-28.2 tar ball.  With
these changes, I can do:

    open emacs:///some/path/to/file.txt#25,40

and the file opens in Emacs with lines 25-40 highlighted.  Clicking a
link in a browser page with the same href as above causes the same
action.  The fragment can be omitted entirely or can be just a single
line.  The comma can also be a dash or a colon.

(I’m also going to submit a feature request to RoR to leverage this
feature.)

I don’t claim to be a lisp programmer so feel free to clean up what
I’ve done.

Note that the documentation says:

    If your delegate implements this method, AppKit does not call the
    application:openFile: or application:openFiles: methods.

I left the code for openFile and openFiles under an **assumption**
that on macOS before 10.13, openURLs will not be called and the system
will fall back to the openFile and openFiles entry points but I'm not
a macOS programmer either.

Thank you to Daniel Martin.  His reply to my email helped a lot.

Thank you for your time,
Perry
[1] https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01271.htmlf

open-url.diff.gz
Description: GNU Zip compressed data