Except from being cool, we can do it, are there any benefits? Benefits for me would be avoiding interactions with the oligarchies and generally executing code on my machine that I don't need to consume Web content.
Hello. This is a bridge that connects Emacs to modern usage of the http protocol, for better or worse.
It makes your chromium experience programmatic, via the Emacs + CDP integration, now you can use a project like this to automate chromium with an Emacs user-friendly human interaction layer.
Sounds like a bunch of words. Here's a real example:
We added yesterday a gpg based password manager vault feature that is emacs-native: it pulls a password out from some local vault file and can inject it straight to a a web form.
That's just a simple example. But for someone who would prefer not to keep all their logins and passwords in a cloud. And for someone who uses and enjoys Emacs. But wants to have a modern browser controlled by Emacs, with all the familiar Emacs binds working the same in the Chromium. It might make sense. :)
One flow I'm considering, is making eww the default browser, to stay pure and text-based in my day to day, code documentation and simple html-only websites etc. all tends to work very well with eww.
And then connecting eww's fallback browser button '&' to this embr project. Then when eww is not capable to do what I need it, use this headless chromium approach.
Then at this point, I dont even need to install firefox or chromium or anything as a system package, and while it "still sucks" at least my browser experience is contained and minimized to a self-contained headless chromium, and i get to control it with Emacs keys.
It feels like a win to me. That's my mindset while putting this all together. And it's also why I used as many eww keybinds as I could for embr.
Except from being cool, we can do it, are there any benefits? Benefits for me would be avoiding interactions with the oligarchies and generally executing code on my machine that I don't need to consume Web content.
Hello. This is a bridge that connects Emacs to modern usage of the http protocol, for better or worse.
It makes your chromium experience programmatic, via the Emacs + CDP integration, now you can use a project like this to automate chromium with an Emacs user-friendly human interaction layer.
Sounds like a bunch of words. Here's a real example:
We added yesterday a gpg based password manager vault feature that is emacs-native: it pulls a password out from some local vault file and can inject it straight to a a web form.
That's just a simple example. But for someone who would prefer not to keep all their logins and passwords in a cloud. And for someone who uses and enjoys Emacs. But wants to have a modern browser controlled by Emacs, with all the familiar Emacs binds working the same in the Chromium. It might make sense. :)
One flow I'm considering, is making eww the default browser, to stay pure and text-based in my day to day, code documentation and simple html-only websites etc. all tends to work very well with eww.
And then connecting eww's fallback browser button '&' to this embr project. Then when eww is not capable to do what I need it, use this headless chromium approach.
Then at this point, I dont even need to install firefox or chromium or anything as a system package, and while it "still sucks" at least my browser experience is contained and minimized to a self-contained headless chromium, and i get to control it with Emacs keys.
It feels like a win to me. That's my mindset while putting this all together. And it's also why I used as many eww keybinds as I could for embr.