Re: Platform independent graphical display for Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Cc: stefankangas@gmail.com, luangruo@yahoo.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 25 Dec 2021 13:23:01 +0200
> 
> On 25.12.2021 10:25, Eli Zaretskii wrote:
> 
> >> How it that different from a BeOS port, or a PGTK port, or etc? Where
> >> the general policy has been (I think?) that we accept such contributions
> >> as long as there interest from the author in maintaining it, and some
> >> probable interest the users.
> > 
> > The suggestion, as I understood it, was to drop all the other toolkits
> > and leave only this proposed one.  That was its main "selling point".
> > If we decide to have just one toolkit, then having that unmaintained
> > would be a serious problem for the future of Emacs.
> 
> Before we could do that, we'd need to have this port functional first, 
> and the problem with dropping all others would be in reaching a 
> consensus across emacs-devel (at least) that the new one is better than 
> the others. And it maintained/maintainable, of course.
> 
> That should pretty much guarantee that it will be maintained. But the 
> odds of reaching that point are pretty slim, of course, given that we 
> don't lack in different viewpoints here.

So you'd suggest to the OP to develop the software in the hope that
all of the above will happen?  And if it doesn't, just agree for the
results to be abandoned?  The OP would have to agree to that.

And I fail to see how that solves the long-term maintenance problem,
once we do accept the code.  This happened in the past, more than
once.

> > I have nothing in principle against improving the no-toolkit
> > configuration.  I do think that _adding_ another no-toolkit
> > configuration would be undesirable, because it would make the
> > proverbial "spaghetti of Emacs code" even harder to understand and
> > maintain.  (I don't think such a suggestion is on the table, but since
> > you seem to say I misunderstood the suggestion, perhaps I've
> > misunderstood that as well.)
> 
> I would at least hope that switching to another no-toolkit configuration 
> (and removing the current one soon after) is on the table. After getting 
> enough consensus, naturally.

What would be the motivation for such a switch, as opposed to just
incrementally improving the existing no-toolkit build?  Come to think
of that, what exactly is the difference between these two
alternatives?

> It might become feasible to remove a number of them, though.

So far we've failed to do that.

> > I'm not saying it's impossible, I'm just saying we don't have such
> > talent on board.  Maybe Blender does, which would be understandable,
> > given the focus of the project.  Our experience is that GUI experts in
> > our ranks are very rare and far in-between, and there are no reasons
> > to believe this will change.
> 
> Having a port like that developed could get us +1 such expect.

Yes, miracles and improbable events do happen sometimes.  But planning
our future on that hope is unwise at best.  If and when that happens,
then we should probably grab the opportunity, but we are not there
now, I think.