emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merging the xwidget_mvp branch


From: Eli Zaretskii
Subject: Re: merging the xwidget_mvp branch
Date: Wed, 04 Nov 2015 17:29:06 +0200

> From: John Wiegley <address@hidden>
> Date: Tue, 03 Nov 2015 16:51:39 -0500
> Cc: address@hidden, Emacs developers <address@hidden>
> 
> > 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]