SVG widget in GNU Emacs

SVG widget in GNU Emacs

[Anand Tamariya]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

Now you can use SVG widget in GNU Emacs. That is, use an SVG image or
fragment as background for push-button widget in Emacs buffer. You can also
specify the width and height of the widget for finer control. Generally
speaking, you can use any type of image for this purpose. But SVG suits
best because you can draw widget of any size without any distortion.

The ability to use SVG fragment means you can define multiple symbols in an
SVG and use the same as a sprite sheet for your UI requirements. Thus the
number of files to be managed is reduced.

Another use case would be better looking customize form. Or at the very
least, rounded "Save" and "Cancel" buttons. In other words, a more visually
appealing UI in graphical environments while maintaining the promise of
Emacs in terminal.

*Sample API: *svg-widget (svg frag &optional width height &rest args)

*Code:* https://gitlab.com/atamariya/emacs/-/blob/dev/lisp/svg.el
<https://www.blogger.com/#>

*Details:*
https://lifeofpenguin.blogspot.com/2021/10/svg-widget-in-gnu-emacs.html
*Patch*
modified   *lisp/wid-edit.el*
@@ -353,6 +353,7 @@ widget-specify-button
   "Specify button for WIDGET between FROM and TO."
   (let ((overlay (make-overlay from to nil t nil))
     (follow-link (widget-get widget :follow-link))
+    (display (widget-get widget :display))
     (help-echo (widget-get widget :help-echo)))
     (widget-put widget :button-overlay overlay)
     (if (functionp help-echo)
@@ -360,6 +361,7 @@ widget-specify-button
     (overlay-put overlay 'button widget)
     (overlay-put overlay 'keymap (widget-get widget :keymap))
     (overlay-put overlay 'evaporate t)
+    (overlay-put overlay 'display display)
     ;; We want to avoid the face with image buttons.
     (unless (widget-get widget :suppress-face)
       (overlay-put overlay 'face (widget-apply widget :button-face-get))

[-- Attachment #2: Type: text/html, Size: 2737 bytes --]

Re: SVG widget in GNU Emacs

[Po Lu]

Anand Tamariya <atamariya@gmail.com> writes:

> Now you can use SVG widget in GNU Emacs. That is, use an SVG image or
> fragment as background for push-button widget in Emacs buffer. You can
> also specify the width and height of the widget for finer
> control. Generally speaking, you can use any type of image for this
> purpose. But SVG suits best because you can draw widget of any size
> without any distortion.

I remember a proprietary version of Emacs (not derived from GNU Emacs)
having the ability to display arbitrary X Toolkit (such as Motif or
Athena widgets) widgets inside frames, along with providing protocol
bindings to X-Windows.

Would it make sense to extend the existing xwidget feature to support
this?  Now that I think of it, I think such a feature would greatly
benefit GNU Emacs.

Re: SVG widget in GNU Emacs

[Lars Ingebrigtsen]

Anand Tamariya <atamariya@gmail.com> writes:

> Now you can use SVG widget in GNU Emacs. That is, use an SVG image or
> fragment as background for push-button widget in Emacs buffer.

Sounds interesting, but I'm not quite sure I understand what this means
in practice.

> Sample API: svg-widget (svg frag &optional width height &rest args)
>
> Code: https://gitlab.com/atamariya/emacs/-/blob/dev/lisp/svg.el

Could you post a patch of the code you've added to svg.el?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: SVG widget in GNU Emacs

[Anand Tamariya]

[-- Attachment #1.1: Type: text/plain, Size: 743 bytes --]

On Wed, Oct 20, 2021 at 1:45 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Anand Tamariya <atamariya@gmail.com> writes:
>
> > Now you can use SVG widget in GNU Emacs. That is, use an SVG image or
> > fragment as background for push-button widget in Emacs buffer.
>
> Sounds interesting, but I'm not quite sure I understand what this means
> in practice.
>
[image: widget3.png]
You can create games or interaction dialogues using these widgets as shown
in the image.


> > Sample API: svg-widget (svg frag &optional width height &rest args)
> >
> > Code: https://gitlab.com/atamariya/emacs/-/blob/dev/lisp/svg.el
>
> Could you post a patch of the code you've added to svg.el?
>
(apply 'widget-create 'push-button :display (svg-image e) args)

[-- Attachment #1.2: Type: text/html, Size: 1512 bytes --]

[-- Attachment #2: widget3.png --]
[-- Type: image/png, Size: 15708 bytes --]

Re: SVG widget in GNU Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Date: Wed, 20 Oct 2021 11:15:02 +0800
> 
> I remember a proprietary version of Emacs (not derived from GNU Emacs)
> having the ability to display arbitrary X Toolkit (such as Motif or
> Athena widgets) widgets inside frames, along with providing protocol
> bindings to X-Windows.
> 
> Would it make sense to extend the existing xwidget feature to support
> this?  Now that I think of it, I think such a feature would greatly
> benefit GNU Emacs.

From my POV, the xwidget feature is incomplete and not maintained very
well.  As long as this is the case, extending such an incomplete
feature is waste of our resources.

Re: SVG widget in GNU Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> From my POV, the xwidget feature is incomplete and not maintained very
> well.  As long as this is the case, extending such an incomplete
> feature is waste of our resources.

I'm not sure I understand why the xwidget feature would be incomplete.
It seems to work OK for what it is currently intended to do: display web
content in an Emacs buffer.

But I'm probably missing something here.  Could you please elaborate
further?  Thanks.

Re: SVG widget in GNU Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org,  atamariya@gmail.com
> Date: Wed, 20 Oct 2021 20:48:15 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > From my POV, the xwidget feature is incomplete and not maintained very
> > well.  As long as this is the case, extending such an incomplete
> > feature is waste of our resources.
> 
> I'm not sure I understand why the xwidget feature would be incomplete.

Here's an example:

  static int
  scrolling_window (struct window *w, int tab_line_p)
  {
   ...
  #ifdef HAVE_XWIDGETS
    /* Currently this seems needed to detect xwidget movement reliably.
       This is most probably because an xwidget glyph is represented in
       struct glyph's 'union u' by a pointer to a struct, which takes 8
       bytes in 64-bit builds, and thus the comparison of u.val values
       done by GLYPH_EQUAL_P doesn't work reliably, since it assumes the
       size of the union is 4 bytes.  FIXME.  */
      return 0;
  #endif

This disables one of the more important display optimizations in an
Emacs compiled with xwidgets support.

> It seems to work OK for what it is currently intended to do: display web
> content in an Emacs buffer.
> 
> But I'm probably missing something here.  Could you please elaborate
> further?  Thanks.

Apart of the above, just look at xwidget.c and xwidget.el, and you
will see the FIXMEs, the incomplete doc strings, and other stuff left
unfinished.  The idea was that those will get finished once the
feature is in the sources, but unfortunately it didn't happen.

Re: SVG widget in GNU Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Here's an example:
>
>   static int
>   scrolling_window (struct window *w, int tab_line_p)
>   {
>    ...
>   #ifdef HAVE_XWIDGETS
>     /* Currently this seems needed to detect xwidget movement reliably.
>        This is most probably because an xwidget glyph is represented in
>        struct glyph's 'union u' by a pointer to a struct, which takes 8
>        bytes in 64-bit builds, and thus the comparison of u.val values
>        done by GLYPH_EQUAL_P doesn't work reliably, since it assumes the
>        size of the union is 4 bytes.  FIXME.  */
>       return 0;
>   #endif

> This disables one of the more important display optimizations in an
> Emacs compiled with xwidgets support.

Thanks.  Since I can't work on this right now, I'd like to ask if
changing the field `val' from `unsigned' to `void *' would work to
resolve this particular issue.

> Apart of the above, just look at xwidget.c and xwidget.el, and you
> will see the FIXMEs, the incomplete doc strings, and other stuff left
> unfinished.  The idea was that those will get finished once the
> feature is in the sources, but unfortunately it didn't happen.

Indeed, I see your point.  Thanks.

I will probably work on this once I get the time.

Re: SVG widget in GNU Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: atamariya@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 20 Oct 2021 21:17:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Here's an example:
> >
> >   static int
> >   scrolling_window (struct window *w, int tab_line_p)
> >   {
> >    ...
> >   #ifdef HAVE_XWIDGETS
> >     /* Currently this seems needed to detect xwidget movement reliably.
> >        This is most probably because an xwidget glyph is represented in
> >        struct glyph's 'union u' by a pointer to a struct, which takes 8
> >        bytes in 64-bit builds, and thus the comparison of u.val values
> >        done by GLYPH_EQUAL_P doesn't work reliably, since it assumes the
> >        size of the union is 4 bytes.  FIXME.  */
> >       return 0;
> >   #endif
> 
> > This disables one of the more important display optimizations in an
> > Emacs compiled with xwidgets support.
> 
> Thanks.  Since I can't work on this right now, I'd like to ask if
> changing the field `val' from `unsigned' to `void *' would work to
> resolve this particular issue.

I have no idea, but I wonder why it is needed for xwidgets, but not
for other components of that union.

> > Apart of the above, just look at xwidget.c and xwidget.el, and you
> > will see the FIXMEs, the incomplete doc strings, and other stuff left
> > unfinished.  The idea was that those will get finished once the
> > feature is in the sources, but unfortunately it didn't happen.
> 
> Indeed, I see your point.  Thanks.
> 
> I will probably work on this once I get the time.

Thanks, cleanup in that area will be appreciated.

Re: SVG widget in GNU Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I remember a proprietary version of Emacs (not derived from GNU Emacs)
  > having the ability to display arbitrary X Toolkit (such as Motif or
  > Athena widgets) widgets inside frames, along with providing protocol
  > bindings to X-Windows.

That feature could pose ethical/legal problems of linking with nonfree
widgets.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: SVG widget in GNU Emacs

[dalanicolai]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

I am not sure what x-widget push-button means exactly, but if they are just
buttons then we can achieve the same effect with default (text-)buttons.
This is used in the sketch-mode package (which just now arrived on elpa)
for showing previews of fonts.

On Thu, 21 Oct 2021 at 00:57, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I remember a proprietary version of Emacs (not derived from GNU Emacs)
>   > having the ability to display arbitrary X Toolkit (such as Motif or
>   > Athena widgets) widgets inside frames, along with providing protocol
>   > bindings to X-Windows.
>
> That feature could pose ethical/legal problems of linking with nonfree
> widgets.
>
> --
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1770 bytes --]

Re: SVG widget in GNU Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

>   > I remember a proprietary version of Emacs (not derived from GNU Emacs)
>   > having the ability to display arbitrary X Toolkit (such as Motif or
>   > Athena widgets) widgets inside frames, along with providing protocol
>   > bindings to X-Windows.

> That feature could pose ethical/legal problems of linking with nonfree
> widgets.

Hmm, how about limiting the selection to Athena or Motif widgets?
(Today, Motif is free software.)

Re: SVG widget in GNU Emacs

[dalanicolai]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

As I am a Spacemacs user, I've set the version to 1.0 a little too early. I
very quickly realized that I forgot to compile the file on vanilla Emacs
(and moreover, to copy the autoload from the `transient-version`). So I
fixed these things quickly, far before it arrived on Elpa, still the
'incorrect'
version is on Elpa now. I hope it gets updated soon (Is it really only once
per day?) 😬

On Thu, 21 Oct 2021 at 01:37, dalanicolai <dalanicolai@gmail.com> wrote:

> I am not sure what x-widget push-button means exactly, but if they are
> just buttons then we can achieve the same effect with default
> (text-)buttons.
> This is used in the sketch-mode package (which just now arrived on elpa)
> for showing previews of fonts.
>
> On Thu, 21 Oct 2021 at 00:57, Richard Stallman <rms@gnu.org> wrote:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > I remember a proprietary version of Emacs (not derived from GNU Emacs)
>>   > having the ability to display arbitrary X Toolkit (such as Motif or
>>   > Athena widgets) widgets inside frames, along with providing protocol
>>   > bindings to X-Windows.
>>
>> That feature could pose ethical/legal problems of linking with nonfree
>> widgets.
>>
>> --
>> Dr Richard Stallman (https://stallman.org)
>> Chief GNUisance of the GNU Project (https://gnu.org)
>> Founder, Free Software Foundation (https://fsf.org)
>> Internet Hall-of-Famer (https://internethalloffame.org)
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 2582 bytes --]

Re: SVG widget in GNU Emacs

[Akira Kyle]

On Wed, Oct 20, 2021 at 8:28 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > > Apart of the above, just look at xwidget.c and xwidget.el, and you
> > > will see the FIXMEs, the incomplete doc strings, and other stuff left
> > > unfinished.  The idea was that those will get finished once the
> > > feature is in the sources, but unfortunately it didn't happen.
> >
> > Indeed, I see your point.  Thanks.
> >
> > I will probably work on this once I get the time.
>
> Thanks, cleanup in that area will be appreciated.

IMHO the current xwidget implementation in emacs should deprecated. A
year ago I spent some time digging into all of this and the result was
my proof of concept emacs module that implemented the webkitgtk
functionally independent of xwidgets, called emac-webkit
(https://github.com/akirakyle/emacs-webkit and there's a thread that I
started here about a year ago to discuss this). The webkitgtk part of
xwidgets really is the only functional part, since the buttons and
other widgets have only an incomplete lisp interface and
implementation.

Po, if you're seriously considering cleaning up this code, it might be
wise to take a step back and consider what features its trying to
provide and how. There's a fundamental tension between the
buffer/window model of emacs and the way gtk implements a MVC paradigm
that makes it nontrivial for them to be compatible. This situation has
only worsened as gtk has been moving its api's to better support a
future with heavy reliance on gpu rendering. IIRC this means the
offscreen rendering technique employed by xwidgets is being deprecated
in gtk. Furthermore xwidgets was implemented before webkit was
transitioned to a containerized worker process architecture so there's
bugs one has to work through as gtk attempts to take back control of
things like signal masks that emacs controls when it initializes gtk.
My impression has actually been that the nsxwidgets have worked far
better and reliably since that was merged (in fact I remember coming
across some emacs package out there that relied on xwidgets, but that
only supported it on macOS as something or another was broken with
xwidgets on gtk). I suspect the transition from x11 to wayland has
introduced a lot of bugs and difficulties for really complex gtk
widgets like webkitgtk.

Ultimately I'd rather see effort go into getting pure gtk merged and
working to eliminate the mess of inpure mixtures of gtk and x11 code
from emacs (there could of course still be a "pure" X backend for
those who desire to run emacs with motif). I think as time goes on, it
will look worse and worse for emacs to need xwayland to run, as
distributions will stop including it by default.

Also I think there's a lot of work to be done on xdisp.c. As I've seen
here and elsewhere, there seems to be sustained interest in richer,
flexible display options to support things like multicolumns or
buffers in buffers without resorting to clever hacks that work around
around the limitations of the current linear character arrays that
emacs represents buffer data as. Browsers with the DOM have obviously
already solved this problem in a very general way, and it's quite
popular these days to leave such complexity and optimization effort to
the browser engine devs and use something like electron. I doubt the
emacs devs or maintainers would ever consent to running emacs on top
of chromium or webkit (although there's already the effort to have
emacs run on servo here https://github.com/emacs-ng/emacs-ng but that
just adds servo as a gui toolkit and doesn't attempt to touch
xdisp.c). So that leaves it to someone to really understand xdisp.c
enough to extend it in such a way that maintains the optimizations
people care about for text terminals, while allowing richer data
structures to be displayed efficiently by the modern gui toolkit
paradigms. No easy task.

Sorry for the long reply. I end up thinking about this topic whenever
I get frustrated with emacs' display engine. I wish I had the time to
work on this, but alas I've started grad school and don't even have
time to work emacs-webkit much.

GUI and redisplay work (was: SVG widget in GNU Emacs)

[Stefan Monnier]

> Ultimately I'd rather see effort go into getting pure gtk merged and

Yes, please.  This should be very high priority (sadly, this is way out
of my area of expertise).

> the browser engine devs and use something like electron. I doubt the
> emacs devs or maintainers would ever consent to running emacs on top
> of chromium or webkit (although there's already the effort to have

I think fundamentally it would be great for Emacs to reuse some existing
display engine rather than having to have our own.  But there are some
important issues:

1- We need to be able to open a 200MB log file with a snappy enough
   performance to be usable (including with a bit of font-locking).
   Most Web redisplay engines are not optimized for that case at all and
   many would tend to become completely unusable.  So if we want to use
   a web engine, we may still need some intermediate layer that feeds
   only part of the buffer to the underlying rendering engine.

2- It needs to support all the features that we currently support.
   Most engines provide *different* features from the ones we have,
   rather than just strictly more.

3- I plan for Emacs to still be around in 2050, but based on past
   experience I suspect that all the current Web engines will
   have been replaced before 2050.

So I think we need to see a Web engine as just another "backend
display", just like currently have X11, Gtk, NS, w32, and tty backends.
:-(


        Stefan

Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So I think we need to see a Web engine as just another "backend
> display", just like currently have X11, Gtk, NS, w32, and tty backends.
> :-(

Interesting stuff.  I don't have much of any substance to add, but I
realize that the discussion is quite important and I hope someone
would start serious work on something in this direction.

One thing I have been thinking about is how you would fit Emacs
concept of a buffer going from 'point-min' to 'point-max' and our
concept of a window as an x/y grid onto a HTML+CSS page in the general
case, where text and lines might be overlapping and displayed in all
kinds of weird and wonderful ways.

To take just a very simple example, when I say 'forward-line' in a web
page, I want to move point to the element (text or image) visually
above the current line, even if that section comes later in the actual
HTML file.  With CSS, text can be moved from anywhere, to anywhere on
the page, and that's not even considering what JavaScript might be
doing.

Does this present any fundamental difficulties, or are those merely
details to be worked out?

Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Po Lu <luangruo@yahoo.com>,  Emacs
>  developers <emacs-devel@gnu.org>
> Date: Tue, 26 Oct 2021 08:32:15 -0400
> 
> 2- It needs to support all the features that we currently support.
>    Most engines provide *different* features from the ones we have,
>    rather than just strictly more.

What's more, most of the features Stefan has in mind must be exposed
to Lisp, because without that Emacs will not be Emacs.

Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 26 Oct 2021 14:51:57 +0200
> Cc: Akira Kyle <ak@akirakyle.com>, Eli Zaretskii <eliz@gnu.org>, Po Lu <luangruo@yahoo.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> To take just a very simple example, when I say 'forward-line' in a web
> page, I want to move point to the element (text or image) visually
> above the current line, even if that section comes later in the actual
> HTML file.

That's vertical-motion in Emacs, so I'm not sure why you thought this
was a problem for us.  (The implementation is, of course, hairy, but
what do you care? ;-)

Re: SVG widget in GNU Emacs

[Po Lu]

Akira Kyle <ak@akirakyle.com> writes:

> IMHO the current xwidget implementation in emacs should deprecated.

Even though it's not very polished at present, I've seen a great deal of
code rely on the existing xwidgets support.  I think it would be best to
not make it obsolete.

> Po, if you're seriously considering cleaning up this code, it might be
> wise to take a step back and consider what features its trying to
> provide and how. There's a fundamental tension between the
> buffer/window model of emacs and the way gtk implements a MVC paradigm
> that makes it nontrivial for them to be compatible. This situation has
> only worsened as gtk has been moving its api's to better support a
> future with heavy reliance on gpu rendering. IIRC this means the
> offscreen rendering technique employed by xwidgets is being deprecated
> in gtk. Furthermore xwidgets was implemented before webkit was
> transitioned to a containerized worker process architecture so there's
> bugs one has to work through as gtk attempts to take back control of
> things like signal masks that emacs controls when it initializes gtk.
> My impression has actually been that the nsxwidgets have worked far
> better and reliably since that was merged (in fact I remember coming
> across some emacs package out there that relied on xwidgets, but that
> only supported it on macOS as something or another was broken with
> xwidgets on gtk). I suspect the transition from x11 to wayland has
> introduced a lot of bugs and difficulties for really complex gtk
> widgets like webkitgtk.

I understand what the problem in this area is.  But I'd rather have the
existing and (mostly) working xwidgets feature fixed than to waste time
implementing a new one.

> Ultimately I'd rather see effort go into getting pure gtk merged and
> working to eliminate the mess of inpure mixtures of gtk and x11 code
> from emacs (there could of course still be a "pure" X backend for
> those who desire to run emacs with motif). I think as time goes on, it
> will look worse and worse for emacs to need xwayland to run, as
> distributions will stop including it by default.

The pure GTK port will do nothing to resolve the issues here.  I worked
with that port a while ago, eventually porting it to GTK 4, but quickly
lost interest not soon after that.

In fact, I don't even see the problem with running Emacs in Xwayland.
I've been doing that for years ever since Fedora switched to using
Wayland by default, and I've never had any non-minor problems.

All and all, the PGTK port still keeps the existing X11+Cairo display
architecture.  On the GTK3 version of that port, xwidgets still work
like they do on X and NS.  They will not work on GTK 4 anyway, as the
GTK developers have deleted the ability to draw off-screen.

> Also I think there's a lot of work to be done on xdisp.c. As I've seen
> here and elsewhere, there seems to be sustained interest in richer,
> flexible display options to support things like multicolumns or
> buffers in buffers without resorting to clever hacks that work around
> around the limitations of the current linear character arrays that
> emacs represents buffer data as. Browsers with the DOM have obviously
> already solved this problem in a very general way, and it's quite
> popular these days to leave such complexity and optimization effort to
> the browser engine devs and use something like electron. I doubt the
> emacs devs or maintainers would ever consent to running emacs on top
> of chromium or webkit (although there's already the effort to have
> emacs run on servo here https://github.com/emacs-ng/emacs-ng but that

It uses WebRender as a window system for Emacs, not Servo.

Re: SVG widget in GNU Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>
> Date: Wed, 27 Oct 2021 17:47:03 +0800
> 
> > Po, if you're seriously considering cleaning up this code, it might be
> > wise to take a step back and consider what features its trying to
> > provide and how. There's a fundamental tension between the
> > buffer/window model of emacs and the way gtk implements a MVC paradigm
> > that makes it nontrivial for them to be compatible. This situation has
> > only worsened as gtk has been moving its api's to better support a
> > future with heavy reliance on gpu rendering. IIRC this means the
> > offscreen rendering technique employed by xwidgets is being deprecated
> > in gtk. Furthermore xwidgets was implemented before webkit was
> > transitioned to a containerized worker process architecture so there's
> > bugs one has to work through as gtk attempts to take back control of
> > things like signal masks that emacs controls when it initializes gtk.
> > My impression has actually been that the nsxwidgets have worked far
> > better and reliably since that was merged (in fact I remember coming
> > across some emacs package out there that relied on xwidgets, but that
> > only supported it on macOS as something or another was broken with
> > xwidgets on gtk). I suspect the transition from x11 to wayland has
> > introduced a lot of bugs and difficulties for really complex gtk
> > widgets like webkitgtk.
> 
> I understand what the problem in this area is.  But I'd rather have the
> existing and (mostly) working xwidgets feature fixed than to waste time
> implementing a new one.

If the technology on which xwidgets are based is being deprecated, let
alone a dead end, that time will not go wasted.

Re: SVG widget in GNU Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> I understand what the problem in this area is.  But I'd rather have the
>> existing and (mostly) working xwidgets feature fixed than to waste time
>> implementing a new one.

> If the technology on which xwidgets are based is being deprecated, let
> alone a dead end, that time will not go wasted.

I don't agree with the statement that they're a dead end, as offscreen
rendering is not deprecated in GTK 3, which will be with us for the
foreseeable future.  The changes introduced with GTK 4 are not relevant
for GTK 3 (and are of a more fundamental nature that put not just
offscreen rendering, but even the use of Cairo in danger).

Fundamentally, NS xwidgets work the same way as GTK xwidgets, by
displaying in an offscreen window, and then copying the contents of said
offscreen window to widgets that are created for each displayed xwidget.

That NS xwidgets (based on the same principles as GTK xwidgets), in
Akira's words, work better, shows there are no fundamental barriers
between briding GTK's rendering model and Emacs's display model.

Thanks.

Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[Alexandre Garreau]

Le mardi 26 octobre 2021, 14:32:15 CEST Stefan Monnier a écrit :
> > Ultimately I'd rather see effort go into getting pure gtk merged and
> 
> Yes, please.  This should be very high priority (sadly, this is way out
> of my area of expertise).
> 
> > the browser engine devs and use something like electron. I doubt the
> > emacs devs or maintainers would ever consent to running emacs on top
> > of chromium or webkit (although there's already the effort to have
> 
> I think fundamentally it would be great for Emacs to reuse some existing
> display engine rather than having to have our own.  But there are some
> important issues:
> 
> 1- We need to be able to open a 200MB log file with a snappy enough
>    performance to be usable (including with a bit of font-locking).
>    Most Web redisplay engines are not optimized for that case at all and
> many would tend to become completely unusable.  So if we want to use a
> web engine, we may still need some intermediate layer that feeds only
> part of the buffer to the underlying rendering engine.
> 
> 2- It needs to support all the features that we currently support.
>    Most engines provide *different* features from the ones we have,
>    rather than just strictly more.
> 
> 3- I plan for Emacs to still be around in 2050, but based on past
>    experience I suspect that all the current Web engines will
>    have been replaced before 2050.

All current Web engines derive from KHTML and Gecko, which are very old… 
wouldn’t the web engines in 2050 still derive from them, given their age?

On the other hand, TeX has now’ve been around for half a century, as long 
as emacs, and longer than the gnu (and nowadays main or even only 
seriously used) implementation of emacs, and it was several times (not 
only by me) drawn to attention as a layout engine whose structure/working 
might be interesting here (along with “bringing emacs on par with 
LibreOffice”, which also is an interesting comparison (LO still maintains 
its own display engine and doesn’t reuse gecko, servo, khtml, webkit, 
blink or anything like that right?)).

An important drawback is LibreOffice is imho slower than web browsers, and 
that TeX is atrociously slow compared to anything existing, due to the 
fact it was meant for one-time AOT compiling… and hence use *only* macros, 
and has no functions (by default, with its normal common evaluation) …
however ongoing current (I mean, since some years) attempt to improve 
TeX’s language/engine to make it faster but more importantly more 
readable, understandable (when you extend it a lot) and even more general, 
go into the direction of implementing real functions and complex and 
general datastructures on top of it (LaTeX3)… which seems to yet again 
lead a new language toward looking more like lisp… shouldn’t we take that 
as a hint or even encouragment?

We could also note that modern web engines have number of notorious 
drawbacks without attempts to be solved, such as typographical quality 
(TeX’s still leading, there), and performance (although they talk all the 
time about it, the very nature of the modern web (ephemeral pages and 
(proprietary) scripts rather than large files and long-lived (free) 
extensions) makes it mostly interpreted and way less efficient than a native 
gui such as gtk that emacs uses)…

And currently, am I wrong to suppose most emacs contributors are more 
familiar with TeX and GTK than the web, its engines and history?

Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Wed, Oct 27, 2021 at 06:07:53PM +0200, Alexandre Garreau wrote:

[...]

> All current Web engines derive from KHTML and Gecko, which are very old… 
> wouldn’t the web engines in 2050 still derive from them, given their age?
> 
> On the other hand, TeX has now’ve been around for half a century, as long 
> as emacs, and longer than the gnu (and nowadays main or even only 
> seriously used) implementation of emacs [...]

Before you start re-inventing the world, if I were you, I'd have a
look at what is "out there" already. Perhaps to contribute to it,
perhaps to copy it, but just perhaps to learn from it on how to
do (or not to do) things:

  https://en.wikipedia.org/wiki/GNU_TeXmacs
  http://texmacs.org/tmweb/home/welcome.en.html

I think Joris and the other (many!) contributors could share quite
a few stories...

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GUI and redisplay work (was: SVG widget in GNU Emacs)

[Alexandre Garreau]

Le mercredi 27 octobre 2021, 19:12:36 CEST tomas@tuxteam.de a écrit :
> On Wed, Oct 27, 2021 at 06:07:53PM +0200, Alexandre Garreau wrote:
> 
> [...]
> 
> > All current Web engines derive from KHTML and Gecko, which are very
> > old… wouldn’t the web engines in 2050 still derive from them, given
> > their age?
> > 
> > On the other hand, TeX has now’ve been around for half a century, as
> > long as emacs, and longer than the gnu (and nowadays main or even
> > only seriously used) implementation of emacs [...]
> 
> Before you start re-inventing the world, if I were you, I'd have a
> look at what is "out there" already. Perhaps to contribute to it,
> perhaps to copy it, but just perhaps to learn from it on how to
> do (or not to do) things:
> 
>   https://en.wikipedia.org/wiki/GNU_TeXmacs
>   http://texmacs.org/tmweb/home/welcome.en.html
> 
> I think Joris and the other (many!) contributors could share quite
> a few stories...

I know TeXmacs and since it initially enthusiastmed me a lot (iirc I even 
talked a bit with its author during a GHM a decade ago), I several times 
tried to use it but unfortunately my computer is too slow to run it 
fluently, so I gave up trying.

Moreover while WYSIWYM looked like a good idea orally, using TeXmacs was 
at the same time more confusing than standard markup, and WYSIWYG 
(although I typically use WYSIWYG only in a very very limited way), so 
maybe the idea is just too innovative to be easy to grasp from a single 
software that’s rarely used (I rarely typeset documents actually, 
especially to print anything, and I prefer to take notes in text editors 
because I don’t get margins nor slowness, I just compile them once when I 
export my exams to pdf).

Also looks like it’s only a text processor with it own format, and not a 
general purpose editor, that could edit, say, HTML or TeX, or, most 
importantly, its own config files, so it’s nor really like emacs, nor TeX :/

And although it looks as good as TeX typographically, it’s younger and 
could be less stable, but I’m sure there could be good ideas and 
experiment here… I just already don’t have the time and attention 
capability to work on emacs as much as I’d like (so I still haven’t 
contributed anything), and TeXmacs would be lower priority for me.

Also I’d like first and foremost to read and understand all TeX’s and 
Metafont’s source (especially as it’s heavily documented in its own 
favored way and made to be read that way), and understand how does GTK 
works, before to try to understand some software that uses the later to 
incompatibly mimmick the first.  I still haven’t done that.  And I should 
reread the TeXbook, but doing the exercises and reading the source at same 
time.

Re: SVG widget in GNU Emacs

[Akira Kyle]

On Wed, Oct 27, 2021 at 3:47 AM Po Lu <luangruo@yahoo.com> wrote:
>
> Even though it's not very polished at present, I've seen a great deal of
> code rely on the existing xwidgets support.  I think it would be best to
> not make it obsolete.

I'd be curious to see anyone in the past several years on a GNU/linux
system that actually uses xwidgets given that last I checked it
suffered from a rather severe flickering bug. I know people on macOS
regularly use it, especially since the popular homebrew-emacs-plus
formula enables it.

> I understand what the problem in this area is.  But I'd rather have the
> existing and (mostly) working xwidgets feature fixed than to waste time
> implementing a new one.

If you do figure out the flickering problem, I'd be very interested in
were the bug is. Last year I tried tracking it down to no avail. I
think I started to suspect it was a bug somewhere between the way GTK
handles offscreen rendering and the way emacs tries to take control of
GTK's event loop.

> The pure GTK port will do nothing to resolve the issues here.  I worked
> with that port a while ago, eventually porting it to GTK 4, but quickly
> lost interest not soon after that.

I didn't say it would, just that I think it should be a higher
priority project than resurrecting xwidgets on gtk.

> In fact, I don't even see the problem with running Emacs in Xwayland.
> I've been doing that for years ever since Fedora switched to using
> Wayland by default, and I've never had any non-minor problems.

I don't think it currently is, or ever will be, a technical problem.
The xwayland devs have made sure of that. I think its more of a
perception problem as wayland becomes adopted and users see apps
requiring xwayland as increasingly "unmaintained", "legacy" apps. I've
certainly seen such questions come up with newcomers, especially when
it comes to users on HiDPI displays so users can see a tangible
difference in the default font rendering between xwayland and native
wayland apps.

> All and all, the PGTK port still keeps the existing X11+Cairo display
> architecture.  On the GTK3 version of that port, xwidgets still work
> like they do on X and NS.  They will not work on GTK 4 anyway, as the
> GTK developers have deleted the ability to draw off-screen.

Exactly why I think for the sake of future compatibility with GTK 4,
it's best not to rely on off-screen rendering.

> It uses WebRender as a window system for Emacs, not Servo.

Yes, I was being loose with my terminology, given webrender is a
component of servo and at one point servo was the more well known
project. Since firefox adopting webrender, and stopping support for
servo development, I suppose the opposite case is now true.

Re: SVG widget in GNU Emacs

[Akira Kyle]

On Wed, Oct 27, 2021 at 6:25 AM Po Lu <luangruo@yahoo.com> wrote:
>
> I don't agree with the statement that they're a dead end, as offscreen
> rendering is not deprecated in GTK 3, which will be with us for the
> foreseeable future.  The changes introduced with GTK 4 are not relevant
> for GTK 3 (and are of a more fundamental nature that put not just
> offscreen rendering, but even the use of Cairo in danger).
>
> Fundamentally, NS xwidgets work the same way as GTK xwidgets, by
> displaying in an offscreen window, and then copying the contents of said
> offscreen window to widgets that are created for each displayed xwidget.

This is not true. Off-screen rendering of webkit views in NS does not
work. See the comment at the top of nsxwidgets. The NS xwidgets
implementation functions in the same (albeit slightly less elegant
way) as emacs-webkit. Namely it enforces a one to one correspondence
between the webview's buffer and it's window. When trying to display
the webview's buffer in two windows, NS xwidgets will message "You
can't share an xwidget (webkit2) among windows." and one window's
contents will be blank. emacs-webkit handles this by always moving the
webview to the focused window and changing the other window to the
next buffer.

> That NS xwidgets (based on the same principles as GTK xwidgets), in
> Akira's words, work better, shows there are no fundamental barriers
> between briding GTK's rendering model and Emacs's display model.

I don't think it's fair to say that just because something works
between emacs and NS, that it will work between emacs and gtk. While
their paradigms are similar, we cannot know how similar or dissimilar
their implementations are given that we cannot inspect the source code
of NS. Furthermore emacs does things differently in the impure X and
gtk display code then it does in the pure gtk display code and the NS
display code it was based on, especially as it concerns the display
event loop.

Re: SVG widget in GNU Emacs

[Po Lu]

Akira Kyle <ak@akirakyle.com> writes:

> I'd be curious to see anyone in the past several years on a GNU/linux
> system that actually uses xwidgets given that last I checked it
> suffered from a rather severe flickering bug. I know people on macOS
> regularly use it, especially since the popular homebrew-emacs-plus
> formula enables it.

If I understand correctly, Fedora Core builds Emacs with xwidgets
enabled by default.

> If you do figure out the flickering problem, I'd be very interested in
> were the bug is. Last year I tried tracking it down to no avail. I
> think I started to suspect it was a bug somewhere between the way GTK
> handles offscreen rendering and the way emacs tries to take control of
> GTK's event loop.

The flickering problem is not a real problem here, I think.  My theory
is that it can be fixed by moving the display to a separate X window,
instead of a GtkDrawingArea.

(Perhaps by using `gdk_window_ensure_native' on the drawing area's
window, but I'm unsure if that approach still works on GTK 3 as it did
on GTK+ 2.)

> I don't think it currently is, or ever will be, a technical problem.
> The xwayland devs have made sure of that. I think its more of a
> perception problem as wayland becomes adopted and users see apps
> requiring xwayland as increasingly "unmaintained", "legacy" apps. I've
> certainly seen such questions come up with newcomers, especially when
> it comes to users on HiDPI displays so users can see a tangible
> difference in the default font rendering between xwayland and native
> wayland apps.

Does Xwayland not support HiDPI displays?

> Exactly why I think for the sake of future compatibility with GTK 4,
> it's best not to rely on off-screen rendering.

If future compatibility with GTK 4 is really such a concern, we should
not even be using cairo.

Re: SVG widget in GNU Emacs

[Po Lu]

Akira Kyle <ak@akirakyle.com> writes:

> This is not true. Off-screen rendering of webkit views in NS does not
> work. See the comment at the top of nsxwidgets. The NS xwidgets
> implementation functions in the same (albeit slightly less elegant
> way) as emacs-webkit. Namely it enforces a one to one correspondence
> between the webview's buffer and it's window. When trying to display
> the webview's buffer in two windows, NS xwidgets will message "You
> can't share an xwidget (webkit2) among windows." and one window's
> contents will be blank. emacs-webkit handles this by always moving the
> webview to the focused window and changing the other window to the
> next buffer.

OK, my bad.  Sorry for that.

P.S. isn't emacs-webkit still a native module that runs within Emacs?

If that is true, then it means emacs-webkit (on GLib builds) will still
drive the GTK/GLib event loop through Emacs code (in xgselect.c), which
is identical to how X11 Emacs does it.

And then nothing prevents WebKitGtk from messing with the SIGCHLD
handler.

> I don't think it's fair to say that just because something works
> between emacs and NS, that it will work between emacs and gtk. While
> their paradigms are similar, we cannot know how similar or dissimilar
> their implementations are given that we cannot inspect the source code
> of NS.

One can inspect the source code of NS, through one of the two
implementations I'm aware of that have source code available: GNUstep
and the Cocoatron.  But I don't think that degree of access is
important, or even required, to determine basic implementation details
like this.

> Furthermore emacs does things differently in the impure X and gtk
> display code then it does in the pure gtk display code and the NS
> display code it was based on, especially as it concerns the display
> event loop.

But how is that a problem?  It doesn't affect the ability of
GtkOffscreenWindow to function correctly, for one.  I verified that long
ago.

Re: SVG widget in GNU Emacs

[Eli Zaretskii]

> From: Akira Kyle <ak@akirakyle.com>
> Date: Wed, 27 Oct 2021 13:49:21 -0600
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> I'd be curious to see anyone in the past several years on a GNU/linux
> system that actually uses xwidgets given that last I checked it
> suffered from a rather severe flickering bug.

Isn't that flickering a direct consequence of the fact that xwidgets
disable an important optimization in scrolling_window?

Re: SVG widget in GNU Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Isn't that flickering a direct consequence of the fact that xwidgets
> disable an important optimization in scrolling_window?

I suspect the problem lies, rather, in Emacs painting over widgets.

Since 2.18 GTK+ has stopped giving widgets individual X windows by
default, so drawing the glyph string background in x_draw_glyph_string
causes flickering, because it is actually painting over the widget's
native X window.

This is because Emacs uses X drawing primitives (or a cairo xlib
surface, not a surface provided by GTK), that GTK doesn't know about.

Fix flickering on X11 xwidgets (was: Re: SVG widget in GNU Emacs)

[Po Lu]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]


And to confirm my suspicions, moving xwidget rendering to an X window
does indeed fix the flicker.

Please test the attached patch.

(Unfortunately, I haven't been able to enable the scrolling optimization
yet, as it will now involve moving X windows around on-screen, but I
think I know how to do it and will let you know ASAP if I complete
that.)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-an-X-window-to-display-xwidgets-on-X11.patch --]
[-- Type: text/x-patch, Size: 17350 bytes --]

From 131416ea626309d34585301727a4311d25e3fd10 Mon Sep 17 00:00:00 2001
From: Po Lu <luangruo@yahoo.com>
Date: Thu, 28 Oct 2021 21:46:01 +0800
Subject: [PATCH] Use an X window to display xwidgets on X11

Since Emacs draws using X11 primitives, Emacs drawing operations can
erase the GtkDrawingArea used to draw the offscreen widget, which
leads to unpleasant flickering effects, all of which can be prevented
by creating a native X window and drawing to that instead.

* src/xterm.c (x_window_to_frame): Return xwidget window if
appropriate.
(handle_one_xevent): Handle xwidget expose events.

* src/xwidget.c (x_window_to_xvw_map): New variable.
(xwidget_view_from_window): New function.

(xwidget_show_view, xwidget_hide_view)
(offscreen_damage_event): Move to drawing xwidgets with X windows.

(xv_do_draw)
(xwidget_expose): New function.

(xwidget_osr_draw_cb, xwidget_osr_event_forward)
(xwidget_osr_event_set_embedder): Removed.

(xwidget_init_view): Replace use of GtkDrawingArea with that of an X
window.

(x_draw_xwidget_glyph_string): Prevent xwidget views from constantly
generating expose events, and use an X window instead of a
GtkDrawingArea.

(syms_of_xwidget): Initialize x_window_to_xwv_map.

src/xwidget.h (struct xwidget_view): Replace GTK widgets with
X-related fields.

(xwidget_view_from_window, xwidget_expose): New functions.
---
 src/xterm.c   |  24 ++++-
 src/xwidget.c | 277 ++++++++++++++++++++++++++------------------------
 src/xwidget.h |  12 ++-
 3 files changed, 175 insertions(+), 138 deletions(-)

diff --git a/src/xterm.c b/src/xterm.c
index aa1a1a5eed..54bfb65bd0 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -4563,8 +4563,9 @@ x_focus_changed (int type, int state, struct x_display_info *dpyinfo, struct fra
     }
 }
 
-/* Return the Emacs frame-object corresponding to an X window.
-   It could be the frame's main window or an icon window.  */
+/* Return the Emacs frame-object corresponding to an X window.  It
+   could be the frame's main window, an icon window, or an xwidget
+   window.  */
 
 static struct frame *
 x_window_to_frame (struct x_display_info *dpyinfo, int wdesc)
@@ -4575,6 +4576,13 @@ x_window_to_frame (struct x_display_info *dpyinfo, int wdesc)
   if (wdesc == None)
     return NULL;
 
+#ifdef HAVE_XWIDGETS
+  struct xwidget_view *xvw = xwidget_view_from_window (wdesc);
+
+  if (xvw && xvw->frame)
+    return xvw->frame;
+#endif
+
   FOR_EACH_FRAME (tail, frame)
     {
       f = XFRAME (frame);
@@ -8211,6 +8219,18 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 
     case Expose:
       f = x_window_to_frame (dpyinfo, event->xexpose.window);
+#ifdef HAVE_XWIDGETS
+      {
+	struct xwidget_view *xv =
+	  xwidget_view_from_window (event->xexpose.window);
+
+	if (xv)
+	  {
+	    xwidget_expose (xv);
+	    goto OTHER;
+	  }
+      }
+#endif
       if (f)
         {
           if (!FRAME_VISIBLE_P (f))
diff --git a/src/xwidget.c b/src/xwidget.c
index e4b42e6e0c..1bd27091d0 100644
--- a/src/xwidget.c
+++ b/src/xwidget.c
@@ -35,10 +35,16 @@ Copyright (C) 2011-2021 Free Software Foundation, Inc.
 #ifdef USE_GTK
 #include <webkit2/webkit2.h>
 #include <JavaScriptCore/JavaScript.h>
+#include <cairo.h>
+#include <X11/Xlib.h>
 #elif defined NS_IMPL_COCOA
 #include "nsxwidget.h"
 #endif
 
+#ifdef USE_GTK
+static Lisp_Object x_window_to_xwv_map;
+#endif
+
 static struct xwidget *
 allocate_xwidget (void)
 {
@@ -222,15 +228,28 @@ xwidget_hidden (struct xwidget_view *xv)
 }
 
 #ifdef USE_GTK
+
+struct xwidget_view *
+xwidget_view_from_window (Window wdesc)
+{
+  Lisp_Object key = make_fixnum (wdesc);
+  Lisp_Object xwv = Fgethash (key, x_window_to_xwv_map, Qnil);
+
+  if (NILP (xwv))
+    return NULL;
+
+  return XXWIDGET_VIEW (xwv);
+}
+
 static void
 xwidget_show_view (struct xwidget_view *xv)
 {
   xv->hidden = false;
-  gtk_widget_show (xv->widgetwindow);
-  gtk_fixed_move (GTK_FIXED (xv->emacswindow),
-                  xv->widgetwindow,
-                  xv->x + xv->clip_left,
-                  xv->y + xv->clip_top);
+  XMoveWindow (xv->dpy, xv->wdesc,
+	       xv->x + xv->clip_left,
+	       xv->y + xv->clip_top);
+  XMapWindow (xv->dpy, xv->wdesc);
+  XFlush (xv->dpy);
 }
 
 /* Hide an xwidget view.  */
@@ -238,28 +257,48 @@ xwidget_show_view (struct xwidget_view *xv)
 xwidget_hide_view (struct xwidget_view *xv)
 {
   xv->hidden = true;
-  gtk_fixed_move (GTK_FIXED (xv->emacswindow), xv->widgetwindow,
-                  10000, 10000);
+  XUnmapWindow (xv->dpy, xv->wdesc);
+  XFlush (xv->dpy);
+}
+
+static void
+xv_do_draw (struct xwidget_view *xw, struct xwidget *w)
+{
+  block_input ();
+
+  cairo_save (xw->cr_context);
+  cairo_translate (xw->cr_context, -xw->clip_left,
+		   -xw->clip_top);
+  gtk_widget_draw (w->widget_osr, xw->cr_context);
+  cairo_restore (xw->cr_context);
+
+  unblock_input ();
 }
 
 /* When the off-screen webkit master view changes this signal is called.
    It copies the bitmap from the off-screen instance.  */
 static gboolean
 offscreen_damage_event (GtkWidget *widget, GdkEvent *event,
-                        gpointer xv_widget)
+                        gpointer xwidget_view)
 {
-  /* Queue a redraw of onscreen widget.
-     There is a guard against receiving an invalid widget,
-     which should only happen if we failed to remove the
-     specific signal handler for the damage event.  */
-  if (GTK_IS_WIDGET (xv_widget))
-    gtk_widget_queue_draw (GTK_WIDGET (xv_widget));
-  else
-    message ("Warning, offscreen_damage_event received invalid xv pointer:%p\n",
-             xv_widget);
+  struct xwidget_view *xw = xwidget_view;
+  struct xwidget *w = XXWIDGET (xw->model);
+
+  if (xw->wdesc == None)
+    return FALSE;
+
+  xv_do_draw (xw, w);
 
   return FALSE;
 }
+
+void
+xwidget_expose (struct xwidget_view *xv)
+{
+  struct xwidget *xw = XXWIDGET (xv->model);
+
+  xv_do_draw (xv, xw);
+}
 #endif /* USE_GTK */
 
 void
@@ -498,51 +537,6 @@ webkit_decide_policy_cb (WebKitWebView *webView,
     return FALSE;
   }
 }
-
-
-/* For gtk3 offscreen rendered widgets.  */
-static gboolean
-xwidget_osr_draw_cb (GtkWidget *widget, cairo_t *cr, gpointer data)
-{
-  struct xwidget *xw = g_object_get_data (G_OBJECT (widget), XG_XWIDGET);
-  struct xwidget_view *xv = g_object_get_data (G_OBJECT (widget),
-                                               XG_XWIDGET_VIEW);
-
-  cairo_rectangle (cr, 0, 0, xv->clip_right, xv->clip_bottom);
-  cairo_clip (cr);
-
-  gtk_widget_draw (xw->widget_osr, cr);
-  return FALSE;
-}
-
-static gboolean
-xwidget_osr_event_forward (GtkWidget *widget, GdkEvent *event,
-			   gpointer user_data)
-{
-  /* Copy events that arrive at the outer widget to the offscreen widget.  */
-  struct xwidget *xw = g_object_get_data (G_OBJECT (widget), XG_XWIDGET);
-  GdkEvent *eventcopy = gdk_event_copy (event);
-  eventcopy->any.window = gtk_widget_get_window (xw->widget_osr);
-
-  /* TODO: This might leak events.  They should be deallocated later,
-     perhaps in xwgir_event_cb.  */
-  gtk_main_do_event (eventcopy);
-
-  /* Don't propagate this event further.  */
-  return TRUE;
-}
-
-static gboolean
-xwidget_osr_event_set_embedder (GtkWidget *widget, GdkEvent *event,
-				gpointer data)
-{
-  struct xwidget_view *xv = data;
-  struct xwidget *xww = XXWIDGET (xv->model);
-  gdk_offscreen_window_set_embedder (gtk_widget_get_window
-				     (xww->widgetwindow_osr),
-                                     gtk_widget_get_window (xv->widget));
-  return FALSE;
-}
 #endif /* USE_GTK */
 
 
@@ -568,63 +562,21 @@ xwidget_init_view (struct xwidget *xww,
   XSETXWIDGET (xv->model, xww);
 
 #ifdef USE_GTK
-  if (EQ (xww->type, Qwebkit))
-    {
-      xv->widget = gtk_drawing_area_new ();
-      /* Expose event handling.  */
-      gtk_widget_set_app_paintable (xv->widget, TRUE);
-      gtk_widget_add_events (xv->widget, GDK_ALL_EVENTS_MASK);
-
-      /* Draw the view on damage-event.  */
-      g_signal_connect (G_OBJECT (xww->widgetwindow_osr), "damage-event",
-                        G_CALLBACK (offscreen_damage_event), xv->widget);
-
-      if (EQ (xww->type, Qwebkit))
-        {
-          g_signal_connect (G_OBJECT (xv->widget), "button-press-event",
-                            G_CALLBACK (xwidget_osr_event_forward), NULL);
-          g_signal_connect (G_OBJECT (xv->widget), "button-release-event",
-                            G_CALLBACK (xwidget_osr_event_forward), NULL);
-          g_signal_connect (G_OBJECT (xv->widget), "motion-notify-event",
-                            G_CALLBACK (xwidget_osr_event_forward), NULL);
-        }
-      else
-        {
-          /* xwgir debug, orthogonal to forwarding.  */
-          g_signal_connect (G_OBJECT (xv->widget), "enter-notify-event",
-                            G_CALLBACK (xwidget_osr_event_set_embedder), xv);
-        }
-      g_signal_connect (G_OBJECT (xv->widget), "draw",
-                        G_CALLBACK (xwidget_osr_draw_cb), NULL);
-    }
+  xv->dpy = FRAME_X_DISPLAY (s->f);
 
-  /* Widget realization.
-
-     Make container widget first, and put the actual widget inside the
-     container later.  Drawing should crop container window if necessary
-     to handle case where xwidget is partially obscured by other Emacs
-     windows.  Other containers than gtk_fixed where explored, but
-     gtk_fixed had the most predictable behavior so far.  */
-
-  xv->emacswindow = FRAME_GTK_WIDGET (s->f);
-  xv->widgetwindow = gtk_fixed_new ();
-  gtk_widget_set_has_window (xv->widgetwindow, TRUE);
-  gtk_container_add (GTK_CONTAINER (xv->widgetwindow), xv->widget);
-
-  /* Store some xwidget data in the gtk widgets.  */
-  g_object_set_data (G_OBJECT (xv->widget), XG_FRAME_DATA, s->f);
-  g_object_set_data (G_OBJECT (xv->widget), XG_XWIDGET, xww);
-  g_object_set_data (G_OBJECT (xv->widget), XG_XWIDGET_VIEW, xv);
-  g_object_set_data (G_OBJECT (xv->widgetwindow), XG_XWIDGET, xww);
-  g_object_set_data (G_OBJECT (xv->widgetwindow), XG_XWIDGET_VIEW, xv);
-
-  gtk_widget_set_size_request (GTK_WIDGET (xv->widget), xww->width,
-                               xww->height);
-  gtk_widget_set_size_request (xv->widgetwindow, xww->width, xww->height);
-  gtk_fixed_put (GTK_FIXED (FRAME_GTK_WIDGET (s->f)), xv->widgetwindow, x, y);
   xv->x = x;
   xv->y = y;
-  gtk_widget_show_all (xv->widgetwindow);
+
+  xv->clip_left = 0;
+  xv->clip_right = xww->width;
+  xv->clip_top = 0;
+  xv->clip_bottom = xww->height;
+
+  xv->wdesc = None;
+  xv->frame = s->f;
+
+  g_signal_connect (G_OBJECT (xww->widgetwindow_osr), "damage-event",
+		    G_CALLBACK (offscreen_damage_event), xv);
 #elif defined NS_IMPL_COCOA
   nsxwidget_init_view (xv, xww, s, x, y);
   nsxwidget_resize_view(xv, xww->width, xww->height);
@@ -681,6 +633,8 @@ x_draw_xwidget_glyph_string (struct glyph_string *s)
   window_box (s->w, TEXT_AREA, &text_area_x, &text_area_y,
               &text_area_width, &text_area_height);
 
+  /* On X11, this keeps generating expose events.  */
+#ifndef USE_GTK
   /* Resize xwidget webkit if its container window size is changed in
      some ways, for example, a buffer became hidden in small split
      window, then it can appear front in merged whole window.  */
@@ -693,6 +647,7 @@ x_draw_xwidget_glyph_string (struct glyph_string *s)
                        make_int (text_area_width),
                        make_int (text_area_height));
     }
+#endif
 
   clip_left = max (0, text_area_x - x);
   clip_right = max (clip_left,
@@ -711,15 +666,45 @@ x_draw_xwidget_glyph_string (struct glyph_string *s)
      later.  */
   bool moved = (xv->x + xv->clip_left != x + clip_left
 		|| xv->y + xv->clip_top != y + clip_top);
+
+#ifdef USE_GTK
+  bool wdesc_was_none = xv->wdesc == None;
+#endif
   xv->x = x;
   xv->y = y;
 
+#ifdef USE_GTK
+  block_input ();
+  if (xv->wdesc == None)
+    {
+      Lisp_Object xvw;
+      XSETXWIDGET_VIEW (xvw, xv);
+      XSetWindowAttributes a;
+      a.event_mask = ExposureMask;
+
+      xv->wdesc = XCreateWindow (xv->dpy, FRAME_X_WINDOW (s->f),
+				 x + clip_left, y + clip_top,
+				 clip_right - clip_left,
+				 clip_bottom - clip_top, 0,
+				 CopyFromParent, CopyFromParent,
+				 CopyFromParent, CWEventMask, &a);
+      xv->cr_surface = cairo_xlib_surface_create (xv->dpy,
+						  xv->wdesc,
+						  FRAME_DISPLAY_INFO (s->f)->visual,
+						  clip_right - clip_left,
+						  clip_bottom - clip_top);
+      xv->cr_context = cairo_create (xv->cr_surface);
+      Fputhash (make_fixnum (xv->wdesc), xvw, x_window_to_xwv_map);
+
+      moved = false;
+    }
+#endif
+
   /* Has it moved?  */
   if (moved)
     {
 #ifdef USE_GTK
-      gtk_fixed_move (GTK_FIXED (FRAME_GTK_WIDGET (s->f)),
-                      xv->widgetwindow, x + clip_left, y + clip_top);
+      XMoveWindow (xv->dpy, xv->wdesc, x + clip_left, y + clip_top);
 #elif defined NS_IMPL_COCOA
       nsxwidget_move_view (xv, x + clip_left, y + clip_top);
 #endif
@@ -735,10 +720,14 @@ x_draw_xwidget_glyph_string (struct glyph_string *s)
       || xv->clip_top != clip_top || xv->clip_left != clip_left)
     {
 #ifdef USE_GTK
-      gtk_widget_set_size_request (xv->widgetwindow, clip_right - clip_left,
-                                   clip_bottom - clip_top);
-      gtk_fixed_move (GTK_FIXED (xv->widgetwindow), xv->widget, -clip_left,
-                      -clip_top);
+      if (!wdesc_was_none)
+	{
+	  XResizeWindow (xv->dpy, xv->wdesc, clip_right - clip_left,
+			 clip_bottom - clip_top);
+	  XFlush (xv->dpy);
+	  cairo_xlib_surface_set_size (xv->cr_surface, clip_right - clip_left,
+				       clip_bottom - clip_top);
+	}
 #elif defined NS_IMPL_COCOA
       nsxwidget_resize_view (xv, clip_right - clip_left,
                              clip_bottom - clip_top);
@@ -758,12 +747,15 @@ x_draw_xwidget_glyph_string (struct glyph_string *s)
   if (!xwidget_hidden (xv))
     {
 #ifdef USE_GTK
-      gtk_widget_queue_draw (xv->widgetwindow);
-      gtk_widget_queue_draw (xv->widget);
+      xv_do_draw (xv, xww);
 #elif defined NS_IMPL_COCOA
       nsxwidget_set_needsdisplay (xv);
 #endif
     }
+
+#ifdef USE_GTK
+  unblock_input ();
+#endif
 }
 
 static bool
@@ -976,8 +968,13 @@ DEFUN ("xwidget-resize", Fxwidget_resize, Sxwidget_resize, 3, 3, 0,
           if (XXWIDGET (xv->model) == xw)
             {
 #ifdef USE_GTK
-              gtk_widget_set_size_request (GTK_WIDGET (xv->widget), xw->width,
-                                           xw->height);
+	      if (xv->wdesc != None)
+		{
+		  XResizeWindow (xv->dpy, xv->wdesc, xw->width, xw->height);
+		  XFlush (xv->dpy);
+		  cairo_xlib_surface_set_size (xv->cr_surface,
+					       xw->width, xw->height);
+		}
 #elif defined NS_IMPL_COCOA
               nsxwidget_resize_view(xv, xw->width, xw->height);
 #endif
@@ -1084,13 +1081,21 @@ DEFUN ("delete-xwidget-view",
   CHECK_XWIDGET_VIEW (xwidget_view);
   struct xwidget_view *xv = XXWIDGET_VIEW (xwidget_view);
 #ifdef USE_GTK
-  gtk_widget_destroy (xv->widgetwindow);
-  /* xv->model still has signals pointing to the view.  There can be
-     several views.  Find the matching signals and delete them all.  */
-  g_signal_handlers_disconnect_matched  (XXWIDGET (xv->model)->widgetwindow_osr,
-                                         G_SIGNAL_MATCH_DATA,
-                                         0, 0, 0, 0,
-                                         xv->widget);
+  if (xv->wdesc != None)
+    {
+      block_input ();
+      XDestroyWindow (xv->dpy, xv->wdesc);
+      /* xv->model still has signals pointing to the view.  There can be
+	 several views.  Find the matching signals and delete them all.  */
+      g_signal_handlers_disconnect_matched  (XXWIDGET (xv->model)->widgetwindow_osr,
+					     G_SIGNAL_MATCH_DATA,
+					     0, 0, 0, 0, xv);
+
+      cairo_destroy (xv->cr_context);
+      cairo_surface_destroy (xv->cr_surface);
+      Fputhash (make_fixnum (xv->wdesc), Qnil, x_window_to_xwv_map);
+      unblock_input ();
+    }
 #elif defined NS_IMPL_COCOA
   nsxwidget_delete_view (xv);
 #endif
@@ -1236,6 +1241,12 @@ syms_of_xwidget (void)
   Vxwidget_view_list = Qnil;
 
   Fprovide (intern ("xwidget-internal"), Qnil);
+
+#ifdef USE_GTK
+  x_window_to_xwv_map = CALLN (Fmake_hash_table, QCtest, Qequal);
+
+  staticpro (&x_window_to_xwv_map);
+#endif
 }
 
 
diff --git a/src/xwidget.h b/src/xwidget.h
index 591f23489d..fc68b52cdb 100644
--- a/src/xwidget.h
+++ b/src/xwidget.h
@@ -32,6 +32,7 @@ #define XWIDGET_H_INCLUDED
 
 #if defined (USE_GTK)
 #include <gtk/gtk.h>
+#include <X11/Xlib.h>
 #elif defined (NS_IMPL_COCOA) && defined (__OBJC__)
 #import <AppKit/NSView.h>
 #import "nsxwidget.h"
@@ -98,9 +99,12 @@ #define XWIDGET_H_INCLUDED
   bool hidden;
 
 #if defined (USE_GTK)
-  GtkWidget *widget;
-  GtkWidget *widgetwindow;
-  GtkWidget *emacswindow;
+  Display *dpy;
+  Window wdesc;
+  struct frame *frame;
+
+  cairo_surface_t *cr_surface;
+  cairo_t *cr_context;
 #elif defined (NS_IMPL_COCOA)
 # ifdef __OBJC__
   XvWindow *xvWindow;
@@ -162,6 +166,8 @@ #define XG_XWIDGET_VIEW "emacs_xwidget_view"
 void store_xwidget_js_callback_event (struct xwidget *xw,
                                       Lisp_Object proc,
                                       Lisp_Object argument);
+struct xwidget_view *xwidget_view_from_window (Window wdesc);
+void xwidget_expose (struct xwidget_view *xv);
 #else
 INLINE_HEADER_BEGIN
 INLINE void syms_of_xwidget (void) {}
-- 
2.31.1

Re: GUI and redisplay work

[Arthur Miller]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> Le mercredi 27 octobre 2021, 19:12:36 CEST tomas@tuxteam.de a écrit :
>> On Wed, Oct 27, 2021 at 06:07:53PM +0200, Alexandre Garreau wrote:
>> 
>> [...]
>> 
>> > All current Web engines derive from KHTML and Gecko, which are very
>> > old… wouldn’t the web engines in 2050 still derive from them, given
>> > their age?
>> > 
>> > On the other hand, TeX has now’ve been around for half a century, as
>> > long as emacs, and longer than the gnu (and nowadays main or even
>> > only seriously used) implementation of emacs [...]
>> 
>> Before you start re-inventing the world, if I were you, I'd have a
>> look at what is "out there" already. Perhaps to contribute to it,
>> perhaps to copy it, but just perhaps to learn from it on how to
>> do (or not to do) things:
>> 
>>   https://en.wikipedia.org/wiki/GNU_TeXmacs
>>   http://texmacs.org/tmweb/home/welcome.en.html
>> 
>> I think Joris and the other (many!) contributors could share quite
>> a few stories...
>
> I know TeXmacs and since it initially enthusiastmed me a lot (iirc I even 
> talked a bit with its author during a GHM a decade ago), I several times 
> tried to use it but unfortunately my computer is too slow to run it 
> fluently, so I gave up trying.
>
> Moreover while WYSIWYM looked like a good idea orally, using TeXmacs was 
> at the same time more confusing than standard markup, and WYSIWYG 
> (although I typically use WYSIWYG only in a very very limited way), so 
> maybe the idea is just too innovative to be easy to grasp from a single 
> software that’s rarely used (I rarely typeset documents actually, 
> especially to print anything, and I prefer to take notes in text editors 
> because I don’t get margins nor slowness, I just compile them once when I 
> export my exams to pdf).
>
> Also looks like it’s only a text processor with it own format, and not a 
> general purpose editor, that could edit, say, HTML or TeX, or, most 
> importantly, its own config files, so it’s nor really like emacs, nor TeX :/
>
> And although it looks as good as TeX typographically, it’s younger and 
> could be less stable, but I’m sure there could be good ideas and 
> experiment here… I just already don’t have the time and attention 
> capability to work on emacs as much as I’d like (so I still haven’t 
> contributed anything), and TeXmacs would be lower priority for me.
>
> Also I’d like first and foremost to read and understand all TeX’s and 
> Metafont’s source (especially as it’s heavily documented in its own 
> favored way and made to be read that way), and understand how does GTK 
> works, before to try to understand some software that uses the later to 
> incompatibly mimmick the first.  I still haven’t done that.  And I should 
> reread the TeXbook, but doing the exercises and reading the source at same 
> time.

Have you checked out Nyxt browser?

https://nyxt.atlas.engineer/

CL + another widget derived from khtml ...

I am quite sure someone could develop a text editor based on "web technologies"
or just in pure CL that works in Nyxt.

Re: GUI and redisplay work

[Alexandre Garreau]

Le vendredi 29 octobre 2021, 19:34:14 CEST Arthur Miller a écrit :
> Alexandre Garreau <galex-713@galex-713.eu> writes:
> > Le mercredi 27 octobre 2021, 19:12:36 CEST tomas@tuxteam.de a écrit :
> >> On Wed, Oct 27, 2021 at 06:07:53PM +0200, Alexandre Garreau wrote:
> >> 
> >> [...]
> >> 
> >> > All current Web engines derive from KHTML and Gecko, which are very
> >> > old… wouldn’t the web engines in 2050 still derive from them, given
> >> > their age?
> >> > 
> >> > On the other hand, TeX has now’ve been around for half a century,
> >> > as
> >> > long as emacs, and longer than the gnu (and nowadays main or even
> >> > only seriously used) implementation of emacs [...]
> >> 
> >> Before you start re-inventing the world, if I were you, I'd have a
> >> look at what is "out there" already. Perhaps to contribute to it,
> >> perhaps to copy it, but just perhaps to learn from it on how to
> >> 
> >> do (or not to do) things:
> >>   https://en.wikipedia.org/wiki/GNU_TeXmacs
> >>   http://texmacs.org/tmweb/home/welcome.en.html
> >> 
> >> I think Joris and the other (many!) contributors could share quite
> >> a few stories...
> > 
> > I know TeXmacs and since it initially enthusiastmed me a lot (iirc I
> > even talked a bit with its author during a GHM a decade ago), I
> > several times tried to use it but unfortunately my computer is too
> > slow to run it fluently, so I gave up trying.
> > 
> > Moreover while WYSIWYM looked like a good idea orally, using TeXmacs
> > was at the same time more confusing than standard markup, and WYSIWYG
> > (although I typically use WYSIWYG only in a very very limited way),
> > so maybe the idea is just too innovative to be easy to grasp from a
> > single software that’s rarely used (I rarely typeset documents
> > actually, especially to print anything, and I prefer to take notes in
> > text editors because I don’t get margins nor slowness, I just compile
> > them once when I export my exams to pdf).
> > 
> > Also looks like it’s only a text processor with it own format, and not
> > a general purpose editor, that could edit, say, HTML or TeX, or, most
> > importantly, its own config files, so it’s nor really like emacs, nor
> > TeX :/
> > 
> > And although it looks as good as TeX typographically, it’s younger and
> > could be less stable, but I’m sure there could be good ideas and
> > experiment here… I just already don’t have the time and attention
> > capability to work on emacs as much as I’d like (so I still haven’t
> > contributed anything), and TeXmacs would be lower priority for me.
> > 
> > Also I’d like first and foremost to read and understand all TeX’s and
> > Metafont’s source (especially as it’s heavily documented in its own
> > favored way and made to be read that way), and understand how does GTK
> > works, before to try to understand some software that uses the later
> > to
> > incompatibly mimmick the first.  I still haven’t done that.  And I
> > should reread the TeXbook, but doing the exercises and reading the
> > source at same time.
> 
> Have you checked out Nyxt browser?
> 
> https://nyxt.atlas.engineer/
> 
> CL + another widget derived from khtml ...
> 
> I am quite sure someone could develop a text editor based on "web
> technologies" or just in pure CL that works in Nyxt.

That’s very very interesting, and it pretty much looks like what I always 
imagined when I imagined a web engine inside emacs… at least the minimal 
part of it.  In the bigger pictures, it *oughts* to integrate with 
javascript, give access to its DOM API to lisp, allow finegrained control 
of scripts (like NoScript but more developed, like including information 
about network/inter-site communication, which APIs are enabled, allowing 
to let APIs to *lie* to the remote program, and, most importantly, 
reacting to licenses and source informations, just as LibreJS, but more 
developed (for instance involving the ability to detect obfuscation, to 
archive executed programs, share them (if the program *really* is free 
that’s anyway legal however you do it), rate them (the most readable 
(hence the most likely free (because how are you gonna know an unreadable 
software is purposedly so or the dev’s just terrible?))/trustable, the 
least malware, the best)), support WebExtensions, including ones involving 
other languages (not only lisp, but also scheme, for instance (such as 
what would have been possible with guile)), or even native/compiled ones.

Talking about CL, that makes me also think that there’s maybe a great deal 
of loss by letting the web engine being written in C, while cl could 
nowadays, with proper typing, be just as fast, yet with the ability to be 
compiled at will.  Along with partial evaluation, that allows a great deal 
of optimization and performance gain with web, as long as you visit again 
a non-totally-changing page, and don’t execute a different script at each 
run (which, btw, completely *disable* any benefit of free software).  Maybe 
even up to the point where a web app could be just as fast as a native 
toolkit (modulo any non-clearly-forseen shortcoming of lisp).

Another issue with CL (and scheme too, and that’s a common obstacle found 
in TeXmacs as well), and combined with the fact it’s apparently still not 
packaged into debian, discourages me to try (to seriously switch to it) is 
that to customize and extend it, I would have to learn a whole new system 
than emacs’ one, which already has a great deal of complexity (I could say 
richness, because that complexity looks useful and justified to me), and 
even is improvable (as no more than recently here have been discussed the 
ability to add more metadata to packages, and in not-so-far past the one 
to natively compile elisp).  Again, guile would have been made for that, 
if only it successfully merged with emacs.

The final problem 

Re: GUI and redisplay work

[Alexandre Garreau]

Le vendredi 29 octobre 2021, 21:29:43 CEST Alexandre Garreau a écrit :
> Le vendredi 29 octobre 2021, 19:34:14 CEST Arthur Miller a écrit :
> > Have you checked out Nyxt browser?
> > 
> > https://nyxt.atlas.engineer/
> > 
> > CL + another widget derived from khtml ...
> > 
>> […]
> 
> […]
>
> The final problem

[hit ctrl by accident, sorry)

The final problem, common with that extension/non-emacsness as well, and 
present as well in TeXmacs, is that you can’t use that software (yet, as 
you said) to edit itself, which greatly diminuish the benefits of self-
extension and dynamism, because you loose a part of the benefit of self-
documentation combined with the integratedness of the development 
environment… to allow that among various programs, as it is already 
natural among various emacs’ extensions (which often provides a whole app, 
actually, as it would modernly be called), would require a whole inter-
program system of hyperlinking, along with sharing of many informations 
about the running program (which within emacs, or, what it comes from, a 
lisp machine, isn’t needed since all data is shared, you don’t even have 
to duplicate it)…

> > I am quite sure someone could develop a text editor based on "web
> > technologies" or just in pure CL that works in Nyxt.

…furthermore, a final manifestation of that is precisely that it would be 
very handy to have an editor inside a such program, however one bad and 
one great thing:

The bad one is that if what the vision of emacs provokes is the 
proliferation of editors, it becomes increasingly unpractical, as with 
each editor you would loose the benefit of the other ones: it would be hard 
to synchronise useful extensions and configurations among many editors, and 
a consequent work to normalize a common interface to make those compatible 
among them… Moreover, emacs is already in the picture since almost half a 
century, and many many many very useful extensions have been developed for 
it, even some you won’t find on any repository, on some old ftp server, 
that exists since longer than I’m born, even some you actually won’t find 
on the internet, but some people would happily share as soon as they’d 
become useful to you (such as specific to some projects), and that would be 
a great loss to abandon that, by switching to something incompatible.

Also something imho of first importance: anything can be an editor.  The 
very concept of editing is very broad, and is appliable to almost anything 
that’s not used passively for viewing.  Emacs is, outside of file editing, 
mainly used for irc and mails: anything involving text-editing can benefit 
from it (and that’s most of the usage of a computer nowadays, that’s why 
we can spend so much time inside emacs).  So I think ideally every 
software should be considered as an editor and share a part of 
customization/functionality with each other (even if only for text 
editing… but there’s also interactive macro registration, keyboard 
association and triggering, among other abstract things that would be 
useful everywhere).

And that would be mostly useful for the web, which became symmetric for 
most people only thanks to “social medias” that take control on their 
data.  But the first web browser was not a viewer, but a viewer/editor, and 
was hence de facto totally symetric in functionality, even from remote 
(thanks to HTTP PUT command, taken from ftp, which also is pretty symetric 
in usage), and didn’t need “web 2.0” for that.  “Web 2.0”, which, 
basically, means using software server-side to store and dispatch user’s 
data, which necessarily involve diverse, non-standard and likely 
incompatible software that could easily grow into SaaSS, or silo whose 
it’s not possible to automatically retrieve personal information…

That’s because most of web browser quickly stopped supporting editing to 
become passive tools of information (from editors to users), where you 
need more skills to express yourself than to read others.  Most of people 
can’t write html (or understand the concept of markup, hence more 
generally computer language), don’t know how it works, and if only 
Firefox’s inspector wouldn’t be so complicated and debugging-oriented it 
could make it way more intuitive to gradually discover (just like many 
users gradually discover programming with emacs).

If only a such browser existed it would be easy to make the web better 
understood, hence the javascript trap, and proprietary software along with 
SaaSS, and how they can be avoided.