merging the xwidget_mvp branch

merging the xwidget_mvp branch

[joakim]

Stefan expressed interest in merging the xwidget_mvp branch before the
Emacs 25 release. If we could make that happen it would be great. If
not, so be it, but I would need to know well in advance, because of other
possible commitments. 

For those who don't know, the xwidget_mvp branch is allows embedding of
an webkit widget in an emacs window. (There is also an xwidget branch
that has more features but it is not ready for inclusion). 

The branch wouldn't actually be merged, rather a patch would be
extracted and applied to master, because the branch has irrelevant
history.

-- 
Joakim Verona

Re: merging the xwidget_mvp branch

[John Wiegley]

>>>>> joakim  <joakim@verona.se> writes:

> For those who don't know, the xwidget_mvp branch is allows embedding of an
> webkit widget in an emacs window. (There is also an xwidget branch that has
> more features but it is not ready for inclusion).

From among the developers here: How much desire is there for adding this
feature? What are the problems it solves, other than being cool?

How large a patch is this? Is there anyone committed to maintaining it after
inclusion?

John

Re: merging the xwidget_mvp branch

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> joakim  <joakim@verona.se> writes:
>
>> For those who don't know, the xwidget_mvp branch is allows embedding of an
>> webkit widget in an emacs window. (There is also an xwidget branch that has
>> more features but it is not ready for inclusion).
>
> From among the developers here: How much desire is there for adding this
> feature? What are the problems it solves, other than being cool?
>
> How large a patch is this? Is there anyone committed to maintaining it after
> inclusion?

The patch is large I suppose. It mostly affects the redisplay system.

I have maintained it in its own branch for a couple of years. I can
continue doing that in master, or in its own branch indefinitely. 

The feature is useful in roughly the same way that image support in
Emacs is useful. I find it useful during web-development and the like.

You can use it for browsing random sites, but thats not the primary
use-case.


>
> John

-- 
Joakim Verona

Re: merging the xwidget_mvp branch

[John Wiegley]

>>>>> joakim  <joakim@verona.se> writes:

> The patch is large I suppose. It mostly affects the redisplay system.

It's unfortunate that that is currently one of our most complex subsystems,
where we've had the greatest difficulty finding other contributors. I'd like
to know Eli's opinion on this especially, since he is actively maintaining
that code.

> I have maintained it in its own branch for a couple of years. I can continue
> doing that in master, or in its own branch indefinitely.

I'm personally inclined to not want this feature, unless there is a great deal
of desire for it from others; so I'll wait for them chime in.

I hate to say no given how much effort you've put into it, but there needs to
be enough value to offset the additional technical debt we'd be accruing.

John

Re: merging the xwidget_mvp branch

[Nicolas Petton]

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

John Wiegley <jwiegley@gmail.com> writes:

>> I have maintained it in its own branch for a couple of years. I can continue
>> doing that in master, or in its own branch indefinitely.
>
> I'm personally inclined to not want this feature, unless there is a great deal
> of desire for it from others; so I'll wait for them chime in.

I would have many use cases for it, and I think it would be an awesome
addition to Emacs 25.1.

Think about (and I know we have EWW, but still):

