Re: [PATCH] Make browser windows pop up when browsing URLs on Wayland

[Daniel Colascione <dancol@dancol.org>]

On December 24, 2024 12:49:36 AM EST, Tassilo Horn <tsdh@gnu.org> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>Hi Daniel,
>
>> We really should consider simplifying the whole browse-url mechanism
>> by eliminating browse-url-default-browser and the distinction between
>> browse-url-handlers and browse-url-default-handlers.  Instead,
>> browse-url-handlers should have a simple list of predicated handlers
>> just like display-buffer-alist.
>
>The reason there's browse-url-default-handlers and browse-url-handlers
>is that the former is meant for Emacs itself and packages whereas the
>latter is meant for the user to customize.  IIRC, Stefan Monnier
>suggested that distinction back then when I added the handlers and I
>still don't see a better way.  If there was only the defcustom
>browse-url-handlers, either packages couldn't sensibly add to it or if
>they did, users wouldn't be sensibly able to override what packages
>added.  Or if a package added an entry which the user then saved, how
>would that be removed when the package was removed?
>
>That's different with display-buffer-alist which is nil by default and
>it's not expected that packages add rules to it.  In contrast, if I'd
>write a gemini client for emacs, it's quite obvious that I'd add an
>entry matching gemini:// urls with my hander to
>browse-url-default-handlers.
>
>Bye,
>Tassilo


You could say the same of hooks, yes? Or auto-mode-alist?

Customization could work by associating each entry with a priority --- 20, 50, 90, etc. --- and merging user-provided entries (and whiteouts to disable certain pre-existing entries) with package supplied entries. This way, we end up with a simple, single approach to finding the handler for a URL: go down the list in priority order (breaking ties arbitrarily) and use the first handler that says "yes, I handle this URL".