Emacs has had browse-url for ages — it’s very simple; it
just calls browse-url-browser-function, and that’s enough for most things.
But then somebody implemented a browser in Emacs that was halfway possible to use for a number of non-complicated web pages, namely eww, and that complicated things. Now some people wanted to stay in Emacs while reading a number of web pages, but had to escape to a real browser for pages that weren’t trivial or had lots of user interaction. So somebody implemented browse-url-secondary-browser-function, and the idea was that if you wanted to stay in Emacs, you just hit RET on a link, and if you wanted to use a real browser, you used C-u RET on the link.
(Or the other way around, depending on your preferences.)
And that works well.
Then Wayland happened.
Wayland doesn’t allow windows to raise themselves because of security. I mean, if a window can just raise itself over another window, that’d be anarchy! Rioting in the streets! It’s so unsafe!
So of course all the compositors have started adding support for this… because… er… uhm… And… er… all applications have to add support for this, explicitly. So, er… Thanks, Wayland.
But back to my thing — an application under Wayland can still open a new window and put it on top. It just can’t raise existing windows. Because that would be unsafe, but opening and raising a new window is obviously safe.
Wayland.
While I’m typing away here, allow me to present my new one act play that has nothing to do with the thing I’m talking about here, but anyway:
Wayland: Taking screenshots is obviously so unsafe! Any application can just copy the screen! Just call magick import. That’s insane! That’s gone!
Users: But we want to be able to take screenshots.
Gnome: OK, we added gnome-screenshot.
KDE: OK, we added Spectacle.
wlroots: OK, we added wayshot.
Wayland: See! Now it’s safe!
End scene. Curtains. Sporadic applause.
But I digress! We were talking about browsers and Emacs.
So I fixed this by just having my firefox being this:
larsi@up:~$ cat /usr/bin/firefox #!/bin/sh exec /usr/local/bin/firefox/firefox --new-window "$@"
But that’s not very satisfactory for some of my workflows. For instance, when shopping music from Norman:
I go through the weekly email and hit C-u RET on all the albums I think may be interesting, and then listen a bit before deciding. But this means that I’ll typically have twenty Firefox windows open, and that’s just kinda messy. In the olden days, I’d just have twenty Firefox tabs, and that was fine.
So I’ve lately realised that I have three ways I want to browse the web:
- In Emacs
- In Firefox, immediately
- In Firefox, later
In the first Firefox case, I want to pop up a window. In the second, I just want to add a tab to the one Firefox window I always have open, and then I’ll read it/do some shopping later.
The results are on Microsoft Github. This is just a tiny micro library, but it seems to do what I want it to do. Your mileage will vary a lot depending on your workflow.
But this is actually better now than my old workflow under X: There I would hit C-u RET on a Norman Records link, and Firefox would pop up with a new tab. And then I’d have to lower the Firefox window to go back to Emacs. Now I can just C-u C-u RET and continue on immediately.
So there you see! Wayland is better after all!
> I mean, if a window can just raise itself over
> another window, that’d be anarchy! Rioting in
> the streets! It’s so unsafe!
I don’t understand this snark at all. Allowing application to raise themselves without user action is a very obvious anti feature to me.
Instead of raising an existing window, any application can just open a new window over another window (without user interaction).
Interesting, I have set my secondary browser function to `browse-url-firefox`and using C-u RET in EWW opens a new tab, and raises the window. With no other config or change.
C-u C-u RET opens the link in a new EWW buffer.
Ehhh… I used backticks for “browse-url-firefox” which I can see now in the output, was a mistake.
And you’re using Wayland (with a Wayland-native Firefox?) If so, what compositor are you using?
Yes to all, I had to look up the compositor…it is “mutter”.
I run Fedora Workstation, if that helps.
I would like to keep browse-url-browser-function at its default and set browse-url-secondary-browser-function to eww-browse-url. This way C-u RET opens the external browser. (One motivation for doing this is that there seems no easy way to use browse-url-secondary-browser-function when following a link from org-mode.)
But this does not work in eww-mode, because there browse-url-browser-function gets overwritten with eww-browse-url, and I end up with no way to open a link in the external browser.
Seems that eww assumes that browse-url-secondary-browser-function is the external browser, but browse-url.el does not make this assumption. Both variables are set to browse-url-default-browser by default.
Actually, it turns out that the little package that this blog post is about solves my problem as well.
Setting
(setq browse-url-browser-function #’open-web
browse-url-secondary-browser-function #’open-web)
disables the primary/secondary browser mechanism and replaces it by open-web’s, which directly reads current-prefix-arg.
It’s a bit of a mess, but it works. 🙂
Yeah, it’s confusing the way open-web does it — you’re not supposed to react to current-prefix-arg way down in a library function, but instead pass it in from the top level command. But in this case, it’s just so convenient. 😀 Especially when trying to figure out whether this way of dealing with links makes sense, which I’m still not quite sure about.
Being able to choose whether to open a new window or add a tab to an existing one is useful IMHO, even on X11.
But what is even more useful for me as a heavy user of both org-mode and Gnus is that open-web suddenly makes web link opening consistent across Emacs. This makes eww usable for me, which in turn allows to stay more in Emacs, which is what all this is about, isn’t it?
Wayland isn’t only for Desktop, that’s why it don’t has rise by default, if a compositor want to implement it fine they can do it(gnome and KDE accepted the risk for usability) but if a more secure compositor or some other type of device don’t want that feature, they don’t need to implement it