| Message ID | 877eew70ge.fsf@web.de |
|---|---|
| State | Accepted |
| Commit | 5bbb04f9d1634e67e572e7e9d170342e63a78573 |
| Headers | show |
| Series | [bug#34128] add emacs built with xwidgets-support | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | success | Successfully applied |
Arne Babenhauserheide <arne_bab@web.de> writes: > Hi Ludovic, > >> Thanks for the patch! > > Thank you for your review! > >> I wonder why this hadn’t been done before; >> Nicolas, Alex, Pierre, thoughts? > > There is an older bug with xwidgets support which had problems because > it depended on an old version of webkitgtk (I only found it after I sent > the patch). Maybe that stopped others from submitting. I performed the migration of the Emacs xwidgets feature from the old to the newer webkitgtk API, but that’s when I noticed that xwidgets are hardly usable in its current state. I certainly wouldn’t use it as a browser, for example, because there is virtually no integration with the rest of Emacs. It works fine for sending JavaScript snippets to the widgets and have it respond, but it’s not very well integrated into Emacs. Disabling JavaScript has the effect of disabling *all* JavaScript, which makes scrolling impossible (as it is implemented by sending JavaScript to the widget). Turning it into a usable browser would require more fundamental changes, and that’s when I stopped working on patches. -- Ricardo
Ricardo Wurmus <rekado@elephly.net> writes: > I performed the migration of the Emacs xwidgets feature from the old to > the newer webkitgtk API, but that’s when I noticed that xwidgets are > hardly usable in its current state. I certainly wouldn’t use it as a > browser, for example, because there is virtually no integration with the > rest of Emacs. I see it as pretty good for many usecases already. I often just want to look up something in a browser without switching away from Emacs, and many websites nowadays don’t work with text browsers anymore. The main thing that’s missing right now is a way to highlight all links and select the one to follow — similar to next (or one of the other projects listed on https://qutebrowser.org/ ). Do you know why it flickers? > It works fine for sending JavaScript snippets to the widgets and have it > respond, but it’s not very well integrated into Emacs. Disabling > JavaScript has the effect of disabling *all* JavaScript, which makes > scrolling impossible (as it is implemented by sending JavaScript to the > widget). That doesn’t really hurt me: For sites without javascript, eww mostly works fine. So when running a webkit, I typically need javascript anyway. Also xwidgets as a feature enables much more than just a browser. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
Heya, Ricardo Wurmus <rekado@elephly.net> skribis: > Arne Babenhauserheide <arne_bab@web.de> writes: > >> Hi Ludovic, >> >>> Thanks for the patch! >> >> Thank you for your review! >> >>> I wonder why this hadn’t been done before; >>> Nicolas, Alex, Pierre, thoughts? >> >> There is an older bug with xwidgets support which had problems because >> it depended on an old version of webkitgtk (I only found it after I sent >> the patch). Maybe that stopped others from submitting. > > I performed the migration of the Emacs xwidgets feature from the old to > the newer webkitgtk API, but that’s when I noticed that xwidgets are > hardly usable in its current state. I certainly wouldn’t use it as a > browser, for example, because there is virtually no integration with the > rest of Emacs. > > It works fine for sending JavaScript snippets to the widgets and have it > respond, but it’s not very well integrated into Emacs. Disabling > JavaScript has the effect of disabling *all* JavaScript, which makes > scrolling impossible (as it is implemented by sending JavaScript to the > widget). > > Turning it into a usable browser would require more fundamental changes, > and that’s when I stopped working on patches. Oh, I was more optimistic; thanks for explaining. Knowing this, what do you think of adding it as a package? We also have ‘guile-emacs’ anyway… Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: >> I performed the migration of the Emacs xwidgets feature from the old to >> the newer webkitgtk API, but that’s when I noticed that xwidgets are >> hardly usable in its current state. I certainly wouldn’t use it as a >> browser, for example, because there is virtually no integration with the >> rest of Emacs. >> >> It works fine for sending JavaScript snippets to the widgets and have it >> respond, but it’s not very well integrated into Emacs. Disabling >> JavaScript has the effect of disabling *all* JavaScript, which makes >> scrolling impossible (as it is implemented by sending JavaScript to the >> widget). >> >> Turning it into a usable browser would require more fundamental changes, >> and that’s when I stopped working on patches. > > Oh, I was more optimistic; thanks for explaining. > > Knowing this, what do you think of adding it as a package? We also have > ‘guile-emacs’ anyway… I’m not at all opposed to adding it as a package. After all, it is a potentially useful feature and providing a package makes it more likely that people get to play with it and maybe extend the features by contributing elisp and JavaScript. -- Ricardo
Hi Arne, Arne Babenhauserheide <arne_bab@web.de> skribis: > Is inline here OK? If yes: It is. > From ed2eca1ade73eb6b7c2e8b17541e3e182ade4608 Mon Sep 17 00:00:00 2001 > From: Arne Babenhauserheide <arne_bab@web.de> > Date: Fri, 18 Jan 2019 23:29:14 +0100 > Subject: [PATCH] add emacs built with xwidgets-support > > * gnu/packages/emacs.scm (emacs-xwidgets): new variable Applied, thank you! I’ve tried it and I confirm that it flickers and that scrolling doesn’t quite work as nicely as it could. ;-) Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: >> Subject: [PATCH] add emacs built with xwidgets-support >> >> * gnu/packages/emacs.scm (emacs-xwidgets): new variable > > Applied, thank you! Thank you! > I’ve tried it and I confirm that it flickers and that scrolling doesn’t > quite work as nicely as it could. ;-) Yes — and that it is now as easy as running guix package -i emacs-xwidgets && emacs M-x xwidget-webkit-browse-url to test this is cool! Best wishes, Arne
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index a488289f1..7e8dcadf9 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -59,6 +59,7 @@ #:use-module (gnu packages pkg-config) #:use-module (gnu packages texinfo) #:use-module (gnu packages tls) + #:use-module (gnu packages webkit) #:use-module (gnu packages xml) #:use-module (gnu packages xorg) #:use-module (guix utils) @@ -210,6 +211,22 @@ languages.") (native-inputs `(("pkg-config" ,pkg-config))))) +(define-public emacs-xwidgets + (package + (inherit emacs) + (name "emacs-xwidgets") + (synopsis "The extensible, customizable, self-documenting text +editor (with xwidgets support)") + (build-system gnu-build-system) + (arguments + `(#:configure-flags + '("--with-xwidgets") + ,@(package-arguments emacs))) + (inputs + `(("webkitgtk" ,webkitgtk) + ("libxcomposite" ,libxcomposite) + ,@(package-inputs emacs))))) + (define-public emacs-no-x (package (inherit emacs) (name "emacs-no-x")