- HTML emails
- Online Documentation (MDN doesn't look good in eww)
- markdown preview in HTML
- org-mode export previews
- have a webkit window open doing web development that you could refresh
  at will and use hooks on it.
- ... many more

It would just be awesome IMHO.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: merging the xwidget_mvp branch

[Stefan Monnier]

>> The patch is large I suppose. It mostly affects the redisplay system.
> It's unfortunate that that is currently one of our most complex subsystems,
> where we've had the greatest difficulty finding other contributors.

That's an argument in favor of accepting this patch ;-)

>> I have maintained it in its own branch for a couple of years.  I can
>> continue doing that in master, or in its own branch indefinitely.
> I'm personally inclined to not want this feature, unless there is
> a great deal of desire for it from others; so I'll wait for them
> chime in.

I think it could open up very interesting new developments.

The embedded web-browser example is also a sexy proof-of-concept which
is likely to attract new blood (maybe not new users directly, but rather
new developers).

> I hate to say no given how much effort you've put into it, but there
> needs to be enough value to offset the additional technical debt we'd
> be accruing.

We've already been through several rounds of reviewing, so I'm sure he'd
be very disappointed if it doesn't get the code merged after all
those efforts.

And IIRC the technical debt seemed quite OK: the interaction between
xwidget's own code (the part that deals with the xwidget API) and
Emacs's own code is very similar to the interaction between Emacs and
the various image libraries.


        Stefan

Re: merging the xwidget_mvp branch

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Tue, 03 Nov 2015 16:51:39 -0500
> Cc: monnier@IRO.UMontreal.CA, Emacs developers <emacs-devel@gnu.org>
> 
> > The patch is large I suppose. It mostly affects the redisplay system.
> 
> It's unfortunate that that is currently one of our most complex subsystems,
> where we've had the greatest difficulty finding other contributors. I'd like
> to know Eli's opinion on this especially, since he is actively maintaining
> that code.

Actually, most of the changes are in the X-specific back-end of the
display engine, something I almost never dive into.  (I have no easy
access to an X-based Unix system where I can run and debug GUI
programs.)

The display-independent parts of the patch are relatively minor and
closely follow the footsteps of displaying images, so maintaining that
part shouldn't be a problem: just remember to do for xwidgets whatever
we do for images.

There is, of course, the point that this is X- and GTK3-specific, so
will only be available on some systems (and some people deliberately
avoid building with GTK even where it is available because it causes
crashes), but I guess this cannot be helped.

> > I have maintained it in its own branch for a couple of years. I can continue
> > doing that in master, or in its own branch indefinitely.
> 
> I'm personally inclined to not want this feature, unless there is a great deal
> of desire for it from others; so I'll wait for them chime in.

Well, at the time there was a lot of excitement, as I understand this
feature is considered rather "cool" nowadays.  See, for example

  http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00077.html

I'll let people who are familiar with the relevant use cases, first
and foremost Joakim himself, describe when and how this is useful.  My
personal impression from past discussions was that the question
whether to reject this was never on the table; it was always the
assumption that we want this feature, nd will merge it as soon as it's
ready.

> I hate to say no given how much effort you've put into it, but there needs to
> be enough value to offset the additional technical debt we'd be accruing.

In these discussions:

  http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02191.html
  http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00012.html

there were some suggestions for cleaning up the code.  I've took a
brief look at the branch as it is now, and most of the problems were
addressed, but I still see a lot of TODOs and FIXMEs, some temporary
comments, some commented-out code, at least one 'printf' in xdisp.c,
etc.  Also, many doc strings in xwidget.c "need work"™.  This needs to
be cleaned up, I think (but can be done after the merge to master, of
course).

Bottom line: I see no reasons not to merge this.

Re: merging the xwidget_mvp branch

[raman]

Another way to  get there -- integrating emacs and  a browser window --
might be the recently announced exwm ---   that way we would not be just
limited to Webkit --- but could run Mozilla, Chrome or generic Webkit 
-- 

Re: merging the xwidget_mvp branch

[Michael Abrahams]

On Wed, Nov 4, 2015 at 11:37 AM, raman <raman@google.com> wrote:
> Another way to  get there -- integrating emacs and  a browser window --
> might be the recently announced exwm ---   that way we would not be just
> limited to Webkit --- but could run Mozilla, Chrome or generic Webkit
> --
>

To chime in support - after hearing about the xwidget branch a few
weeks ago I gave it a shot, and found it was functioning pretty
nicely. I didn't get a chance to study the internals, but as Joakim
said, the overall experience of using inline widgets is very similar
to that of inline images.  (The main xwidget branch, although not
cleaned up for merging like xwidget_mvp, provides a variety of
different widgets to try out. Some widgets work better than others.)

One use case that comes to mind is a Company-style visual completion popup.

Re: merging the xwidget_mvp branch

[Nicolas Petton]

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

joakim@verona.se writes:

> Stefan expressed interest in merging the xwidget_mvp branch before the
> Emacs 25 release. If we could make that happen it would be great. If
> not, so be it, but I would need to know well in advance, because of other
> possible commitments. 
>
> For those who don't know, the xwidget_mvp branch is allows embedding of
> an webkit widget in an emacs window. (There is also an xwidget branch
> that has more features but it is not ready for inclusion). 
>
> The branch wouldn't actually be merged, rather a patch would be
> extracted and applied to master, because the branch has irrelevant
> history.

I just tried it, switching to the xwidget_mvp branch and compiling
Emacs, but I get the following errors after a `M-x xwidget-browse-url':

read-string: Symbol’s value as variable is void: xwidget-view-list
xwidget-kill-buffer-query-function: Symbol’s function definition is
void: get-buffer-xwidgets

I guess I'm doing something wrong, or not compiling it properly.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: merging the xwidget_mvp branch

[joakim]

Nicolas Petton <nicolas@petton.fr> writes:

> joakim@verona.se writes:
>
>> Stefan expressed interest in merging the xwidget_mvp branch before the
>> Emacs 25 release. If we could make that happen it would be great. If
>> not, so be it, but I would need to know well in advance, because of other
>> possible commitments. 
>>
>> For those who don't know, the xwidget_mvp branch is allows embedding of
>> an webkit widget in an emacs window. (There is also an xwidget branch
>> that has more features but it is not ready for inclusion). 
>>
>> The branch wouldn't actually be merged, rather a patch would be
>> extracted and applied to master, because the branch has irrelevant
>> history.
>
> I just tried it, switching to the xwidget_mvp branch and compiling
> Emacs, but I get the following errors after a `M-x xwidget-browse-url':
>
> read-string: Symbol’s value as variable is void: xwidget-view-list
> xwidget-kill-buffer-query-function: Symbol’s function definition is
> void: get-buffer-xwidgets
>
> I guess I'm doing something wrong, or not compiling it properly.

It sounds like you didnt compile with the right flags.

The correct flags are here: https://github.com/jave/xwidget-aux

The error you get is of course still a bug, since the lisp parts should
guard against the xwidget feature not being compiled in the C code.

>
> Nico
>

-- 
Joakim Verona

Re: merging the xwidget_mvp branch

[John Wiegley]

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

> We've already been through several rounds of reviewing, so I'm sure he'd be
> very disappointed if it doesn't get the code merged after all those efforts.

> And IIRC the technical debt seemed quite OK: the interaction between
> xwidget's own code (the part that deals with the xwidget API) and Emacs's
> own code is very similar to the interaction between Emacs and the various
> image libraries.

Since this review was done under your tenure, Stefan, I'll defer to your
judgment on this one. I generally have an aversion to large new features
without a driving use case, but you deserve at least one "midnight
appointment". :)

John

Re: merging the xwidget_mvp branch

[joakim]

Nicolas Petton <nicolas@petton.fr> writes:

> joakim@verona.se writes:
>
>> Stefan expressed interest in merging the xwidget_mvp branch before the
>> Emacs 25 release. If we could make that happen it would be great. If
>> not, so be it, but I would need to know well in advance, because of other
>> possible commitments. 
>>
>> For those who don't know, the xwidget_mvp branch is allows embedding of
>> an webkit widget in an emacs window. (There is also an xwidget branch
>> that has more features but it is not ready for inclusion). 
>>
>> The branch wouldn't actually be merged, rather a patch would be
>> extracted and applied to master, because the branch has irrelevant
>> history.
>
> I just tried it, switching to the xwidget_mvp branch and compiling
> Emacs, but I get the following errors after a `M-x xwidget-browse-url':
>
> read-string: Symbol’s value as variable is void: xwidget-view-list
> xwidget-kill-buffer-query-function: Symbol’s function definition is
> void: get-buffer-xwidgets
>
> I guess I'm doing something wrong, or not compiling it properly.

Did you succeed in compiling the branch?

I have some detailed build recipies for different distributions if you
need further assistance.

>
> Nico
>

-- 
Joakim Verona

Re: merging the xwidget_mvp branch

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> We've already been through several rounds of reviewing, so I'm sure he'd be
>> very disappointed if it doesn't get the code merged after all those efforts.
>
>> And IIRC the technical debt seemed quite OK: the interaction between
>> xwidget's own code (the part that deals with the xwidget API) and Emacs's
>> own code is very similar to the interaction between Emacs and the various
>> image libraries.
>
> Since this review was done under your tenure, Stefan, I'll defer to your
> judgment on this one. I generally have an aversion to large new features
> without a driving use case, but you deserve at least one "midnight
> appointment". :)

There is a driving use case, but I think I will explain it on the new
'tangents' list.

On emacs-devel I like to be terse, but it's not really my natural mode
of writing.

>
> John

-- 
Joakim Verona

Re: merging the xwidget_mvp branch

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Sun, 08 Nov 2015 17:34:46 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> There is a driving use case, but I think I will explain it on the new
> 'tangents' list.

I'm afraid your audience there will be extremely small.

Re: merging the xwidget_mvp branch

[Nicolas Petton]

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

joakim@verona.se writes:

> Did you succeed in compiling the branch?
>
> I have some detailed build recipies for different distributions if you
> need further assistance.

I haven't tried yet.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Join us on emacs-tangents! (was: merging the xwidget_mvp branch)

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I'm afraid your audience there will be extremely small.

For those who are willing, or have high-powered mail readers, please join us
on emacs-tangents! There are still so many fun topics to bikeshed, and now
they have a home.

John

Re: Join us on emacs-tangents!

[Rasmus]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I'm afraid your audience there will be extremely small.
>
> For those who are willing, or have high-powered mail readers, please join us
> on emacs-tangents! There are still so many fun topics to bikeshed, and now
> they have a home.

It's not on Gmane.  Could whoever is the admin for this list requests its
inclusion there?

Thanks,
Rasmus

-- 
It was you, Jezebel, it was you

Re: Join us on emacs-tangents!

[Dmitry Gutov]

On 11/09/2015 09:53 PM, John Wiegley wrote:

> For those who are willing, or have high-powered mail readers, please join us
> on emacs-tangents! There are still so many fun topics to bikeshed, and now
> they have a home.

It might help if that list was included at 
https://savannah.gnu.org/mail/?group=emacs.

Re: Join us on emacs-tangents!

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> It might help if that list was included at
> https://savannah.gnu.org/mail/?group=emacs.

It will be done.

John

Re: Join us on emacs-tangents!

[John Wiegley]

>>>>> Rasmus  <rasmus@gmx.us> writes:

> It's not on Gmane. Could whoever is the admin for this list requests its
> inclusion there?

Added to TODO, unless someone else gets to it first.

John

Re: Join us on emacs-tangents! (was: merging the xwidget_mvp branch)

[Aaron Ecay]

Hi John,

2015ko azaroak 9an, John Wiegley-ek idatzi zuen:
> 
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> I'm afraid your audience there will be extremely small.
> 
> For those who are willing, or have high-powered mail readers, please join us
> on emacs-tangents! There are still so many fun topics to bikeshed, and now
> they have a home.

I hope this is the right place to report an(other) emacs-tangents
related issue: the HTML archive link
<https://lists.gnu.org/archive/html/emacs-tangents> from the list’s
homepage <https://lists.gnu.org/mailman/listinfo/emacs-tangents> is
currently a dead link.

-- 
Aaron Ecay

Re: Join us on emacs-tangents!

[Jose E. Marchesi]

    > For those who are willing, or have high-powered mail readers, please join us
    > on emacs-tangents! There are still so many fun topics to bikeshed, and now
    > they have a home.
    
    I hope this is the right place to report an(other) emacs-tangents
    related issue: the HTML archive link
    <https://lists.gnu.org/archive/html/emacs-tangents> from the list?s
    homepage <https://lists.gnu.org/mailman/listinfo/emacs-tangents> is
    currently a dead link.

That is normal.  The archives webpage will be created as soon as there
is something to archive.

Re: merging the xwidget_mvp branch

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> We've already been through several rounds of reviewing, so I'm sure he'd be
>> very disappointed if it doesn't get the code merged after all those efforts.
>
>> And IIRC the technical debt seemed quite OK: the interaction between
>> xwidget's own code (the part that deals with the xwidget API) and Emacs's
>> own code is very similar to the interaction between Emacs and the various
>> image libraries.
>
> Since this review was done under your tenure, Stefan, I'll defer to your
> judgment on this one. I generally have an aversion to large new features
> without a driving use case, but you deserve at least one "midnight
> appointment". :)

Did we come to an argeement regarding merging this feature?
I think I read in another mail that you do agree now, but I'm having
trouble finding anything in the recent torrent of email.

If you now do agree, when should we attempt the merge? Is there a hard
freeze on friday? 

>
> John

-- 
Joakim Verona

Re: merging the xwidget_mvp branch

[John Wiegley]

>>>>> joakim  <joakim@verona.se> writes:

> Did we come to an argeement regarding merging this feature? I think I read
> in another mail that you do agree now, but I'm having trouble finding
> anything in the recent torrent of email.
> 
> If you now do agree, when should we attempt the merge? Is there a hard
> freeze on friday?

Your feature is accepted into 25.1, and you are exempted from the freeze on
Friday. Take what time you need to get it ready, but do not delay long. I want
to test that feature aggressively, since it extends our redisplay code.

John