Motif support

Motif support

[Po Lu]

`--with-x-toolkit=motif' is documented in INSTALL, but configure
complained that it was not an option.  At first I thought this was
related to the PGTK merge, but apparently someone removed the single
line in configure.ac that enables the Motif build some time last year.

After adding it back, the Motif build works perfectly on both master and
emacs-28.  So I see no harm in reenabling it (possibly in the release
branch as well.)

If people are concerned about the Motif support being a maintenance
burden, then no worries: you will be free to break the Motif build
whenever you want, and I will notice and fix the lossage.

Re: Motif support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sun, 19 Dec 2021 10:04:58 +0800
> 
> `--with-x-toolkit=motif' is documented in INSTALL, but configure
> complained that it was not an option.  At first I thought this was
> related to the PGTK merge, but apparently someone removed the single
> line in configure.ac that enables the Motif build some time last year.
> 
> After adding it back, the Motif build works perfectly on both master and
> emacs-28.  So I see no harm in reenabling it (possibly in the release
> branch as well.)
> 
> If people are concerned about the Motif support being a maintenance
> burden, then no worries: you will be free to break the Motif build
> whenever you want, and I will notice and fix the lossage.

The Motif support was deliberately removed after a long discussion,
which started here:

  https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00768.html

The fact that it wasn't removed from INSTALL is a mistake that should
be fixed.

I don't think we want to reinstate Motif support.

Re: Motif support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think we want to reinstate Motif support.

The code still works perfectly: reinstating that line allowed me to
configure and build a functioning Motif Emacs, even with new features
such as XInput2.

The Motif build also has some technical advantages over others these
days.  For example, Motif at present has the only working toolkit
scrollbars on X where the thumb size is adjusted when it is dragged.

I spent a while trying to fix bug#51343 a few weeks ago and didn't get
anywhere, and implementing toolkit scrollbars correctly on GTK isn't
possible anyway, as the GTK developers don't want programs to control
the thumb size.

Icon window menus on mwm also work correctly only with Motif Emacs.

Also, I think that discussion boiled down to "let's remove it and see if
anyone notices"... well, I noticed :)

It won't hurt to keep that code, especially since nobody has managed to
break in close to a year since it was disabled, even with large features
such as XInput2 and the xwidgets update.

Thanks.

Re: Motif support

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> It won't hurt to keep that code, especially since nobody has managed
> to break in close to a year since it was disabled, even with large
> features such as XInput2 and the xwidgets update.

I find most of the discussion alarming on other fronts as well.  The
PGTK branch is hardly ready to become the default, much less replace the
existing X and GTK 3 build.  People are also talking about removing
support for Xft and lwlib!

There are quite a few features that the PGTK build cannot, by design,
support.  Aside from the ones I listed earlier, there's also:

  - The inability to support session management.  (To accomplish that
    with only GTK, you have to use GtkApplication, whose architecture is
    simply incompatible with Emacs.)
  - The inability to understand X resources.
  - The inability to support popular existing packages, such as EXWM.
  - The inability to have `yank-media' work.  (Though this can probably
    be fixed.)

There are also a few other limitations shared by both the cairo and PGTK
builds:

  - The inability to function correctly without the X Render Extension.
  - The inability to work at all with a pseudo color visual, or a
    private colormap, because Cairo was not designed to work this way.

The last problem means Xft is the only way to get FreeType fonts on a
server using a pseudo color visual.  This feature is often used to get
better performance on X running over the network, so removing it would
be a very bad idea.  It's okay to trade a few crashes when loading color
fonts for this functionality, as long as it isn't the default build
configuration.

From personal experience, there are a few more, but I can't list them
off-hand right now.

In short: please don't rush to remove either the existing GTK build, Xft
support, or the lwlib build, or the non-Cairo X build.  They are still
useful, and more importantly, there is no reason at all to rush things.

Re: Motif support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 19 Dec 2021 15:14:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think we want to reinstate Motif support.
> 
> The code still works perfectly: reinstating that line allowed me to
> configure and build a functioning Motif Emacs, even with new features
> such as XInput2.

We didn't remove Motif because it was broken, we removed it because
the consensus was it was relatively unused and unsupported by distros.

> It won't hurt to keep that code, especially since nobody has managed to
> break in close to a year since it was disabled, even with large features
> such as XInput2 and the xwidgets update.

I don't like to go back on our decisions except if they turn out to be
grave mistakes.  So, unless there are very good reasons to reinstate
Motif support, I'd like to leave it unsupported.

Let's see what others think about this.

Re: Motif support

[Bozhidar Batsov]

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

Emacs is already huge and I think Motif is pretty much dead at this point (I think I haven't seen any Motif-based apps in 10+ years), which makes Motif support in Emacs dead weight IMO. A case can be made for keeping everything indefinitely, but I think the practical approach is to focus on what matters (is used) the most and shed the rest for the sake of simplicity and easier long-term maintenance.

Having less code is almost always better, so I don't agree with the assessment that keeping some legacy code around won't hurt. Less is more. 

On Sun, Dec 19, 2021, at 9:50 AM, Eli Zaretskii wrote:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: emacs-devel@gnu.org
> > Date: Sun, 19 Dec 2021 15:14:30 +0800
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > I don't think we want to reinstate Motif support.
> > 
> > The code still works perfectly: reinstating that line allowed me to
> > configure and build a functioning Motif Emacs, even with new features
> > such as XInput2.
> 
> We didn't remove Motif because it was broken, we removed it because
> the consensus was it was relatively unused and unsupported by distros.
> 
> > It won't hurt to keep that code, especially since nobody has managed to
> > break in close to a year since it was disabled, even with large features
> > such as XInput2 and the xwidgets update.
> 
> I don't like to go back on our decisions except if they turn out to be
> grave mistakes.  So, unless there are very good reasons to reinstate
> Motif support, I'd like to leave it unsupported.
> 
> Let's see what others think about this.
> 
> 

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

Re: Motif support

[Dmitry Gutov]

On 19.12.2021 10:14, Po Lu wrote:
> The Motif build also has some technical advantages over others these
> days.  For example, Motif at present has the only working toolkit
> scrollbars on X where the thumb size is adjusted when it is dragged.

What about the Lucid build?

Last I checked, they had been very similar.

Re: Motif support

[Po Lu]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Emacs is already huge and I think Motif is pretty much dead at this
> point (I think I haven't seen any Motif-based apps in 10+ years),
> which makes Motif support in Emacs dead weight IMO.

~2 years ago I was involved in the development of a Motif based ORM
program, so I have to disagree here.

> Having less code is almost always better, so I don't agree with the
> assessment that keeping some legacy code around won't hurt. Less is
> more.

Not if nobody else but me has to worry about it.

Re: Motif support

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 19.12.2021 10:14, Po Lu wrote:
>> The Motif build also has some technical advantages over others these
>> days.  For example, Motif at present has the only working toolkit
>> scrollbars on X where the thumb size is adjusted when it is dragged.
>
> What about the Lucid build?

The Lucid build doesn't have it's own toolkit scroll bars, it uses
whatever is available.

Xaw3d scroll bars (the only toolkit scrollbars that are available these
days) are broken: see bug#51343.

Re: Motif support

[martin rudalics]

 >> I don't think we want to reinstate Motif support.
 >
 > The code still works perfectly: reinstating that line allowed me to
 > configure and build a functioning Motif Emacs, even with new features
 > such as XInput2.

I am building with Motif regularly ever since support for it was dropped
and still think it comes up as the best graphical build on GNU/Linux.

 > The Motif build also has some technical advantages over others these
 > days.  For example, Motif at present has the only working toolkit
 > scrollbars on X where the thumb size is adjusted when it is dragged.
 >
 > I spent a while trying to fix bug#51343 a few weeks ago and didn't get
 > anywhere, and implementing toolkit scrollbars correctly on GTK isn't
 > possible anyway, as the GTK developers don't want programs to control
 > the thumb size.

As someone who spent considerable time to control the appearance of
scroll bars and tooltips via gtk.css and eventually gave up, I can only
concur.  We have, for example, bug reports that the GTK slider width
cannot be controlled by Emacs.  Unfortunately, GTK (and GNOME) settings
are sometimes considered as God-given here, something an earthly Emacser
is not supposed to contest.

 > Icon window menus on mwm also work correctly only with Motif Emacs.
 >
 > Also, I think that discussion boiled down to "let's remove it and see if
 > anyone notices"... well, I noticed :)
 >
 > It won't hurt to keep that code, especially since nobody has managed to
 > break in close to a year since it was disabled, even with large features
 > such as XInput2 and the xwidgets update.

It's not too late (so far nobody bothered to change the Wikipedia entry

   GNU Emacs runs both on text terminals and in graphical user interface
   (GUI) environments. On Unix-like operating systems, GNU Emacs can use
   the X Window System to produce its GUI either directly using Athena
   widgets or by using a "widget toolkit" such as Motif, LessTif, or
   GTK+.

).

martin

Re: Motif support

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't like to go back on our decisions except if they turn out to be
> grave mistakes.  So, unless there are very good reasons to reinstate
> Motif support, I'd like to leave it unsupported.
>
> Let's see what others think about this.

Well, we ended the thread with:

> > We could just remove support for '--with-x-toolkit=motif' from
> > configure.ac for a while, and see if anyone complains. If not, we rip
> > out the actual Motif code.
> 
> Sounds like a plan.

And now we've had (at least) a couple complaints, so perhaps we should
reconsider.  It did take almost a full year, so the complaints aren't...
vigorous, though.

(I don't have an opinion myself, one way or another.)

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

Re: Motif support

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

>> Having less code is almost always better, so I don't agree with the
>> assessment that keeping some legacy code around won't hurt. Less is
>> more.
>
> Not if nobody else but me has to worry about it.

Anyone who reads or hacks the sources has to worry about it.

Re: Motif support

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> Having less code is almost always better, so I don't agree with the
>>> assessment that keeping some legacy code around won't hurt. Less is
>>> more.
>>
>> Not if nobody else but me has to worry about it.
>
> Anyone who reads or hacks the sources has to worry about it.

You don't have to.  The Motif code is well contained behind Motif
conditionals, and it is also conceptually simple.

And as of this moment, you have no obligation to keep the Motif build
working after hacking: I volunteer myself to keep it working.

Re: Motif support

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>>> Having less code is almost always better, so I don't agree with the
>>>> assessment that keeping some legacy code around won't hurt. Less is
>>>> more.
>>>
>>> Not if nobody else but me has to worry about it.
>>
>> Anyone who reads or hacks the sources has to worry about it.
>
> You don't have to.  The Motif code is well contained behind Motif
> conditionals,

The hacker must track those conditionals while reading the source.

> and it is also conceptually simple.
>
> And as of this moment, you have no obligation to keep the Motif build
> working after hacking: I volunteer myself to keep it working.

Somehow we must ensure that the existing and future hackers should know
about this ;-)

What I've read from you about motif on this thread convinced me to give
it a try, but let's face it, the display code is rotten spaghetti (much
of Emacs' C sources are rotten spaghetti, but the display part is far
worse) and removing some of the umpteen backends would be a start to
improve things.

If Motif is so good, maybe remove Lucid? (which is what I use, BTW)

Re: Motif support

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> The hacker must track those conditionals while reading the source.

Which takes very little effort.

> Somehow we must ensure that the existing and future hackers should know
> about this ;-)

If you are right and nobody cares about Motif, then they won't bother to
keep the Motif port building either.

> What I've read from you about motif on this thread convinced me to give
> it a try, but let's face it, the display code is rotten spaghetti (much
> of Emacs' C sources are rotten spaghetti, but the display part is far
> worse) and removing some of the umpteen backends would be a start to
> improve things.

Removing tiny pieces of code, most of which are tucked away in lwlib/,
will not improve the "rotten spaghetti" that is the display code (which
is already a statement I disagree with.)

> If Motif is so good, maybe remove Lucid?

"Lucid" is just the widget library used to interface with (partially)
both Motif and the variants of Athena widgets.

Both the Motif build and the "Lucid" build use the Lucid library.  Even
the GTK build, PGTK port, NS port and W32 port use parts of the Lucid
library for handling menus.  The only GUI port that is completely free
of lwlib is the Haiku port.

Re: Motif support

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> The hacker must track those conditionals while reading the source.
>
> Which takes very little effort.
>
>> Somehow we must ensure that the existing and future hackers should know
>> about this ;-)
>
> If you are right and nobody cares about Motif, then they won't bother to
> keep the Motif port building either.
>
>> What I've read from you about motif on this thread convinced me to give
>> it a try, but let's face it, the display code is rotten spaghetti (much
>> of Emacs' C sources are rotten spaghetti, but the display part is far
>> worse) and removing some of the umpteen backends would be a start to
>> improve things.
>
> Removing tiny pieces of code, most of which are tucked away in lwlib/,
> will not improve the "rotten spaghetti" that is the display code (which
> is already a statement I disagree with.)
>
>> If Motif is so good, maybe remove Lucid?
>
> "Lucid" is just the widget library used to interface with (partially)
> both Motif and the variants of Athena widgets.
>
> Both the Motif build and the "Lucid" build use the Lucid library.  Even
> the GTK build, PGTK port, NS port and W32 port use parts of the Lucid
> library for handling menus.  The only GUI port that is completely free
> of lwlib is the Haiku port.

In short: you (and many other people who have not worked with the X
port) are grossly overstating the amount of work needed to keep the
Motif build working, and how difficult it is to comprehend.

New hackers will likely have much more trouble understanding the GTK
code than the code for a well-behaved X toolkit such as Motif.  IME,
they will also have more difficulties understanding X in general, which
is quite different from other contemporary window systems.

For example, do you really understand what we do in `XTflash' with the
various versions of GTK and Cairo?

I apologize in advance if this reply appears to have an accausatory
tone: if it does, I didn't intend for it to be that way, but I couldn't
find another wording that would get the point accross.

Thanks.

Re: Motif support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 19 Dec 2021 18:58:01 +0800
> 
> Both the Motif build and the "Lucid" build use the Lucid library.  Even
> the GTK build, PGTK port, NS port and W32 port use parts of the Lucid
> library for handling menus.  The only GUI port that is completely free
> of lwlib is the Haiku port.

I think you are mistaken: the MS-Windows build doesn't use lwlib
code.  Its menu code is entirely native w32 code, see w32menu.c.

Re: Motif support

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

>> "Lucid" is just the widget library used to interface with (partially)
>> both Motif and the variants of Athena widgets.
>>
>> Both the Motif build and the "Lucid" build use the Lucid library.  Even
>> the GTK build, PGTK port, NS port and W32 port use parts of the Lucid
>> library for handling menus.  The only GUI port that is completely free
>> of lwlib is the Haiku port.
>
> In short: you (and many other people who have not worked with the X
> port)

I looked at the sources and quickly decided that I would only work with
that under duress.

> are grossly overstating the amount of work needed to keep the
> Motif build working, and how difficult it is to comprehend.

I'm afraid that on this topic there are a lot of self-fulling prophecies
and selection biases. Whenever somebody mentions the complexity of the
source, some seasoned hacker pops up saying that the assessment is
wrong, without realizing that he is precisely the worst placed person to
dispute the assessment.

> New hackers will likely have much more trouble understanding the GTK
> code than the code for a well-behaved X toolkit such as Motif.

New hackers probably are more comfortable with GTK than with legacy X
libraries.

> IME, they will also have more difficulties understanding X in general,
> which is quite different from other contemporary window systems.

Yes.

> For example, do you really understand what we do in `XTflash' with the
> various versions of GTK and Cairo?

I prefer to keep those horrible thoughts out of my mind ;-)

> I apologize in advance if this reply appears to have an accausatory
> tone: if it does, I didn't intend for it to be that way, but I couldn't
> find another wording that would get the point accross.

No worries, I understand your position. On the past I supported Eli he
objected to removing the DOS port, so I say the same on your case: if
that is the price for keeping you hacking on Emacs, it is a good
trade-off. But let's not pretend that all that extra complexity has no
impact on others.

Re: Motif support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Both the Motif build and the "Lucid" build use the Lucid library.  Even
>> the GTK build, PGTK port, NS port and W32 port use parts of the Lucid
                                                      ^^^^^
>> library for handling menus.  The only GUI port that is completely free
>> of lwlib is the Haiku port.

> I think you are mistaken: the MS-Windows build doesn't use lwlib
> code.  Its menu code is entirely native w32 code, see w32menu.c.

It uses some of the lwlib code (mostly related to the data structure
`struct widget_value'), which is what I meant by "parts" here.  The
Haiku port doesn't, and the parts of menu.c that relate to the
construction of those data structures isn't built there either.

Thanks.

Re: Motif support

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I looked at the sources and quickly decided that I would only work with
> that under duress.

That applies to any large code one is not used to working with, be it
based on GTK or Motif.

> New hackers probably are more comfortable with GTK than with legacy X
> libraries.

Please take a look at `XTflash' and decide whether or not you are
comfortable with the GTK code: it is representative of the many hoops we
go through in order to work with GTK.  Ditto for the pgtk port, which I
found to somehow not be much better in this aspect.

> No worries, I understand your position. On the past I supported Eli he
> objected to removing the DOS port, so I say the same on your case: if
> that is the price for keeping you hacking on Emacs, it is a good
> trade-off. But let's not pretend that all that extra complexity has no
> impact on others.

I'm not pretending that any "extra complexity" has no impact on others,
I'm saying that the Motif support adds so negligible an amount of
complexity that it's not even possible to quantify whether or not it's
extraneous.

Re: Motif support

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> I looked at the sources and quickly decided that I would only work with
>> that under duress.
>
> That applies to any large code one is not used to working with, be it
> based on GTK or Motif.

I disagree. I worked on some code bases much larger than Emacs' C part,
with an application domain much more technical and specialized, and
achieved productivity on non-trivial tasks after a few hours of study.
Those are projects that put a lot of thought on code architecture, both
macro and micro, with no tolerance for long-lived hacks or "somehow this
seems to work" changes.

Emacs does not fit that description at all. And please do not take this
as a criticism towards the contributors, I have much respect for their
work seeing how stable Emacs is.

>> New hackers probably are more comfortable with GTK than with legacy X
>> libraries.
>
> Please take a look at `XTflash' and decide whether or not you are
> comfortable with the GTK code: it is representative of the many hoops we
> go through in order to work with GTK.  Ditto for the pgtk port, which I
> found to somehow not be much better in this aspect.

Well, we always can pick a counter-example where GTK simplifies the job,
can't we? What XTflash does is somewhat weird, but for other more
mundane tasks GTK can be better. Or so I'll guess, since I don't know
that library and I've heard lots of times that it is a bit difficult to
work with in comparison with other contemporary toolkits.

Re: Motif support

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Po Lu <luangruo@yahoo.com> writes:

> I disagree. I worked on some code bases much larger than Emacs' C part,
> with an application domain much more technical and specialized, and
> achieved productivity on non-trivial tasks after a few hours of study.
> Those are projects that put a lot of thought on code architecture, both
> macro and micro, with no tolerance for long-lived hacks or "somehow this
> seems to work" changes.

If you spend a week of study on X-Windows and Xt, along with spending
some time to read the comments in keyboard.c, you will be able to
understand the code in the X port fairly well.  I've personally seen
both the "no tolerance for long-lived-hacks" and the "you don't have to
understand it to work on it" attitudes destroy decades-old pieces of
software, so I don't recommend following it unconditionally.

X is a very complicated system, so people interested in working on its
support in Emacs are recommended to spend at least a week of study on it
beforehand, just as they must also study C.

Either way, the discussion has turned to a tangent.  The original point
was that the complexity added by Motif is too negligble to be considered
extra.

> Well, we always can pick a counter-example where GTK simplifies the job,
> can't we? What XTflash does is somewhat weird, but for other more
> mundane tasks GTK can be better. Or so I'll guess, since I don't know
> that library and I've heard lots of times that it is a bit difficult to
> work with in comparison with other contemporary toolkits.

That sort of counter-example doesn't exist in the code in both kinds of
GTK builds, IME.  Both types of GTK build consistently need large
amounts of hacks to work correctly, which are usually one or to five
lines of straightforward code in an Xt or a no-toolkit build.

For example, you can look at the function `xg_update_scrollbar_pos', and
compare it to the code `XTset_vertical_scroll_bar' runs on an Xt or
no-toolkit scroll bars build:

This is run on Xt:

    XtConfigureWidget (SCROLL_BAR_X_WIDGET (FRAME_X_DISPLAY (f), bar),
                       left, top, width, max (height, 1), 0);

And this is run on when there are no toolkit scroll bars:

      /* Move/size the scroll bar window.  */
      if (mask)
	{
	  XWindowChanges wc;

	  wc.x = left;
	  wc.y = top;
	  wc.width = width;
	  wc.height = height;
	  XConfigureWindow (FRAME_X_DISPLAY (f), bar->x_window,
			    mask, &wc);
	}

Both of which are more straightforward to understand and work with than
`xg_update_scrollbar_pos', where even the tiniest detail can cause the
function to stop working correctly.

Re: Motif support

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 19 Dec 2021 13:05:23 +0100
> 
> I worked on some code bases much larger than Emacs' C part,
> with an application domain much more technical and specialized, and
> achieved productivity on non-trivial tasks after a few hours of study.
> Those are projects that put a lot of thought on code architecture, both
> macro and micro, with no tolerance for long-lived hacks or "somehow this
> seems to work" changes.

Either those projects were redesigned and rewritten every few years,
or they stopped getting significant changes after several years.

Emacs has its major part rewritten only very rarely (the display
engine in Emacs 21 and the handling of non-ASCII in Emacs 20 and then
again in Emacs 23 are basically the only examples that come to mind).
Emacs is also a highly interactive program with many extensions "in
the wild", so it must stay compatible throughout the changes.  And
finally, I very much doubt that any other project supports so many
different UI frameworks.

These differences explain why you don't frequently see the complexity
we have in Emacs.

And please don't take this as a defense of what we have, it's just a
statement of some facts we should keep in mind.

Re: Motif support

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I worked on some code bases much larger than Emacs' C part,
>> with an application domain much more technical and specialized, and
>> achieved productivity on non-trivial tasks after a few hours of study.
>> Those are projects that put a lot of thought on code architecture, both
>> macro and micro, with no tolerance for long-lived hacks or "somehow this
>> seems to work" changes.
>
> Either those projects were redesigned and rewritten every few years,

Yes.

Well, sort of. Not really rewritten as in "let's scrap everything an
begin anew", but there were no misgivings about rethinking, changing and
scraping things when they seemed to start going out of hands.

> or they stopped getting significant changes after several years.
>
> Emacs has its major part rewritten only very rarely (the display
> engine in Emacs 21 and the handling of non-ASCII in Emacs 20 and then
> again in Emacs 23 are basically the only examples that come to mind).
> Emacs is also a highly interactive program with many extensions "in
> the wild", so it must stay compatible throughout the changes.  And
> finally, I very much doubt that any other project supports so many
> different UI frameworks.

AFAIK a lot of the complexity on the display engine comes from
shoehorning a GUI on top of a TUI design.

> These differences explain why you don't frequently see the complexity
> we have in Emacs.
>
> And please don't take this as a defense of what we have, it's just a
> statement of some facts we should keep in mind.

Agreed. If the technical exigence on Emacs were as high as in those
other projects, probably Emacs would be dead by now for lack of
contributors. Different environments, different applications, different
state of mind of contributors (vocational payjob vs scratch-an-itch on
free time), etc.

That said, the combination of micro-changes (features plus bug fixes)
combined with the principle of "if it works, don't fix it" is too easily
perceptible on Emacs :-)

Re: Motif support

[dick]

ÓF> AFAIK a lot of the complexity on the display engine comes from
ÓF> shoehorning a GUI on top of a TUI design.

Yes, although to someone's credit, GUI was retrofitted on TUI as well as
one could expect.

ÓF> That said, the combination of micro-changes

The micro-changes which minimize impact while maximizing obfuscation
perpetuate a vicious cycle of increasing incomprehensibility and
recalcitrance towards taking one step back for two steps forward.

Re: Motif support

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 19 Dec 2021 15:15:03 +0100
> 
> > Emacs has its major part rewritten only very rarely (the display
> > engine in Emacs 21 and the handling of non-ASCII in Emacs 20 and then
> > again in Emacs 23 are basically the only examples that come to mind).
> > Emacs is also a highly interactive program with many extensions "in
> > the wild", so it must stay compatible throughout the changes.  And
> > finally, I very much doubt that any other project supports so many
> > different UI frameworks.
> 
> AFAIK a lot of the complexity on the display engine comes from
> shoehorning a GUI on top of a TUI design.

That's a myth that doesn't endure meeting with the reality.  Just read
the code.  If anything, the Emacs 21 display engine is the other way
around: TTY display built on top of the GUI display.

> That said, the combination of micro-changes (features plus bug fixes)
> combined with the principle of "if it works, don't fix it" is too easily
> perceptible on Emacs :-)

There's no other policy that would keep Emacs so stable for so long.

Re: Motif support

[Madhu]

* martin rudalics <13ceca98-ccb5-8ed7-6d1f-4921e9b2554a@gmx.at> :
Wrote on Sun, 19 Dec 2021 11:14:59 +0100:

>>> I don't think we want to reinstate Motif support.
>>
>> The code still works perfectly: reinstating that line allowed me to
>> configure and build a functioning Motif Emacs, even with new features
>> such as XInput2.
>
> I am building with Motif regularly ever since support for it was dropped
> and still think it comes up as the best graphical build on GNU/Linux.

Same here.  And I hear there is an opensource revival of CDE, which
should be encouraged.

It always helps to test "standard emacs" behaviour on another toolkit
rather than letting the behaviour slide

>> The Motif build also has some technical advantages over others these
>> days.  For example, Motif at present has the only working toolkit
>> scrollbars on X where the thumb size is adjusted when it is dragged.
>>
>> I spent a while trying to fix bug#51343 a few weeks ago and didn't get
>> anywhere, and implementing toolkit scrollbars correctly on GTK isn't
>> possible anyway, as the GTK developers don't want programs to control
>> the thumb size.
>
> As someone who spent considerable time to control the appearance of
> scroll bars and tooltips via gtk.css and eventually gave up, I can only
> concur.  We have, for example, bug reports that the GTK slider width
> cannot be controlled by Emacs.  Unfortunately, GTK (and GNOME) settings
> are sometimes considered as God-given here, something an earthly Emacser
> is not supposed to contest.
>
>> Icon window menus on mwm also work correctly only with Motif Emacs.
>>
>> Also, I think that discussion boiled down to "let's remove it and see if
>> anyone notices"... well, I noticed :)
>>
>> It won't hurt to keep that code, especially since nobody has managed to
>> break in close to a year since it was disabled, even with large features
>> such as XInput2 and the xwidgets update.
>
> It's not too late (so far nobody bothered to change the Wikipedia entry
>
>   GNU Emacs runs both on text terminals and in graphical user interface
>   (GUI) environments. On Unix-like operating systems, GNU Emacs can use
>   the X Window System to produce its GUI either directly using Athena
>   widgets or by using a "widget toolkit" such as Motif, LessTif, or
>   GTK+.

Re: Motif support

[Po Lu]

Madhu <enometh@meer.net> writes:

> Same here.  And I hear there is an opensource revival of CDE, which
> should be encouraged.
>
> It always helps to test "standard emacs" behaviour on another toolkit
> rather than letting the behaviour slide

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > > We could just remove support for '--with-x-toolkit=motif' from
> > > configure.ac for a while, and see if anyone complains. If not, we rip
> > > out the actual Motif code.
> > 
> > Sounds like a plan.
> 
> And now we've had (at least) a couple complaints, so perhaps we should
> reconsider.  It did take almost a full year, so the complaints
> aren't...  vigorous, though.

For the reasons mentioned above, and also because Martin and I think
someone else was also using the Motif build even though support was
dropped, I think we should back out of this change.  It's not too late,
and I don't think the discussion ever ended conclusively either.

Re: Motif support

[Po Lu]

Madhu <enometh@meer.net> writes:

> Same here.  And I hear there is an opensource revival of CDE, which
> should be encouraged.
>
> It always helps to test "standard emacs" behaviour on another toolkit
> rather than letting the behaviour slide

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > > We could just remove support for '--with-x-toolkit=motif' from
> > > configure.ac for a while, and see if anyone complains. If not, we rip
> > > out the actual Motif code.
> > 
> > Sounds like a plan.
> 
> And now we've had (at least) a couple complaints, so perhaps we should
> reconsider.  It did take almost a full year, so the complaints
> aren't...  vigorous, though.

For the reasons mentioned above, and also because Martin and I think
someone else was also using the Motif build even though support was
dropped, I think we should back out of this change and restore Motif
support.  It's not too late, and I don't think the discussion ever ended
conclusively either.

Re: Motif support

[Aiko Kyle]

On Sun, Dec 19, 2021 at 8:11 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > > Emacs has its major part rewritten only very rarely (the display
> > > engine in Emacs 21 and the handling of non-ASCII in Emacs 20 and then
> > > again in Emacs 23 are basically the only examples that come to mind).
> > > Emacs is also a highly interactive program with many extensions "in
> > > the wild", so it must stay compatible throughout the changes.  And
> > > finally, I very much doubt that any other project supports so many
> > > different UI frameworks.
> >
> > AFAIK a lot of the complexity on the display engine comes from
> > shoehorning a GUI on top of a TUI design.
>
> That's a myth that doesn't endure meeting with the reality.  Just read
> the code.  If anything, the Emacs 21 display engine is the other way
> around: TTY display built on top of the GUI display.

It seems we just passed the 20th anniversary of the release of Emacs
21! Since then, I think a lot of assumptions about hardware have
changed or are changing: GPUs are now ubiquitous, hidpi is here to
stay, laptops have precision multitouch trackpads and touch displays,
the end of Dennard scaling and subsequent move towards parallel
processing for performance gains. I often wonder what emacs "core"
would look like if it were rewritten from scratch today with an
emphasis on performance. I imagine Firefox's transition of gecko to
rust components from servo over the last several years is probably a
good indication of what such a rewrite looks like for a complex
codebase.

Re: Motif support

[Po Lu]

Aiko Kyle <aikokyle@gmail.com> writes:

> It seems we just passed the 20th anniversary of the release of Emacs
> 21! Since then, I think a lot of assumptions about hardware have
> changed or are changing: GPUs are now ubiquitous, hidpi is here to
> stay, laptops have precision multitouch trackpads and touch displays,

None of which will require a rewrite to support.  In fact, Emacs 29
already supports precision mice, high definition displays, multitouch
trackpads, and digitizers.  On X, both the non-Cairo and Cairo builds
make use of hardware acceleration whenever available through both the
Glamor component of the X server and the X render extension.

NS also makes use of hardware acceleration, and IIUC GDI (which is used
in MS-Windows) is also hardware accelerated.

> I imagine Firefox's transition of gecko to rust components from servo
> over the last several years is probably a good indication of what such
> a rewrite looks like for a complex codebase.

Gecko is still mostly C++, and hasn't gone through much of a rewrite
either.  (But please take the discussion about Gecko to emacs-tangents.)

Re: Motif support

[Akira Kyle]

On Sun, Dec 19, 2021 at 8:13 PM Po Lu <luangruo@yahoo.com> wrote:
>
> Aiko Kyle <aikokyle@gmail.com> writes:
>
> > It seems we just passed the 20th anniversary of the release of Emacs
> > 21! Since then, I think a lot of assumptions about hardware have
> > changed or are changing: GPUs are now ubiquitous, hidpi is here to
> > stay, laptops have precision multitouch trackpads and touch displays,
>
> None of which will require a rewrite to support.  In fact, Emacs 29
> already supports precision mice, high definition displays, multitouch
> trackpads, and digitizers.

I know emacs supports these, my point was more about things that
didn't exist when the current architecture of the display engine was
conceived and thus assumptions that were made about hardware for the
sake of performance do not necessarily now hold with newer hardware
(for example subpixel font rendering on hidpi). I'm by no means an
expert in how the display code has evolved since then so I can't say
whether a "rewrite from scratch" of that code today would look the
same as it does now. My point about firefox is that that code looks
vastly different today than it did 20 years ago (eg with webrender and
potential other components coming from servo) because the whole
architecture had to be rethought in order to take full advantage of
hardware acceleration (and they did a lot of experimenting to figure
out the "best" architecture).

>  On X, both the non-Cairo and Cairo builds
> make use of hardware acceleration whenever available through both the
> Glamor component of the X server and the X render extension.
>
> NS also makes use of hardware acceleration, and IIUC GDI (which is used
> in MS-Windows) is also hardware accelerated.

Sure, but the question isn't a binary one (hardware accelerated vs
not) but how well is the available hardware being utilized which is a
much more difficult question to answer.

Re: Motif support

[Po Lu]

Akira Kyle <akira@akirakyle.com> writes:

> I know emacs supports these, my point was more about things that
> didn't exist when the current architecture of the display engine was
> conceived and thus assumptions that were made about hardware for the
> sake of performance do not necessarily now hold with newer hardware
> (for example subpixel font rendering on hidpi).

Subpixel font rendering is not the job of Emacs, or redisplay, it's the
job of the individual terminals and font drivers.  The Cairo and macOS
drivers do a pretty good job at that at present.

> Sure, but the question isn't a binary one (hardware accelerated vs
> not) but how well is the available hardware being utilized which is a
> much more difficult question to answer.

It's utilized very well, in the case of XRender and Glamor.

Re: Motif support

[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. ]]]

  > 21! Since then, I think a lot of assumptions about hardware have
  > changed or are changing: GPUs are now ubiquitous, 

In the free software community, GPUs are sometimes absent or
nonfunctional.  That's because many of them require the installed
operating system to contain nonfree software, and some of us refuse
to install a system which contains that.

What this means for Emacs is that we need to keep it working well
on the machines where some or all of the GPU's functionality is absent.
(I won't say "missing".)

Someday we will have processors that with GPUs that don't
require users to install nonfree software, and that problem will
cease.  But I don't expect that to happen next year.

  > None of which will require a rewrite to support.  In fact, Emacs 29
  > already supports precision mice, high definition displays, multitouch
  > trackpads, and digitizers.  On X, both the non-Cairo and Cairo builds
  > make use of hardware acceleration whenever available through both the
  > Glamor component of the X server and the X render extension.

We should take care not to add features to Emacs which _need_ the
acceleration, because they won't work well on the machines without
graphics acceleration.

-- 
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: Motif support

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> We should take care not to add features to Emacs which _need_ the
> acceleration, because they won't work well on the machines without
> graphics acceleration.

They will both work very well without graphics acceleration and on the
machines for which free graphics drivers and firmware are available.

Thanks.

Re: Motif support

[Robert Pluim]

>>>>> On Sun, 19 Dec 2021 11:28:47 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Well, we ended the thread with:

    >> > We could just remove support for '--with-x-toolkit=motif' from
    >> > configure.ac for a while, and see if anyone complains. If not, we rip
    >> > out the actual Motif code.
    >> 
    >> Sounds like a plan.

    Lars> And now we've had (at least) a couple complaints, so perhaps we should
    Lars> reconsider.  It did take almost a full year, so the complaints aren't...
    Lars> vigorous, though.

It looks like I wrongly assumed that the people who still build Emacs
with Motif support tracked master, and would thus all jump out and
complain instantly about my heinous crime. It looks more like they
wait for a new release, and this change is not in a released
version of Emacs (and Iʼve seen no messages from the alleged CDE
people affected by this).

If thereʼs a strong will to put it back, we can of course do so, but I
was hoping to achieve more removals of problematic display code. If
even such a small change is rejected, then I lose hope we will ever
achieve such simplifications.

Robert
-- 

Re: Motif support

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> If thereʼs a strong will to put it back, we can of course do so, but I
> was hoping to achieve more removals of problematic display code. If
> even such a small change is rejected, then I lose hope we will ever
> achieve such simplifications.

I'm all for simplifications -- the display code is indeed very
complicated, and the proliferation of #ifdefs is scary.

And there will always be protests when removing basically anything, so I
guess it's down to the number of protests, really.

In this specific instance, the number of protests has been small, and a
long time in coming.

But as I said, I don't really have much of an opinion on this specific
removal, so I'll let others decide.

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

Re: Motif support

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> As I said, Motif is the least of the problems here.

Yes, it's not a lot of code, and that points towards keeping it.  But on
the other hand, simplification is simplification.

> I'd say the toolkit responsible for 90% of the mess we have in xterm.c
> is GTK, of which 70% is the responsibility of GTK 3.
>
> The PGTK code unfortunately suffers from the same problem, as GTK isn't
> very suited to software like Emacs.

I don't think we can avoid supporting GTK, though, so it's something we
necessarily have to live with.  The same isn't the case with Motif.

> (BTW, is everything under gnu.org down?  Anyone know why that might be
> so?  Thanks.)

Yup; it's totally down -- no mail to @gnu.org/@fsf.org is being
delivered now.  (Except to debbugs.gnu.org, but last time this happened,
that server accepted mail and then discarded it, so I'll probably have
to resend all the bug-related mail I've been doing today.  *sigh*)

https://www.isitdownrightnow.com/gnu.org.html

and the status page isn't saying anything, 

https://hostux.social/@fsfstatus

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

Re: Motif support

[Robert Pluim]

>>>>> On Mon, 20 Dec 2021 18:35:20 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> I think only a small percentage of Emacs users track master.  Most of us
    Po> probably wait for the pretests to come out before complaining about this
    Po> or that.

Emacs *users* yes. I expected packagers to live a bit closer to the
bleeding edge.

    >> If thereʼs a strong will to put it back, we can of course do so, but I
    >> was hoping to achieve more removals of problematic display code. If
    >> even such a small change is rejected, then I lose hope we will ever
    >> achieve such simplifications.

    Po> I've been slowly working on cleaning up xterm.c, and from that
    Po> experience it doesn't seem like removing Motif support will achieve any
    Po> real simplification.  But there are lots of GTK-related things that
    Po> simply aren't necessary anymore, and some of the workarounds for GTK 3
    Po> we used to have need to be updated for recent developments in the GTK
    Po> world.

Thatʼs good to hear. Iʼd still like to remove eg Xft support

    Po> So again, I hope we will agree to reinstate Motif support.

Thatʼs not up to me, but Iʼm not going to object either.

Robert
-- 

Re: Motif support

[Eli Zaretskii]

> From: Akira Kyle <akira@akirakyle.com>
> Date: Sun, 19 Dec 2021 21:16:07 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I know emacs supports these, my point was more about things that
> didn't exist when the current architecture of the display engine was
> conceived and thus assumptions that were made about hardware for the
> sake of performance do not necessarily now hold with newer hardware
> (for example subpixel font rendering on hidpi). I'm by no means an
> expert in how the display code has evolved since then so I can't say
> whether a "rewrite from scratch" of that code today would look the
> same as it does now. My point about firefox is that that code looks
> vastly different today than it did 20 years ago (eg with webrender and
> potential other components coming from servo) because the whole
> architecture had to be rethought in order to take full advantage of
> hardware acceleration (and they did a lot of experimenting to figure
> out the "best" architecture).

I do know how the display code works and how it evolved, but frankly I
don't understand what you are trying to say, concretely.  I understand
the vague thoughts and ideas of the technological advances in GUI vs
the development of the Emacs display, but do you actually have
something specific to suggest about that, like what could the Emacs
display engine do differently using some of these technologies?
because I think we all understand the general issues; it's specific
practical ideas that are missing, if we really want to modernize the
Emacs display code.

And even if you are talking about a complete redesign of the display
engine, then again, to make that even marginally practical, please
present specific ideas of such a redesign.  That at least could give
someone motivation to sit down and develop those ideas at some point.

> Sure, but the question isn't a binary one (hardware accelerated vs
> not) but how well is the available hardware being utilized which is a
> much more difficult question to answer.

The question that interests me is which part(s) of the Emacs display
code you'd like to accelerate using this hardware.

Re: Motif support

[Stefan Monnier]

> The question that interests me is which part(s) of the Emacs display
> code you'd like to accelerate using this hardware.

Indeed, and maybe for that a first step would be to try and get actual
numbers about where the time is spent.

My assumption has always been that the times when redisplay isn't fast
aren't related to the complexity of actually drawing on the glass, but
instead it's due to the time spent updating the glyph matrices (and
other things before that such as running jit-lock).

How this could take advantage of GPUs is very much unclear to me.
Instead, I tried to speed this up by reducing the number of cases where
we just re-render all the windows.

Then again, maybe my assumption here is completely wrong.

My impression is that would be "easier" to speed things up by making use
of multiple CPUs rather than making use of GPUs.  True concurrency when
running ELisp is hard, but there are other ways to make use of multiple
CPUs:

- make the GC parallel.
- make the GC concurrent.
- use a separate thread per window-redisplay (so when redisplaying 20
  windows we can use 20 CPUs to update their glyph matrices).
- ...

I don't consider these examples as easy, but at least I have
a fairly clear idea of what it could look like.


        Stefan

Re: Motif support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Akira Kyle <akira@akirakyle.com>,  luangruo@yahoo.com,  ofv@wanadoo.es,
>   emacs-devel@gnu.org
> Date: Mon, 20 Dec 2021 14:01:52 -0500
> 
> My impression is that would be "easier" to speed things up by making use
> of multiple CPUs rather than making use of GPUs.  True concurrency when
> running ELisp is hard, but there are other ways to make use of multiple
> CPUs:
> 
> - make the GC parallel.
> - make the GC concurrent.
> - use a separate thread per window-redisplay (so when redisplaying 20
>   windows we can use 20 CPUs to update their glyph matrices).
> - ...

I think in all cases where redisplay was really slow, it was either
due to slow Lisp being called by JIT font-lock, or by very long lines
in the buffer, or both.  If we have several such windows, then yes,
having that run in parallel could speed up things, but is that really
a frequent case?

And anyway, working on several windows in parallel will have to deal
with the buffer-local stuff that changes global state, since each
window generally displays a different buffer, and the display code
makes that buffer current for the duration of time it works on a
window.

Re: Motif support

[Sean Whitton]

Hello,

On Mon 20 Dec 2021 at 12:09PM +01, Robert Pluim wrote:

>>>>>> On Mon, 20 Dec 2021 18:35:20 +0800, Po Lu <luangruo@yahoo.com> said:
>
>     Po> I think only a small percentage of Emacs users track master.  Most of us
>     Po> probably wait for the pretests to come out before complaining about this
>     Po> or that.
>
> Emacs *users* yes. I expected packagers to live a bit closer to the
> bleeding edge.

The view from the Debian Emacs team is that I think I'm the only one
tracking master out of four or five of us, and I'm not the one with
primary responsibility for packaging Emacs itself.

-- 
Sean Whitton

Re: Motif support

[Stefan Monnier]

>> - make the GC parallel.
>> - make the GC concurrent.
>> - use a separate thread per window-redisplay (so when redisplaying 20
>>   windows we can use 20 CPUs to update their glyph matrices).
>> - ...
>
> I think in all cases where redisplay was really slow, it was either
> due to slow Lisp being called by JIT font-lock, or by very long lines
> in the buffer, or both.  If we have several such windows, then yes,
> having that run in parallel could speed up things,

The jit-lock part can't be run in parallel (at least until we figure
out how to make ELisp code run parallel).  And with very long lines, the
problem is algorithmic, so concurrency won't help either.

> but is that really a frequent case?

None of the things I suggest above will fix all the problems, no.
Especially not the ones where things are *really* slow.  I suspect they
could help a fraction of the "middle" cases.  How much it would help
those cases, how important it is, and how it would impact other cases is
hard to tell (except maybe for the concurrent GC where the impact is
easier to predict, especially since we can draw on the experience of the
XEmacs guys with their incremental GC).

> And anyway, working on several windows in parallel will have to deal
> with the buffer-local stuff that changes global state, since each
> window generally displays a different buffer, and the display code
> makes that buffer current for the duration of time it works on a
> window.

Indeed.


        Stefan

Re: Motif support

[Akira Kyle]

On Mon, Dec 20, 2021 at 9:54 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> I do know how the display code works and how it evolved, but frankly I
> don't understand what you are trying to say, concretely.  I understand
> the vague thoughts and ideas of the technological advances in GUI vs
> the development of the Emacs display, but do you actually have
> something specific to suggest about that, like what could the Emacs
> display engine do differently using some of these technologies?
> because I think we all understand the general issues; it's specific
> practical ideas that are missing, if we really want to modernize the
> Emacs display code.
>

Sorry I don't have much to offer besides vague thoughts as I'm not an
expert in emacs' display code nor computer graphics in general, I was
more hoping it might prompt those who are experts to comment. Perhaps
the answer is, as Stefan suggested, that the largest slowness in
emacs' display is due to elisp, which has inherent difficulties in
being parallelized. I think, though, that it's probably best to
profile emacs' display to really understand what the bottlenecks are
before thinking about how things could be done more efficiently, and
often there are different approaches to parallelizing code that one
cannot a priori decide which will be the optimal. My cursory
understanding of the servo project is that they would often
implemented several different parallel approaches to see which ones
worked best in practice.

> And even if you are talking about a complete redesign of the display
> engine, then again, to make that even marginally practical, please
> present specific ideas of such a redesign.  That at least could give
> someone motivation to sit down and develop those ideas at some point.

I think the complexity of the current display code is a huge barrier
to this type of experimentation and I wonder if there would be a
cleaner abstraction for the various toolkits emacs can use than the
current "redisplay_interface" struct which if I understand correctly,
is the main way emacs currently abstracts each toolkit.

> > Sure, but the question isn't a binary one (hardware accelerated vs
> > not) but how well is the available hardware being utilized which is a
> > much more difficult question to answer.
>
> The question that interests me is which part(s) of the Emacs display
> code you'd like to accelerate using this hardware.

Re: Motif support

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> As I said, Motif is the least of the problems here.
>
> Yes, it's not a lot of code, and that points towards keeping it.  But on
> the other hand, simplification is simplification.

A similar reply probably got lost during the gnu.org outage, and I
forgot what I sent it to, so apologies in advance if this doesn't make
sense in context.

Since at least two people seem to be using the Motif port, and it has
some technical advantages over the others, and the other people seem to
be neutral on the subject, I'll restore Motif support to the emacs-28
branch in a day or so.

Please let me know if you see a problem with that, thanks.

Re: Motif support

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Tue, 21 Dec 2021 09:01:21 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Po Lu <luangruo@yahoo.com> writes:
> >
> >> As I said, Motif is the least of the problems here.
> >
> > Yes, it's not a lot of code, and that points towards keeping it.  But on
> > the other hand, simplification is simplification.
> 
> A similar reply probably got lost during the gnu.org outage, and I
> forgot what I sent it to, so apologies in advance if this doesn't make
> sense in context.
> 
> Since at least two people seem to be using the Motif port, and it has
> some technical advantages over the others, and the other people seem to
> be neutral on the subject, I'll restore Motif support to the emacs-28
> branch in a day or so.

I didn't yet decide that we should restore it, and doing that on
emacs-28 requires even more consideration.

Re: Motif support

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I think I might be able to cut back some of the stuff we do in GTK
> builds on the X port in the next 6 months, which will make for some
> actual simplification of the code.

Sounds good.  😀

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

Re: Motif support

[xenodasein--- via Emacs development discussions.]

(Not sure if this is the thread to bring this up in.)

Why does Emacs use so many GUI libraries? What is their advantage over
simply creating our own window and drawing our own scroll/menu bar?
Especially considering GUI libraries like GTK are the poster-children of
code-horror? (Which I guess is expected since GNOME people like to spend
their time on this Earth with deeds like slandering RMS. :) )

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 17:15:26 +0100 (CET)
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> Why does Emacs use so many GUI libraries? What is their advantage over
> simply creating our own window and drawing our own scroll/menu bar?
> Especially considering GUI libraries like GTK are the poster-children of
> code-horror? (Which I guess is expected since GNOME people like to spend
> their time on this Earth with deeds like slandering RMS. :) )

Various people like how various toolkits look and work, and want Emacs
to look and work similarly.  That's all there is to it.

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 05:28:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, rpluim@gmail.com, emacs-devel@gnu.org
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
> >   emacs-devel@gnu.org
> > Date: Tue, 21 Dec 2021 09:01:21 +0800
> > 
> > Since at least two people seem to be using the Motif port, and it has
> > some technical advantages over the others, and the other people seem to
> > be neutral on the subject, I'll restore Motif support to the emacs-28
> > branch in a day or so.
> 
> I didn't yet decide that we should restore it, and doing that on
> emacs-28 requires even more consideration.

After re-reading that discussion, I don't object to restoring the
Motif build, but please show the patch before installing: I want to
make sure it is safe enough for the release branch at this point.

Thanks.

Re: Motif support

[Robert Pluim]

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

>>>>> On Tue, 21 Dec 2021 19:01:28 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> I didn't yet decide that we should restore it, and doing that on
    >> emacs-28 requires even more consideration.

    Eli> After re-reading that discussion, I don't object to restoring the
    Eli> Motif build, but please show the patch before installing: I want to
    Eli> make sure it is safe enough for the release branch at this point.

    Eli> Thanks.

Attached


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Revert-Remove-Motif-support.patch --]
[-- Type: text/x-diff, Size: 2984 bytes --]

From b7d31d619247d1299d8a361945dddac8659811ee Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Tue, 21 Dec 2021 18:39:39 +0100
Subject: [PATCH] Revert "Remove Motif support"
To: emacs-devel@gnu.org

This reverts commit db237850abc240e2c3e765e9cc7e15ee5681dcaf.
---
 configure.ac | 9 +++++----
 etc/NEWS     | 3 ---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 766811b8a8..357d2538e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -410,18 +410,19 @@ AC_DEFUN
 dnl added later on when we find the file name of X, and it's best to
 dnl keep them together visually.
 AC_ARG_WITH([x-toolkit],[AS_HELP_STRING([--with-x-toolkit=KIT],
- [use an X toolkit (KIT one of: yes or gtk, gtk2, gtk3, lucid or athena, no)])],
+ [use an X toolkit (KIT one of: yes or gtk, gtk2, gtk3, lucid or athena, motif, no)])],
 [	  case "${withval}" in
 	    y | ye | yes )	val=gtk ;;
 	    n | no )		val=no  ;;
 	    l | lu | luc | luci | lucid )	val=lucid ;;
 	    a | at | ath | athe | athen | athena )	val=athena ;;
+	    m | mo | mot | moti | motif )	val=motif ;;
 	    g | gt | gtk  )	val=gtk ;;
 	    gtk2  )	val=gtk2 ;;
 	    gtk3  )	val=gtk3 ;;
 	    * )
 AC_MSG_ERROR(['--with-x-toolkit=$withval' is invalid;
-this option's value should be 'yes', 'no', 'lucid', 'athena', 'gtk',
+this option's value should be 'yes', 'no', 'lucid', 'athena', 'motif', 'gtk',
 'gtk2' or 'gtk3'.  'yes' and 'gtk' are synonyms.
 'athena' and 'lucid' are synonyms.])
 	    ;;
@@ -460,7 +461,7 @@ AC_DEFUN
 OPTION_DEFAULT_ON([libotf],[don't use libotf for OpenType font support])
 OPTION_DEFAULT_ON([m17n-flt],[don't use m17n-flt for text shaping])
 
-OPTION_DEFAULT_ON([toolkit-scroll-bars],[don't use Xaw3d/GTK toolkit scroll bars])
+OPTION_DEFAULT_ON([toolkit-scroll-bars],[don't use Motif/Xaw3d/GTK toolkit scroll bars])
 OPTION_DEFAULT_ON([xaw3d],[don't use Xaw3d])
 OPTION_DEFAULT_ON([xim],[at runtime, default X11 XIM to off])
 OPTION_DEFAULT_ON([xdbe],[don't use X11 double buffering support])
@@ -2251,7 +2252,7 @@ AC_DEFUN
    then
         AC_MSG_ERROR([You seem to be running X, but no X development libraries
 were found.  You should install the relevant development files for X
-and for the toolkit you want, such as Gtk+.  Also make
+and for the toolkit you want, such as Gtk+ or Motif.  Also make
 sure you have development files for image handling, i.e.
 tiff, gif, jpeg, png and xpm.
 If you are sure you want Emacs compiled without X window support, pass
diff --git a/etc/NEWS b/etc/NEWS
index e7d7215902..02b6f665b0 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -77,9 +77,6 @@ shaping, so 'configure' now recommends that combination.
 'configure --with-xdbe=no' can now be used to disable double buffering
 at build time.
 
----
-** Support for building with Motif has been removed.
-
 ---
 ** The configure option '--without-makeinfo' has been removed.
 This was only ever relevant when building from a repository checkout.
-- 
2.34.0

Re: Motif support

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: luangruo@yahoo.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Tue, 21 Dec 2021 18:47:07 +0100
> 
>     Eli> After re-reading that discussion, I don't object to restoring the
>     Eli> Motif build, but please show the patch before installing: I want to
>     Eli> make sure it is safe enough for the release branch at this point.
> 
>     Eli> Thanks.
> 
> Attached

Thanks, this looks safe enough (famous last words).

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02025.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 18:48:35 +0200

> Various people like how various toolkits look and work, and want Emacs
> to look and work similarly.  That's all there is to it.

I see, plenitude of choices.  Since my interest is game development It
felt peculiar to me as the common practice there is to just draw your
interface as how you want it to look, make it customizable possibly.

If I wanted to work on something like --with-x-toolkit=no but pretty and
customizable, using simple software rendering to run on all platforms,
is this something desirable?  It could be enabled in early-init to be
used instead of win32 toolkit for example.

Re: Motif support

[Robert Pluim]

>>>>> On Tue, 21 Dec 2021 19:53:26 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: luangruo@yahoo.com,  larsi@gnus.org,  emacs-devel@gnu.org
    >> Date: Tue, 21 Dec 2021 18:47:07 +0100
    >> 
    Eli> After re-reading that discussion, I don't object to restoring the
    Eli> Motif build, but please show the patch before installing: I want to
    Eli> make sure it is safe enough for the release branch at this point.
    >> 
    Eli> Thanks.
    >> 
    >> Attached

    Eli> Thanks, this looks safe enough (famous last words).

Hey, I tested it, and it produced the expected ugly-but-working Emacs.

Pushed as b7d31d6192

Robert
-- 

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 18:58:18 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> If I wanted to work on something like --with-x-toolkit=no but pretty and
> customizable, using simple software rendering to run on all platforms,
> is this something desirable?

I don't think I understand what that means in practice.  GUI
programming for drawing is inherently system-dependent; for example,
the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
you explain how something like that can work on all platforms?

Re: Motif support

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: luangruo@yahoo.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Tue, 21 Dec 2021 19:02:46 +0100
> 
>     Eli> Thanks, this looks safe enough (famous last words).
> 
> Hey, I tested it, and it produced the expected ugly-but-working Emacs.
> 
> Pushed as b7d31d6192

Thanks.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02036.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 20:09:26 +0200

> I don't think I understand what that means in practice.  GUI
> programming for drawing is inherently system-dependent; for example,
> the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
> you explain how something like that can work on all platforms?

For the maintenance of the frame, true, but we do not need the platform
to draw what we put inside that window, no? I still need to use X,
Wayland, win32 etc.  But they need not dictate what the program looks
like, as all video game look different.

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 19:28:45 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02036.html
> From:	Eli Zaretskii
> Subject: Re: Motif support
> Date:	Tue, 21 Dec 2021 20:09:26 +0200
> 
> > I don't think I understand what that means in practice.  GUI
> > programming for drawing is inherently system-dependent; for example,
> > the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
> > you explain how something like that can work on all platforms?
> 
> For the maintenance of the frame, true, but we do not need the platform
> to draw what we put inside that window, no?

Of course, we do.  Displaying text in a GUI window (a.k.a. "frame")
requires Xlib calls on X, Win32 API calls on MS-Windows, etc.  And the
fonts available on each platform OOTB are generally different.  And
then we have display of images, which again uses platform-dependent
GUI API calls, mouse and keyboard inputs and WM events that are
accessed using platform-dependent GUI API calls, etc.

> I still need to use X, Wayland, win32 etc.  But they need not
> dictate what the program looks like, as all video game look
> different.

Experience tells us that users on every platforms generally want Emacs
to look and feel like other GUI programs on that platform.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 20:37:03 +0200

> And then we have display of images, which again uses platform-dependent
> GUI API calls, mouse and keyboard inputs and WM events that are
> accessed using platform-dependent GUI API calls, etc.

They are platform calls, a GUI toolkit need not be a middleman. Our GUI
elements here can be thought of as one of those images, as an example.
We simply tell system's window/frame to display it, like BitBlt or
StretchDIBits fron Win32 API.  Same for input.

> Of course, we do.  Displaying text in a GUI window (a.k.a. "frame")
> requires Xlib calls on X, Win32 API calls on MS-Windows, etc.  And the
> fonts available on each platform OOTB are generally different.

These are also simply platform layer calls right?  There's no widget toolkit
involved.  If a platform does not provide text rendering, we could use
something like FreeType, which is what Xft uses I presume?

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 20:18:16 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > And then we have display of images, which again uses platform-dependent
> > GUI API calls, mouse and keyboard inputs and WM events that are
> > accessed using platform-dependent GUI API calls, etc.
> 
> They are platform calls, a GUI toolkit need not be a middleman. Our GUI
> elements here can be thought of as one of those images, as an example.

Not necessarily.  On some platforms, the "toolkit" is built-in: you
cannot display a GUI window without using the toolkit.  MS-Windows is
one such platform (and I believe NS is another).

> We simply tell system's window/frame to display it, like BitBlt or
> StretchDIBits fron Win32 API.  Same for input.

That doesn't really work.  For example, the pixels that you want to
bitblt have to be created somehow, and how do you think you create
them, if not by drawing to some off-screen surface using those same
GUI API calls that you want to avoid.  (Assuming, that is, that you
don't really intend Emacs to construct those pixels bit by bit "by
hand", i.e. reinvent all the graphics programming from scratch.)

> > Of course, we do.  Displaying text in a GUI window (a.k.a. "frame")
> > requires Xlib calls on X, Win32 API calls on MS-Windows, etc.  And the
> > fonts available on each platform OOTB are generally different.
> 
> These are also simply platform layer calls right?  There's no widget toolkit
> involved.

Not necessarily.  For example, menus on Windows cannot be created
without going through the "toolkit".

> If a platform does not provide text rendering, we could use
> something like FreeType, which is what Xft uses I presume?

AFAIR, FreeType port for Windows calls Windows APIs where it needs to
access system services.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date:	Tue, 21 Dec 2021 20:37:03 +0200

Sorry, forgot to answer the last part:

> Experience tells us that users on every platforms generally want Emacs
> to look and feel like other GUI programs on that platform.

I feels like this contradicts VSCode's popularity, which has it's unique
look?  Why shouldn't Emacs have a signature keewl look?

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02046.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 21:29:55 +0200

> That doesn't really work.  For example, the pixels that you want to
> bitblt have to be created somehow, and how do you think you create
> them, if not by drawing to some off-screen surface using those same
> GUI API calls that you want to avoid.  (Assuming, that is, that you
> don't really intend Emacs to construct those pixels bit by bit "by
> hand", i.e. reinvent all the graphics programming from scratch.)
> ...
> Not necessarily.  For example, menus on Windows cannot be created
> without going through the "toolkit".

Yes, that is exactly what I meant all along by saying "a simple
software renderer".  It really isn't that hard to draw a 2D GUI, no
need to reinvent all graphics, only a miniscule part. Text rendering
is the hard part, which we delegate. We draw the menus how we want them
to look, then tell the platform to display them.

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 20:45:07 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > Experience tells us that users on every platforms generally want Emacs
> > to look and feel like other GUI programs on that platform.
> 
> I feels like this contradicts VSCode's popularity, which has it's unique
> look?  Why shouldn't Emacs have a signature keewl look?

If this is true (I don't use VSCode, so I don't know), then perhaps
because VSCode users and Emacs users have different expectations?

> Yes, that is exactly what I meant all along by saying "a simple
> software renderer".  It really isn't that hard to draw a 2D GUI, no
> need to reinvent all graphics, only a miniscule part. Text rendering
> is the hard part, which we delegate. We draw the menus how we want them
> to look, then tell the platform to display them.

I very much doubt this will produce anything useful, let alone why
would we want yet another "toolkit".  But feel free to prove me wrong
by showing code that does this.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02048.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 21:51:13 +0200

> If this is true (I don't use VSCode, so I don't know), then perhaps
> because VSCode users and Emacs users have different expectations?

I specifically mentioned that editor because it's popularity became
something ridiculous, almost monopolistic. If we steal even a drop
of that user base Emacs' could double.

> I very much doubt this will produce anything useful, let alone why
> would we want yet another "toolkit". But feel free to prove me wrong
> by showing code that does this.

The code you mention; is it enough for it to be a simple library in a
single C file? Or do you want to see it integrated and working in Emacs?
The latter wouldn't be too easy for me to, if it is not something wanted
in Emacs.  But that could be decided after looking at the former?

Re: Motif support

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 21:15:12 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > I very much doubt this will produce anything useful, let alone why
> > would we want yet another "toolkit". But feel free to prove me wrong
> > by showing code that does this.
> 
> The code you mention; is it enough for it to be a simple library in a
> single C file? Or do you want to see it integrated and working in Emacs?
> The latter wouldn't be too easy for me to, if it is not something wanted
> in Emacs.  But that could be decided after looking at the former?

What would the library be capable of?  You say that you can replace
all the window decorations we now implement via toolkits: menus,
dialogs, scroll bars, title and caption bar, the tool bar.  Will all
of this be in the library, complete with support for colors and other
stuff?  If not, what would such a library prove?

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02051.html
From:	Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 22:23:12 +0200

> What would the library be capable of? You say that you can replace
> all the window decorations we now implement via toolkits: menus,
> dialogs, scroll bars, title and caption bar, the tool bar. Will all
> of this be in the library, complete with support for colors and other
> stuff? If not, what would such a library prove?

Yes, I can do the listed elements (without text; I could use FreeType
but I'd rather keep build simple. And what is the caption bar? I normally
use --without-x), it would look like an Emacs frame with window area being
empty, elements interact-able.  Just rendering code with WinMain.

Re: Motif support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Not necessarily.  On some platforms, the "toolkit" is built-in: you
> cannot display a GUI window without using the toolkit.  MS-Windows is
> one such platform (and I believe NS is another).

That's correct, and I'd like to add Haiku to that list as well.

Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> The code you mention; is it enough for it to be a simple library in a
> single C file? Or do you want to see it integrated and working in Emacs?
> The latter wouldn't be too easy for me to, if it is not something wanted
> in Emacs.  But that could be decided after looking at the former?

We tried with such a library, many eons ago.  It was named lwlib, and
you can judge for yourself how successful it is.

Re: Motif support

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 21 Dec 2021 19:53:26 +0200, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: luangruo@yahoo.com,  larsi@gnus.org,  emacs-devel@gnu.org
>     >> Date: Tue, 21 Dec 2021 18:47:07 +0100
>     >> 
>     Eli> After re-reading that discussion, I don't object to restoring the
>     Eli> Motif build, but please show the patch before installing: I want to
>     Eli> make sure it is safe enough for the release branch at this point.
>     >> 
>     Eli> Thanks.
>     >> 
>     >> Attached
>
>     Eli> Thanks, this looks safe enough (famous last words).
>
> Hey, I tested it, and it produced the expected ugly-but-working Emacs.
>
> Pushed as b7d31d6192

Thanks.

Re: Motif support

[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. ]]]

  > > We should take care not to add features to Emacs which _need_ the
  > > acceleration, because they won't work well on the machines without
  > > graphics acceleration.

  > They will both work very well without graphics acceleration and on the
  > machines for which free graphics drivers and firmware are available.

That's how it should be.  But since we don't yet know what changes
would be required, to achieve that abstract goal, how can anyone be
sure of this a priori?

-- 
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: Motif support

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

>   > They will both work very well without graphics acceleration and on the
>   > machines for which free graphics drivers and firmware are available.

> That's how it should be.  But since we don't yet know what changes
> would be required, to achieve that abstract goal, how can anyone be
> sure of this a priori?

I regularly test Emacs on obscure X configurations, including those that
use software rendering, and also non-X.Org servers which do not support
hardware acceleration.

Emacs performs very well on all of them.

Thanks.

Re: Motif support

[Arthur Miller]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sun, 19 Dec 2021 11:28:47 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:
>
>     Lars> Well, we ended the thread with:
>
>     >> > We could just remove support for '--with-x-toolkit=motif' from
>     >> > configure.ac for a while, and see if anyone complains. If not, we rip
>     >> > out the actual Motif code.
>     >> 
>     >> Sounds like a plan.
>
>     Lars> And now we've had (at least) a couple complaints, so perhaps we should
>     Lars> reconsider.  It did take almost a full year, so the complaints aren't...
>     Lars> vigorous, though.
>
> It looks like I wrongly assumed that the people who still build Emacs
> with Motif support tracked master, and would thus all jump out and
> complain instantly about my heinous crime. It looks more like they
> wait for a new release, and this change is not in a released
> version of Emacs (and Iʼve seen no messages from the alleged CDE
> people affected by this).
>
> If thereʼs a strong will to put it back, we can of course do so, but I
> was hoping to achieve more removals of problematic display code. If
> even such a small change is rejected, then I lose hope we will ever
> achieve such simplifications.

I feel said. Is there really anyone in the world who cares for Motif?

Emacs C source is full of spaghetti-if-defs all over the place. It would be nice
if it was cleaned of some old stuff not cared by more than 5 people.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02081.html
From: Po Lu
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 08:52:49 +0800

Please try to understand what idea someone is trying to convey, and
ask for comments if you see any lack of clarity before dishing out
judgments.

Here is what lwlib README says:
"This subdirectory contains the Lucid Widget Library (lwlib), which
provides a uniform interface to a few different X toolkits..."

This is textbook case nightmare inside a nightmare, and NOT what I am
proposing at all.



Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02051.html
From:   Eli Zaretskii
Subject: Re: Motif support
Date: Tue, 21 Dec 2021 22:23:12 +0200

> What would the library be capable of? You say that you can replace
> all the window decorations we now implement via toolkits: menus,
> dialogs, scroll bars, title and caption bar, the tool bar. Will all
> of this be in the library, complete with support for colors and other
> stuff? If not, what would such a library prove?

Repeating my previous answer; it seems more suitable to continue here.

"Yes, I can do the listed elements (without text; I could use FreeType
but I'd rather keep build simple. And what is the caption bar? I normally
use --without-x), it would look like an Emacs frame with window area being
empty, elements interact-able.  Just rendering code with WinMain."

Addendum:

What this proves is that I am not fooling around, and it provides you
a convenient way to assess my code.  If satisfactory I can receive
the go and proceed integrating it on a test branch.

This opens a myriad of possibilities.  Off the top of my head, it
becomes almost trivial to use a minimap instead of the scrollbar.
It gives Elisp the ability to dictate how Emac looks.  For example
packages like this: https://github.com/org-roam/org-roam-ui will
start to pop up in lisp, instead of jAvAschRiPt.  It will make way
for "Office" level decorations.  Eat that, Microsoft!

I don't want to create the impression that I am trying to hastily
my slap machina-tion into Emacs.  I am fine with doing maintenance
work for some time first, until this feature is discussed again
sometime in the future.  For now it is more than enough that you take
the time to explain intricacies of Emacs platform layer to a total
stranger.  Thanks.

Relevant mail:

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02193.html
From: Óscar Fuentes
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 16:51:41 +0100

Re: Motif support

[Arthur Miller]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02051.html
> From:	Eli Zaretskii
> Subject: Re: Motif support
> Date: Tue, 21 Dec 2021 22:23:12 +0200
>
>> What would the library be capable of? You say that you can replace
>> all the window decorations we now implement via toolkits: menus,
>> dialogs, scroll bars, title and caption bar, the tool bar. Will all
>> of this be in the library, complete with support for colors and other
>> stuff? If not, what would such a library prove?
>
> Yes, I can do the listed elements (without text; I could use FreeType
> but I'd rather keep build simple. And what is the caption bar? I normally
> use --without-x), it would look like an Emacs frame with window area being
> empty, elements interact-able.  Just rendering code with WinMain.
Isn't Emacs already linked to FreeType2 library?

I am not sure how much work it would be, and how well it would play with
harfbuzz and what Emacs uses for text rendering, but at least in theory it could
be possibly to render text without system libraries. Or is it too much work? If
I am not misstaken, alacritty uses Freetype2 to load fonts and renders all text
on gpu. Emacs does not need to do it on gpu, but would it be too much work to go
that path?

In general, I share your opinion from the start of this thread, that Emacs could
in general do fine with just one OS window for the frame and do it's own thing
for the little GUI it does (menubar, toolbar, buttons and scrollbars,
fringes). They could maybe even be implemented in pure lisp, with help of svg
renderer or without. But, yes, the looks and feel wouldn't feel "native". 

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Po Lu <luangruo@yahoo.com>,  Eli
>  Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 16:58:18 +0100
> 
> Emacs C source is full of spaghetti-if-defs all over the place. It would be nice
> if it was cleaned of some old stuff not cared by more than 5 people.

Reinstating Motif support didn't touch any C code, so what makes you
sad didn't happen.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
From: Arthur Miller
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 18:09:55 +0100

Hello, it'd make for a nicer mail experience if you reply to this:
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02203.html
instead of here.

> Isn't Emacs already linked to FreeType2 library?

What I proposed was just a demonstration prototype, not something to
appear verbatim in emacs, otherwise you are correct.

> ... But, yes, the looks and feel wouldn't feel "native".

It could be trivially themed to look native too.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 21 Dec 2021 18:58:18 +0100 (CET)
>> From: xenodasein@tutanota.de
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> 
>> If I wanted to work on something like --with-x-toolkit=no but pretty and
>> customizable, using simple software rendering to run on all platforms,
>> is this something desirable?
>
> I don't think I understand what that means in practice.  GUI
> programming for drawing is inherently system-dependent; for example,
> the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
> you explain how something like that can work on all platforms?

Games usually do all GUI drawing themselves. Doesn't gdk/gtk use Cairo
to render it's own gui on a surface so they are not dependent on any OS toolkit?

I am not an expert on Gtk, and I am sure there are many paths there to render a
GUI, but it was something along those lines if I remember when Wayland
development was starting up.

Blender for example also uses this approach to render entire GUI in the
application, and just uses low level stuff from the OS to open a window and
obtain drawing contexts, to deal with input, keyboard, mouse and such, but gui
elements such as buttons and menus are created and managed by Blender itself.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 22, 2021, 20:24 by xenodasein

> Quoting: > https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
> From: Arthur Miller
> Subject: Re: Motif support
> Date: Wed, 22 Dec 2021 18:09:55 +0100
>
> Hello, it'd make for a nicer mail experience if you reply to this:
> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02203.html
> instead of here.
>
> > Isn't Emacs already linked to FreeType2 library?
>
> What I proposed was just a demonstration prototype, not something to
> appear verbatim in emacs, otherwise you are correct.
>
> > ... But, yes, the looks and feel wouldn't feel "native".
>
> It could be trivially themed to look native too.
>
>
Oops, wrong quote link. This one is the intended one:
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02212.html

Re: Motif support

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 17:39:14 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> What this proves is that I am not fooling around, and it provides you
> a convenient way to assess my code.  If satisfactory I can receive
> the go and proceed integrating it on a test branch.

My preference would be for you to do this directly in Emacs code (on a
fork somewhere that's convenient for you).  The reason is that I have
gray hair from taking code that works stand-alone and then adapting it
to Emacs -- too many times it turns out that some key assumptions
about how Emacs works that are revealed to be false imply that some
design based on those assumptions is in fact unworkable without much
more serious surgery elsewhere in Emacs.

I've been in this kind of "reverse-eureka" situations a couple of
times myself, and saw others there.

So I grew suspicious to stand-alone demonstrations outside of the
Emacs codebase.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: xenodasein@tutanota.de,  emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 18:26:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Tue, 21 Dec 2021 18:58:18 +0100 (CET)
> >> From: xenodasein@tutanota.de
> >> Cc: Emacs Devel <emacs-devel@gnu.org>
> >> 
> >> If I wanted to work on something like --with-x-toolkit=no but pretty and
> >> customizable, using simple software rendering to run on all platforms,
> >> is this something desirable?
> >
> > I don't think I understand what that means in practice.  GUI
> > programming for drawing is inherently system-dependent; for example,
> > the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
> > you explain how something like that can work on all platforms?
> 
> Games usually do all GUI drawing themselves.

So you are saying that so should we??

> Doesn't gdk/gtk use Cairo
> to render it's own gui on a surface so they are not dependent on any OS toolkit?

Did you look at, for example, the MS-Windows back-end of the Cairo
port to Windows?

> Blender for example also uses this approach to render entire GUI in the
> application, and just uses low level stuff from the OS to open a window and
> obtain drawing contexts, to deal with input, keyboard, mouse and such, but gui
> elements such as buttons and menus are created and managed by Blender itself.

I don't understand what you are saying.  Should we use GTK or should
we reinvent its code inside Emacs?

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Po Lu <luangruo@yahoo.com>,  Eli
>>  Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Wed, 22 Dec 2021 16:58:18 +0100
>> 
>> Emacs C source is full of spaghetti-if-defs all over the place. It would be nice
>> if it was cleaned of some old stuff not cared by more than 5 people.
>
> Reinstating Motif support didn't touch any C code, so what makes you
> sad didn't happen.

Oh, I hoped it would be removed from C code, but now when people complained it
will stay there :-).

No, I maybe sound annoying, it wasn't my goal, but my opinion is that code has
lots of paths which makes it quite hard to read and understand, so I generally
welcome anything that can make it less complex.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02221.html
From: Eli Zaretskii
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 19:32:06 +0200

Agreed.  Emacs is pretty unique amongst programs.

Re: Motif support

[Arthur Miller]

xenodasein@tutanota.de writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02040.html
> From: Arthur Miller
> Subject: Re: Motif support
> Date: Wed, 22 Dec 2021 18:09:55 +0100
>
> Hello, it'd make for a nicer mail experience if you reply to this:
> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02203.html
> instead of here.
>
>> Isn't Emacs already linked to FreeType2 library?
>
> What I proposed was just a demonstration prototype, not something to
> appear verbatim in emacs, otherwise you are correct.
>
>> ... But, yes, the looks and feel wouldn't feel "native".
>
> It could be trivially themed to look native too.

Trivially and trivially :). I would be very careful to call it so, but Emacs has
relatively modest GUI demands. Some things are maybe not so difficult to emulate
but some other would be harder. For example menus and buttons are not so hard to
emulate for gtk toolkit, but tooltips would need quite some work to look same. I
don't know, some other toolkits might need more work. No idea, but I would not
aim for fully themeable renderer. In that case it is better to just use gtk and
to render with gtk everywhere, but than you get people who prefer Motif to Gtk
and in practice it will probably never happen.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02235.html
From: Arthur Miller
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 19:07:11 +0100

> Trivially and trivially :). I would be very careful to call it so, but Emacs has
> relatively modest GUI demands.

I am speaking of course in relative terms, with Emacs itself being
opposite of trivial; what is stretching and coloring a few pixels
in comparison?

> ...In that case it is better to just use gtk and to render with gtk...

All GTK achieves is effing with people's command loops while providing
a drop of the capability.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 18:56:35 +0100
> 
> No, I maybe sound annoying, it wasn't my goal, but my opinion is that code has
> lots of paths which makes it quite hard to read and understand, so I generally
> welcome anything that can make it less complex.

We don't develop Emacs to make its code easy to understand, we develop
Emacs to make it useful on platforms and in configurations we want to
support.  How easy will the code be is secondary.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: xenodasein@tutanota.de,  emacs-devel@gnu.org
>> Date: Wed, 22 Dec 2021 18:26:41 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Tue, 21 Dec 2021 18:58:18 +0100 (CET)
>> >> From: xenodasein@tutanota.de
>> >> Cc: Emacs Devel <emacs-devel@gnu.org>
>> >> 
>> >> If I wanted to work on something like --with-x-toolkit=no but pretty and
>> >> customizable, using simple software rendering to run on all platforms,
>> >> is this something desirable?
>> >
>> > I don't think I understand what that means in practice.  GUI
>> > programming for drawing is inherently system-dependent; for example,
>> > the --with-x-toolkit=no build uses Xlib calls all over the place.  Can
>> > you explain how something like that can work on all platforms?
>> 
>> Games usually do all GUI drawing themselves.
>
> So you are saying that so should we??
I'm not devil's advocate nor your enemy Eli. I don't say Emacs should do
this or that because someone else is doing it, or just to say it.

What I try to say is that it is possible to do gui on it's own. Emacs is not a
typical gui application anyway; it is not full of dialogs and views and what
not. Menus, toolbar and scrollbar are not very hard to do without external
toolkit, and since this thread took up that Emacs talks to numerous toolkits, it
may be pointed out that doing own thing might be a simplification of the code
base.


>> Doesn't gdk/gtk use Cairo
>> to render it's own gui on a surface so they are not dependent on any OS toolkit?
>
> Did you look at, for example, the MS-Windows back-end of the Cairo
> port to Windows?

Not really. I am quite sure they need to talk to the OS at some point, but
that is different to rely on OS to render menus and buttons, or just low level
stuff to open a window or blit ssurfaces.

>> Blender for example also uses this approach to render entire GUI in the
>> application, and just uses low level stuff from the OS to open a window and
>> obtain drawing contexts, to deal with input, keyboard, mouse and such, but gui
>> elements such as buttons and menus are created and managed by Blender itself.
>
> I don't understand what you are saying.  Should we use GTK or should
> we reinvent its code inside Emacs?

Emacs uses just small subset of Gtk, doesn't it? So if it wasn't for the look &
feel, as you said in some opening mail, because people want Emacs to look and
feel as the rest of the platform, Emacs wouldn't really need it?

I don't say you should use neither this or that. Emacs could probaly use only
Gtk to render it's gui on all platforms and remove other gui paths.

This thread was about Emacs talking to many different toolkits and someone
suggesting that situation could be simplified. I try to come med input, but as I
see, Motif is still important to someone. Is there Athena backend
somewhere still viable :)?

I am not trying to be devil't advocate, or annoying, I just believe that code
base would be easier to work and experiment with without so many different paths.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02225.html
From: Eli Zaretskii
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 19:40:21 +0200

>> Games usually do all GUI drawing themselves.
> So you are saying that so should we??

Believe it or not, Emacs is much more reminiscent of a game engine than
a desktop app.  Also if definition of video game was; a software, use of
which instills high levels of fun to the user, by definition Emacs is one.
:)

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: xenodasein@tutanota.de,  emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 20:14:39 +0100
> 
> >> Games usually do all GUI drawing themselves.
> >
> > So you are saying that so should we??
> I'm not devil's advocate nor your enemy Eli. I don't say Emacs should do
> this or that because someone else is doing it, or just to say it.
> 
> What I try to say is that it is possible to do gui on it's own.

It's possible, sure.  But why would we want to do that?  We have
enough work on our hands without that.

> Menus, toolbar and scrollbar are not very hard to do without external
> toolkit, and since this thread took up that Emacs talks to numerous toolkits, it
> may be pointed out that doing own thing might be a simplification of the code
> base.

If you read this thread since its beginning, you have read the message
where I explained that it won't simplify the code, because eventually
you'd need to call the GUI APIs that are different for different
platforms.

> > Did you look at, for example, the MS-Windows back-end of the Cairo
> > port to Windows?
> 
> Not really. I am quite sure they need to talk to the OS at some point, but
> that is different to rely on OS to render menus and buttons, or just low level
> stuff to open a window or blit ssurfaces.

I suggest that you look at the code, because the reality is quite
different from what you think.  The calls to Win32 APIs are all over
the place there.

> I am not trying to be devil't advocate, or annoying, I just believe that code
> base would be easier to work and experiment with without so many different paths.

If you can suggest reasonable practical ways of doing that, by all
means go ahead.  I didn't yet hear any such proposal in this
discussion.

Re: Motif support

[Arthur Miller]

xenodasein@tutanota.de writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02225.html
> From: Eli Zaretskii
> Subject: Re: Motif support
> Date: Wed, 22 Dec 2021 19:40:21 +0200
>
>>> Games usually do all GUI drawing themselves.
>> So you are saying that so should we??
>
> Believe it or not, Emacs is much more reminiscent of a game engine than
> a desktop app.
I was also thinking of same when I wrote my replay to Eli, but I didn't want to
took it up. :)

Re: Motif support

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 20:19:24 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: eliz@gnu.org, arthur.miller@live.com, ofv@wanadoo.es
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02225.html
> From: Eli Zaretskii
> Subject: Re: Motif support
> Date: Wed, 22 Dec 2021 19:40:21 +0200
> 
> >> Games usually do all GUI drawing themselves.
> > So you are saying that so should we??
> 
> Believe it or not, Emacs is much more reminiscent of a game engine than
> a desktop app.

I indeed don't believe it.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  larsi@gnus.org,
>>   emacs-devel@gnu.org
>> Date: Wed, 22 Dec 2021 18:56:35 +0100
>> 
>> No, I maybe sound annoying, it wasn't my goal, but my opinion is that code has
>> lots of paths which makes it quite hard to read and understand, so I generally
>> welcome anything that can make it less complex.
>
> We don't develop Emacs to make its code easy to understand, we develop
> Emacs to make it useful on platforms and in configurations we want to
> support.  How easy will the code be is secondary.

Yes of course, I didn't meant it is priority to be easy to understand. But if
some old cruft that no one, or really very few people, use was removed, it would
implicitly also make the code base slightly less complicated to understand and
maintain. Would that be a bad thing?

Re: Motif support

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> What I try to say is that it is possible to do gui on it's own.
>
> It's possible, sure.  But why would we want to do that?

It gives you ultimate control over the GUI. Start with a surface and put
there whatever you want.

> We have enough work on our hands without that.

He is not asking you to do the work ;-)

>> Menus, toolbar and scrollbar are not very hard to do without external
>> toolkit, and since this thread took up that Emacs talks to numerous toolkits, it
>> may be pointed out that doing own thing might be a simplification of the code
>> base.
>
> If you read this thread since its beginning, you have read the message
> where I explained that it won't simplify the code, because eventually
> you'd need to call the GUI APIs that are different for different
> platforms.

You can use a cross-platform layer for that. There are many readily
available, developed by the game crowd. Some of them are ridiculously
simple and powerful at the same time.

>> > Did you look at, for example, the MS-Windows back-end of the Cairo
>> > port to Windows?
>> 
>> Not really. I am quite sure they need to talk to the OS at some point, but
>> that is different to rely on OS to render menus and buttons, or just low level
>> stuff to open a window or blit ssurfaces.
>
> I suggest that you look at the code, because the reality is quite
> different from what you think.  The calls to Win32 APIs are all over
> the place there.

See above.

>> I am not trying to be devil't advocate, or annoying, I just believe that code
>> base would be easier to work and experiment with without so many different paths.
>
> If you can suggest reasonable practical ways of doing that, by all
> means go ahead.  I didn't yet hear any such proposal in this
> discussion.

It would be not easy. Well, actually, the easier part would be the pure
graphical one. But integrating events and, above all, defining, exposing
and implementing on the display engine the new primitives for the
drawing features we wish to expose to Elisp looks like the most
difficult part to me.

And then every possible technique for the graphical part has its own
rough edges that you need to overcome. But if done right Emacs would
give any other modern editor a run for his money.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 20:46:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Arthur Miller <arthur.miller@live.com>
> >> Cc: luangruo@yahoo.com,  rpluim@gmail.com,  larsi@gnus.org,
> >>   emacs-devel@gnu.org
> >> Date: Wed, 22 Dec 2021 18:56:35 +0100
> >> 
> >> No, I maybe sound annoying, it wasn't my goal, but my opinion is that code has
> >> lots of paths which makes it quite hard to read and understand, so I generally
> >> welcome anything that can make it less complex.
> >
> > We don't develop Emacs to make its code easy to understand, we develop
> > Emacs to make it useful on platforms and in configurations we want to
> > support.  How easy will the code be is secondary.
> 
> Yes of course, I didn't meant it is priority to be easy to understand. But if
> some old cruft that no one, or really very few people, use was removed, it would
> implicitly also make the code base slightly less complicated to understand and
> maintain. Would that be a bad thing?

But we decided that we do want to support Motif for now.

Re: Motif support

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 21:08:31 +0100
> 
> You can use a cross-platform layer for that.

That's a different suggestion.  This one does make sense, we "just"
need a volunteer to sit down and do it.

Re: Motif support

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Games usually do all GUI drawing themselves.
>> > So you are saying that so should we??
>> 
>> Believe it or not, Emacs is much more reminiscent of a game engine than
>> a desktop app.
>
> I indeed don't believe it.

I agree with the OP. Emacs does a lot of micro-management of graphical
elements and does its own event processing. That's distinctive of games.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 21:08:31 +0100
>> 
>> You can use a cross-platform layer for that.
>
> That's a different suggestion.  This one does make sense, we "just"
> need a volunteer to sit down and do it.
But you already have one such layer om Emacs; Gtk, GDK is a cross platform
rendering layer Gtk uses, but Emacs could use just Cairo which is also used by
Emacs.

If I am not wrong Gtk runs pretty much everywhere where GUI Emacs run, isn't it
so? I am not sure how well it runs on Haiku, but otherwise.

So just let a volunteer remove pure xlib/win32/motif/ and make Emacs a pure Gtk
application and all good :).

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> I don't say you should use neither this or that. Emacs could probaly use only
> Gtk to render it's gui on all platforms and remove other gui paths.

That would be a bad mistake.  For instance, we would lose the ability to
open frames in multiple displays without worrying about crashes.

GTK is also a pain to get working on MS-Windows and macOS.

> This thread was about Emacs talking to many different toolkits and someone
> suggesting that situation could be simplified.

We don't "talk to many (X) toolkits" in a significant fashion.  We talk
to X, and the toolkits are used to display trinkets.

> I try to come med input, but as I see, Motif is still important to
> someone. Is there Athena backend somewhere still viable :)?

That toolkit is called "Lucid".  (And it's not a backend, since the
important talking is done with X, not lwlib.)

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> But you already have one such layer om Emacs; Gtk, GDK is a cross
> platform rendering layer Gtk uses, but Emacs could use just Cairo
> which is also used by Emacs.

Cairo is hardly cross-platform.  grep for `USE_BE_CAIRO' in
src/haiku_support.cc and you will see how much of a mess using it
anywhere other than a platform they explictly support is.

GDK only supports X and Wayland well: everywhere else, your mileage will
vary a lot.  Its support for macOS is particularly bad.

> If I am not wrong Gtk runs pretty much everywhere where GUI Emacs run,
> isn't it so? I am not sure how well it runs on Haiku, but otherwise.

It doesn't run on Haiku at all.

> So just let a volunteer remove pure xlib/win32/motif/ and make Emacs a
> pure Gtk application and all good :).

First you will have to fix the amazing attitude of the GTK+ developers
when it comes to fixing bugs from programs that don't fit within their
narrow worldview, such as programs that need to control the size of
their scroll bar thumbs, or programs that want to open windows on
multiple displays at once.

There is really no good "cross-platform toolkit" that suits our
purposes.

Re: Motif support

[Michael Welsh Duggan]

Arthur Miller <arthur.miller@live.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Óscar Fuentes <ofv@wanadoo.es>
>>> Date: Wed, 22 Dec 2021 21:08:31 +0100
>>> 
>>> You can use a cross-platform layer for that.
>>
>> That's a different suggestion.  This one does make sense, we "just"
>> need a volunteer to sit down and do it.
> But you already have one such layer om Emacs; Gtk, GDK is a cross platform
> rendering layer Gtk uses, but Emacs could use just Cairo which is also used by
> Emacs.
>
> If I am not wrong Gtk runs pretty much everywhere where GUI Emacs run, isn't it
> so? I am not sure how well it runs on Haiku, but otherwise.
>
> So just let a volunteer remove pure xlib/win32/motif/ and make Emacs a pure Gtk
> application and all good :).

Except, doesn't the GTK version have a bug that we have been unable to
fix with respect to remote frames when a network connection crashes?  I
could have misremembered the exact problem, but I remember that I ran
into it frequently and do not use the Gtk version anymore due to this.
This would be a deal breaker for me.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> This is textbook case nightmare inside a nightmare, and NOT what I am
> proposing at all.

"Nightmare inside a nightmare" is what happens with _every_ attempt to
abstract between different window systems and toolkits.

Be it named lwlib, or wxWidgets, or GTK.

> "Yes, I can do the listed elements (without text; I could use FreeType
> but I'd rather keep build simple. And what is the caption bar? I normally
> use --without-x), it would look like an Emacs frame with window area being
> empty, elements interact-able.  Just rendering code with WinMain."

Now that you can expect everyone to use FreeType, why not also expect
them to have fontconfig installed on their systems?

> Addendum:
>
> For example packages like this:
> https://github.com/org-roam/org-roam-ui will start to pop up in lisp,
> instead of jAvAschRiPt.

Why is that so?

>   It will make way for "Office" level decorations.  Eat that,
> Microsoft!

We do not want "decorations" like MS-Office.  We want the ability to
edit documents like MS-Office, including the indentation of
variable-pitch text.  Feel free to work on that instead.

Re: Motif support

[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 regularly test Emacs on obscure X configurations, including those that
  > use software rendering, and also non-X.Org servers which do not support
  > hardware acceleration.

  > Emacs performs very well on all of them.

Can you undertake to do that frequently, so that if this ever ceases
to perform well, you'll inform us very soon?

-- 
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: Motif support

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

>   > I regularly test Emacs on obscure X configurations, including those that
>   > use software rendering, and also non-X.Org servers which do not support
>   > hardware acceleration.
>
>   > Emacs performs very well on all of them.

> Can you undertake to do that frequently, so that if this ever ceases
> to perform well, you'll inform us very soon?

I will try.  In the short term I can probably arrange to test this way
every week, but that could change in the long term.

Thanks.

Re: Motif support

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 21:24:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >> Games usually do all GUI drawing themselves.
> >> > So you are saying that so should we??
> >> 
> >> Believe it or not, Emacs is much more reminiscent of a game engine than
> >> a desktop app.
> >
> > I indeed don't believe it.
> 
> I agree with the OP. Emacs does a lot of micro-management of graphical
> elements and does its own event processing. That's distinctive of games.

There's a large chasm between "micro-management of graphical elements
and own event processing" and doing all the GUI by hand, bit by bit.
It is far from being black-and-white.  And Emacs is very far from the
edge you seem to be saying we are at or near.  You are invited to read
the code and see for yourself.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 00:44:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Wed, 22 Dec 2021 21:08:31 +0100
> >> 
> >> You can use a cross-platform layer for that.
> >
> > That's a different suggestion.  This one does make sense, we "just"
> > need a volunteer to sit down and do it.
> But you already have one such layer om Emacs; Gtk, GDK is a cross platform
> rendering layer Gtk uses, but Emacs could use just Cairo which is also used by
> Emacs.

GTK is not really cross-platform, and more importantly, is being
developed in directions that make it harder and harder to use in
Emacs.  So Emacs should not throw all the eggs into the GTK basket,
quite the opposite: we should find a way of migrating away of GTK
(assuming we can find a good replacement).

Re: Motif support

[Madhu]

* Arthur Miller <DB9PR09MB498654A6B8A8D5B84A9B7CC8967D9@DB9PR09MB4986.eurprd09.prod.outlook.com> :
Wrote on Wed, 22 Dec 2021 16:58:18 +0100:

> I feel said. Is there really anyone in the world who cares for Motif?
>
> Emacs C source is full of spaghetti-if-defs all over the place. It
> would be nice if it was cleaned of some old stuff not cared by more
> than 5 people.

This is an example of one of the subtle ways in which a "freedoma
narrative" is introduced to remove freedom from software, destroy value,
and devalue the work of others by people who are not invested in the
code at all.

Re: Motif support

[Madhu]

Sorry ignore my earlier message. I should've read ahead before
responding.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Óscar Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
>> Date: Thu, 23 Dec 2021 00:44:06 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Óscar Fuentes <ofv@wanadoo.es>
>> >> Date: Wed, 22 Dec 2021 21:08:31 +0100
>> >> 
>> >> You can use a cross-platform layer for that.
>> >
>> > That's a different suggestion.  This one does make sense, we "just"
>> > need a volunteer to sit down and do it.
>> But you already have one such layer om Emacs; Gtk, GDK is a cross platform
>> rendering layer Gtk uses, but Emacs could use just Cairo which is also used by
>> Emacs.
>
> GTK is not really cross-platform, and more importantly, is being
> developed in directions that make it harder and harder to use in
> Emacs.  So Emacs should not throw all the eggs into the GTK basket,
> quite the opposite: we should find a way of migrating away of GTK
> (assuming we can find a good replacement).

Allright, didn't know you were not happy with Gtk as is. I had a feeling that
Emacs was moving towards Gtk.

Than yes, Emacs would need some other abstraction layer. Is it realistic to use
just Cairo, since it is already in use in Emacs? Also Cairo has support for
using GPU. It is just that there are rumors that Cairo is deprecated or not
developed any more, but I don't know how true it is, I don't really follow the
web rumors.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 21:24:52 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> >> Games usually do all GUI drawing themselves.
>> >> > So you are saying that so should we??
>> >> 
>> >> Believe it or not, Emacs is much more reminiscent of a game engine than
>> >> a desktop app.
>> >
>> > I indeed don't believe it.
>> 
>> I agree with the OP. Emacs does a lot of micro-management of graphical
>> elements and does its own event processing. That's distinctive of games.
>
> There's a large chasm between "micro-management of graphical elements
> and own event processing" and doing all the GUI by hand, bit by bit.
> It is far from being black-and-white.  And Emacs is very far from the
> edge you seem to be saying we are at or near.  You are invited to read
> the code and see for yourself.

In a way a repl is kind of similar to a game loop in that it reads input (read),
update the world (eval) and render the world (print). The other similarity is
that Emacs is also controlling it's loop rather than fitting into some
frameworks loop such as Gtk, or some other toolkits framework. You rather use
those as a library of functionality to draw things when they suit Emacs, while
desktop applications would usually fit into a framework and let toolkit do the
update and drawing when it needs to be done. GUI toolkits like Gtk are usually
"don't call us, we call you", while games, and I perecive Emacs, are rather, "do
this for me when I ask you".

Maybe I missunderstand how Emacs works, but that is how I understood it.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 23 Dec 2021 08:58:29 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> In a way a repl is kind of similar to a game loop in that it reads input (read),
> update the world (eval) and render the world (print). The other similarity is
> that Emacs is also controlling it's loop rather than fitting into some
> frameworks loop such as Gtk, or some other toolkits framework. You rather use
> those as a library of functionality to draw things when they suit Emacs, while
> desktop applications would usually fit into a framework and let toolkit do the
> update and drawing when it needs to be done. GUI toolkits like Gtk are usually
> "don't call us, we call you", while games, and I perecive Emacs, are rather, "do
> this for me when I ask you".

That difference is largely irrelevant in the context of this
particular discussion, since we are specifically talking about drawing
stuff, not about the framework or the main loop.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Than yes, Emacs would need some other abstraction layer. Is it
> realistic to use just Cairo, since it is already in use in Emacs? Also
> Cairo has support for using GPU. It is just that there are rumors that
> Cairo is deprecated or not developed any more, but I don't know how
> true it is, I don't really follow the web rumors.

These aren't rumors, the Cairo developers are indeed not very active
anymore.

GPU acceleration is also really just supported on X, and getting Cairo
to work on any other platform is a massive PITA.

Re: Motif support

[Óscar Fuentes]

Arthur Miller <arthur.miller@live.com> writes:

> Allright, didn't know you were not happy with Gtk as is. I had a feeling that
> Emacs was moving towards Gtk.

The recent addition of Wayland support by means of adapting our Gtk
usage is great news, but I see many people which is not very happy about
having to deal with Gtk, here and elsewhere.

> Than yes, Emacs would need some other abstraction layer. Is it realistic to use
> just Cairo, since it is already in use in Emacs? Also Cairo has support for
> using GPU. It is just that there are rumors that Cairo is deprecated or not
> developed any more, but I don't know how true it is, I don't really follow the
> web rumors.

I just briefly looked at Cairo repo and it shows a fair amount of
activity. OTOH, all the rage nowadays is Skia. It is C++, though.

Re: Motif support

[Arthur Miller]

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

Madhu <enometh@meer.net> writes:

> * Arthur Miller <DB9PR09MB498654A6B8A8D5B84A9B7CC8967D9@DB9PR09MB4986.eurprd09.prod.outlook.com> :
> Wrote on Wed, 22 Dec 2021 16:58:18 +0100:
>
>> I feel said. Is there really anyone in the world who cares for Motif?
>>
>> Emacs C source is full of spaghetti-if-defs all over the place. It
>> would be nice if it was cleaned of some old stuff not cared by more
>> than 5 people.
>

Actually, I percieve that for freedom of software it is equally important to
have documentation for the sources as the sources themselves. Situation with
docs is somewhat addressed in last years or so, but there were times when many
GNU projects came out with very few comments, usually no dev docs, and scarce
descriptions about internals. I said several times to Eli Z. to write a book
about Emacs internals; that would probably be the best boost to Emacs
development.

As time goes by, projects are growing, Emacs too, and it takes more and more
time to understand it for people new to the source. If you have a family and
full time job, you might not have the time for all the detective work that is
sometimes needed. It can be unfortunate, if you know what to do to implement
something, but have to spend lot of time to investigate how Emacs does it.

The popular belief is that Emacs development is hold back by lack of "modern
development" in form of some public git repository and pr-modell as used on
github & co. I don't think that is what hold more people to contribute to
Emacs. There is SXEmacs, a fork of XEmacs, that has git workflow as the popular 
request is for GNU Emacs. They even have tools to make it easier to work with
SXEmacs itself, and they also made some populistic changes of the time, like
reformatted the code to kernel style and removed Windows port and implemented
FFI. Yet, they have no active devs seems like. What is the problem? I don't know,
but I would rather say the complexity and that it is hard and time consuming to
do deeper changes if you are not quite familiar with internals. It will be
interesting to see if there will be a flood of developers incoming after a
change to sourcehut or whatever is chosen for future development. I would be
happy if I am wrong of course.

> This is an example of one of the subtle ways in which a "freedoma
> narrative" is introduced to remove freedom from software, destroy value,
> and devalue the work of others by people who are not invested in the
> code at all.

When it comes to Motif, the fact is that it is a dead toolkit. It is alive just
so its devs can milk money out of some existing customers and old code bases,
but I can't imagine anyone clear in their minds to use it for a new
project. Motif hasn't been relevant for like 15+ years, maybe 20, I don't
know. I don't understand why Debian maintainers build Emacs with Motif, when
even Debian stable comes with Gtk, but it is their choice of course.

Just for the fun I have attached comparison, side by side of SXEmacs and GNU
Emacs, SXEmacs uses Motif to render it's gui and pure X I guess to render
fonts. In my eyes it looks very ugly, I don't think it is representable of what
GNU Emacs can do to give to anyone an Emacs built on Motif nowadays. (I don't
have a build of GNU Emacs with Motif, so I took SXEmacs).


[-- Attachment #2: sxe-vs-gnu.png --]
[-- Type: image/png, Size: 184576 bytes --]

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Actually, I percieve that for freedom of software it is equally
> important to have documentation for the sources as the sources
> themselves. Situation with docs is somewhat addressed in last years or
> so, but there were times when many GNU projects came out with very few
> comments, usually no dev docs, and scarce descriptions about
> internals. I said several times to Eli Z. to write a book about Emacs
> internals; that would probably be the best boost to Emacs development.

Emacs internals are documented very well, inside both the relevant parts
of the Lisp reference manual and the code itself.  Writing a book would
not make for much benefit.  In fact, it would become tiresome to keep
that book up to date.

I think that there is a misconception floating around the internet that
Emacs internals are difficult to understand.  Certain individuals
spreading misinformation hold a great deal of responsibility for this
situation.  IOW, a significant boost to Emacs development will result
from combating this disinformation.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02275.html
From: Po Lu
Subject: Re: Motif support
Date: Thu, 23 Dec 2021 08:58:36 +0800

> "Nightmare inside a nightmare" is what happens with _every_ attempt to
> abstract between different window systems and toolkits.

That is why I am proposing something else, if you cared to read.

> Now that you can expect everyone to use FreeType, why not also expect
> them to have fontconfig installed on their systems?

You are still writing without reading or understanding what I explained
on this topic, so please do not reply to me ever again if this will keep
happening, it is a waste of whole emacs-devel's time, not just mine.

>> instead of jAvAschRiPt.
> Why is that so?

Why does Elisp exist? Please ponder, and do not answer.

>> It will make way for "Office" level decorations.
> We do not want "decorations" like MS-Office.  We want the ability to
> edit documents like MS-Office, including the indentation of
> variable-pitch text.

"Office level" does not mean the same thing as "Office like", same old
same old.  So you are saying that you want to do what Office does
without the same level of visual feedback?  I also want to be able to
move like a car without being one. :)

> Feel free to work on that instead.

I feel like what is going to happen is while working on a large change
it will become apparent that it will necessitate another one, then
someone else like you will appear and say that "We only want what
I want, don't do, change or discuss anything else."  Then the discussion
will become long and time-consuming, it will then get reprimands in the
form of "why are you wasting time talking and not producing cute little
commits?"  I hope I'm wrong but this is my impression so far.

Re: Motif support

[Po Lu]

xenodasein@tutanota.de writes:

>> "Nightmare inside a nightmare" is what happens with _every_ attempt to
>> abstract between different window systems and toolkits.

> That is why I am proposing something else, if you cared to read.

I cared to read, and I don't understand why your proposed solution
doesn't fit the description of "abstraction between window systems".

> You are still writing without reading or understanding what I
> explained on this topic, so please do not reply to me ever again if
> this will keep happening, it is a waste of whole emacs-devel's time,
> not just mine.

You proposed to use FreeType for all text rendering, and I replied why
that is not desirable.

> "Office level" does not mean the same thing as "Office like", same old
> same old.  So you are saying that you want to do what Office does
> without the same level of visual feedback?  I also want to be able to
> move like a car without being one. :)

So you're saying we won't be able to correctly indent (for example)
variable pitch text if we don't have decorations that look like what
MS-Office has? Please demonstrate why that is the case, because I really
cannot believe that statement.

Thanks.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02341.html
From: Po Lu
Subject: Re: Motif support
Date: Thu, 23 Dec 2021 18:54:38 +0800

> I cared to read, and I don't understand why your proposed solution
> doesn't fit the description of "abstraction between window systems"...

The answer is same as the answer to this question:
"How can the old game called Mario is able to have the same HUD on
countless platforms?"
If you study this the answer will become apparent.

> You proposed to use FreeType for all text rendering, and I replied why
> that is not desirable.

You did not read.  It was for a small demonstration prototype program,
not for Emacs.  You are making me write the things I have already
written.

> So you're saying we won't be able to correctly indent (for example)
> variable pitch text if we don't have decorations that look like what
> MS-Office has? Please demonstrate why that is the case, because I really
> cannot believe that statement.

I believe we have different pictures in our heads regarding how much of
the features of Office is desired inside Emacs, which cancels this
this conversation and opens another big one, which I do not want right
now.

Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> The answer is same as the answer to this question:
> "How can the old game called Mario is able to have the same HUD on
> countless platforms?"
> If you study this the answer will become apparent.

Emacs is not a game based on displaying 8-bit graphics tiles, if that's
what you mean.  But I'm afraid I don't understand what you're trying to
allude to here.

> I believe we have different pictures in our heads regarding how much of
> the features of Office is desired inside Emacs, which cancels this
> this conversation and opens another big one, which I do not want right
> now.

The features I am referring to are the features listed in etc/TODO.
Here is a copy of that list for your convenience:

 . import / export MS Office documents
 . import / export Open Document Format (.odt) files
 . import / export RTF files
 . export to a PDF file
 . select a font and its size
 . apply a bold / italic / underline / strikethrough effect
 . superscripts / subscripts
 . apply a left / center / right / justified effect
 . change the font color and the background color
 . pixel-level text fill, justification, and indentation (so that
   variable-pitch fonts could be freely used)
 . create a list
 . insert and change a table
 . insert a picture
 . define / use / modify styles
 . print preview / print, in a way that is similar to what's on screen
   (e.g., wrt the place where lines wrap)
 . use footnotes
 . support for "track changes" markings, including those which come
   from Office documents
 . multiple columns
 . change page headers and footers
 . save all the properties and settings mentioned above with the text
   to a file, so that they are restored when later visiting that file

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Than yes, Emacs would need some other abstraction layer. Is it
>> realistic to use just Cairo, since it is already in use in Emacs? Also
>> Cairo has support for using GPU. It is just that there are rumors that
>> Cairo is deprecated or not developed any more, but I don't know how
>> true it is, I don't really follow the web rumors.
>
> These aren't rumors, the Cairo developers are indeed not very active
> anymore.
Ok. Thanks for confirming. By the way, what is the reason? Maybe they have
implemented the functionality they needed? Is it considered complete?

> GPU acceleration is also really just supported on X
Hardware acceleration only on X is fine. Win32/Mac are
proprietary OS:s, so if Cairo does support gpu acceleration on those, I think it
is fine. Current Emacs does not use gpu acceleration anyway (more than what OS
uses to render windows), so I don't think it is a major issue.

>                                                          getting Cairo
> to work on any other platform is a massive PITA.

I can only speak for win32, since I have never owned a mac machine so have no
idea how it works overthere. It is PITA if you gonna compile Cairo on Win32
yourself from the sources because you have to chase and compile all the deps,
glib, libxm2 and co and so on. But it is not PITA if you install precompiled
one, or ou choose to install it via MSYS2 which is as simple as intalling it on
Arch Linux. Anyway, it wouldn't be problem for Emacs, Emacs does not include
Cairo sources, and even if you prefer to compile it yourself, since Emacs
is build on MSYS2 (is cygwin officially supported?), building Cairo is just one
command line away, just as in gnu/Linux, so I don't think it is PITA.

Anyway, if gdk or cairo itself as a 2d drawing library to implement guis is
not acceptable, there are others. Personally I would prefer emacs to do gui in
Lisp, not in C, so that C core could be simplifed to just deal with OS windows,
fonts and input, but as I understand from the discussion, it is not acceptable.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Ok. Thanks for confirming. By the way, what is the reason? Maybe they
> have implemented the functionality they needed? Is it considered
> complete?

No, it's because their last user (GTK+) has stopped using Cairo in its
latest release, replacing it with a custom alternative that can only be
used with GTK.

> Hardware acceleration only on X is fine. Win32/Mac are proprietary
> OS:s, so if Cairo does support gpu acceleration on those, I think it
> is fine. Current Emacs does not use gpu acceleration anyway (more than
> what OS uses to render windows), so I don't think it is a major issue.

Emacs does use GPU acceleration on every supported platform, as long as
that is present.

> I can only speak for win32, since I have never owned a mac machine so
> have no idea how it works overthere. It is PITA if you gonna compile
> Cairo on Win32 yourself from the sources because you have to chase and
> compile all the deps, glib, libxm2 and co and so on. But it is not
> PITA if you install precompiled one, or ou choose to install it via
> MSYS2 which is as simple as intalling it on Arch Linux. Anyway, it
> wouldn't be problem for Emacs, Emacs does not include Cairo sources,
> and even if you prefer to compile it yourself, since Emacs is build on
> MSYS2 (is cygwin officially supported?), building Cairo is just one
> command line away, just as in gnu/Linux, so I don't think it is PITA.

[..]

> Anyway, if gdk or cairo itself as a 2d drawing library to implement
> guis is not acceptable, there are others. Personally I would prefer
> emacs to do gui in Lisp, not in C, so that C core could be simplifed
> to just deal with OS windows, fonts and input, but as I understand
> from the discussion, it is not acceptable.

I can speak for Haiku at least when I say that Cairo isn't very
portable.  On every not-that-popular platform (such as Haiku), you can
only use image surfaces, and then you have to work out how to integrate
them well with the toolkit provided by that platform, and things start
to go downhill from there.

Besides, it will bring us no benefit at all, except to cause annoyance
to many users.  (Have you ever tried making Fontconfig work properly on
other platforms?  Cairo needs that for fonts.)  Most of the mess we have
results from having to take care of the idiosyncrasies of each window
system, and not implementing the basic drawing operations for that
window system.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

All the discussion on this line of thread about the pain third-party
"libs" like GTK inflict on Emacs.  Emacs drawing it's own interface is
an order of magnitude easier, and cross-platform.  I don't know, man.

Re: Motif support

[Po Lu]

xenodasein@tutanota.de writes:

> All the discussion on this line of thread about the pain third-party
> "libs" like GTK inflict on Emacs.  Emacs drawing it's own interface is
> an order of magnitude easier, and cross-platform.

That's exactly the situation here, especially with GTK+.  Whether or not
it seems plausible to you is not really relevant, as experience says
something very different from your expectations.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 23, 2021, 14:39 by Po Lu:

> xenodasein writes:
>
>> All the discussion on this line of thread about the pain third-party
>> "libs" like GTK inflict on Emacs.  Emacs drawing it's own interface is
>> an order of magnitude easier, and cross-platform.
>>
>
> That's exactly the situation here, especially with GTK+.  Whether or not
> it seems plausible to you is not really relevant, as experience says
> something very different from your expectations.
>

You don't even understand how Mario works, so don't come
here attacking me about my "expectations" and experience.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 23 Dec 2021 08:58:29 +0100
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>> 
>> In a way a repl is kind of similar to a game loop in that it reads input (read),
>> update the world (eval) and render the world (print). The other similarity is
>> that Emacs is also controlling it's loop rather than fitting into some
>> frameworks loop such as Gtk, or some other toolkits framework. You rather use
>> those as a library of functionality to draw things when they suit Emacs, while
>> desktop applications would usually fit into a framework and let toolkit do the
>> update and drawing when it needs to be done. GUI toolkits like Gtk are usually
>> "don't call us, we call you", while games, and I perecive Emacs, are rather, "do
>> this for me when I ask you".
>
> That difference is largely irrelevant in the context of this
> particular discussion, since we are specifically talking about drawing
> stuff, not about the framework or the main loop.

Well it is what it is about, how Emacs draw the world (or rather buffers). Since
Emacs uses toolkit in that fashion, and it already pretends that a gui window is
a text terminal (as D. Colascione put it in one old text he wrote), Emacs can as
well use it's own library functions to do the gui, and just use a (relatively)
tiny wrapper for os/hardware to implement that abstraction.

I suggested Cairo or gdk as such, but that does not seem to be popular for
different reasons you and Po mentioned, but there might be other ones already
written that could be suitable.

I have understanding that you hae implemented quite advanced text renderer at
least on X; I am not sure if you do same on win32 or Emacs uses built-in OS text
rendering on Windows. In that light, I wonder if Emacs even need 3rd party
abstraction and toolkits other than for, as you said in the beginning of the
thread, to fit into looks of the platform.

Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> You don't even understand how Mario works, so don't come here
> attacking me about my "expectations" and experience.

I wasn't referring to how Mario works, I'm referring to the conclusions
I've developed about cross-platform toolkits (GTK in particular) in the
course of my recent work on the X, Haiku and PGTK ports of Emacs, which
again is not "Mario" or any other video game.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> I have understanding that you hae implemented quite advanced text
> renderer at least on X;  I am not sure if you do same on win32 or Emacs
> uses built-in OS text rendering on Windows.

Emacs doesn't implement its own text renderer anywhere, I think.  We use
libraries that can be considered part of the system for that everywhere.

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Actually, I percieve that for freedom of software it is equally
>> important to have documentation for the sources as the sources
>> themselves. Situation with docs is somewhat addressed in last years or
>> so, but there were times when many GNU projects came out with very few
>> comments, usually no dev docs, and scarce descriptions about
>> internals. I said several times to Eli Z. to write a book about Emacs
>> internals; that would probably be the best boost to Emacs development.
>
> Emacs internals are documented very well, inside both the relevant parts
> of the Lisp reference manual and the code itself.  Writing a book would
> not make for much benefit.  In fact, it would become tiresome to keep
> that book up to date.
Situation has got much better in late years. It wasn't always so.

> I think that there is a misconception floating around the internet that
> Emacs internals are difficult to understand.  Certain individuals
> spreading misinformation hold a great deal of responsibility for this
> situation.  IOW, a significant boost to Emacs development will result
> from combating this disinformation.
Ok. We have all seen how much personal guidance you have needed from
Eli on even a minor details to get your offsceen lines working. If you think it
is so easy, why didn't you just hand in a patch that worked? Cmon, seriosuly.

I don't know how much time you have on your disposal, but looking at how many
different things on Emacs you are commenting/working on, how many OS systems you
write you use, all from Windows 9x to Haiky, all kind of strange X
configurations and so on, you must have all days on your disposal to hack
Emacs. It is great, and your work is appreciated. But if you expect eveyrone to
have that time is unrealistic. To say certain individuals spread missinformation
is just plain immature. Nobody is spreading missinformation, and certainly not
on purpose.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Ok. We have all seen how much personal guidance you have needed from
> Eli on even a minor details to get your offsceen lines working. If you
> think it is so easy, why didn't you just hand in a patch that worked?

Actually, it was due to a mistake in the documentation that the
discussion was started.  Such a mistake could happen anywhere, even
inside a book.

Then the discussion turned from "why doesn't it work" to "what would be
the best interface to expose for this".  Once again, not something a
book can solve.

> I don't know how much time you have on your disposal, but looking at
> how many different things on Emacs you are commenting/working on, how
> many OS systems you write you use, all from Windows 9x to Haiky, all
> kind of strange X configurations and so on, you must have all days on
> your disposal to hack Emacs. It is great, and your work is
> appreciated.

I don't have a lot of time to work on Emacs, I just try to make good use
of the time I do have (which probably comes out to around 1/7th of each
day.)

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Ok. Thanks for confirming. By the way, what is the reason? Maybe they
>> have implemented the functionality they needed? Is it considered
>> complete?
>
> No, it's because their last user (GTK+) has stopped using Cairo in its
> latest release, replacing it with a custom alternative that can only be
> used with GTK.
Ok. Thanks.

>> Hardware acceleration only on X is fine. Win32/Mac are proprietary
>> OS:s, so if Cairo does support gpu acceleration on those, I think it
>> is fine. Current Emacs does not use gpu acceleration anyway (more than
>> what OS uses to render windows), so I don't think it is a major issue.
>
> Emacs does use GPU acceleration on every supported platform, as long as
> that is present.
Than we are not talking about same thing here. Of course every OS window will
use gpu if it's present. I meant using something like opengl or other terms to
render stuff ourselves not via OS.

>> I can only speak for win32, since I have never owned a mac machine so
>> have no idea how it works overthere. It is PITA if you gonna compile
>> Cairo on Win32 yourself from the sources because you have to chase and
>> compile all the deps, glib, libxm2 and co and so on. But it is not
>> PITA if you install precompiled one, or ou choose to install it via
>> MSYS2 which is as simple as intalling it on Arch Linux. Anyway, it
>> wouldn't be problem for Emacs, Emacs does not include Cairo sources,
>> and even if you prefer to compile it yourself, since Emacs is build on
>> MSYS2 (is cygwin officially supported?), building Cairo is just one
>> command line away, just as in gnu/Linux, so I don't think it is PITA.
>
> [..]
>
>> Anyway, if gdk or cairo itself as a 2d drawing library to implement
>> guis is not acceptable, there are others. Personally I would prefer
>> emacs to do gui in Lisp, not in C, so that C core could be simplifed
>> to just deal with OS windows, fonts and input, but as I understand
>> from the discussion, it is not acceptable.
>
> I can speak for Haiku at least when I say that Cairo isn't very
> portable.  On every not-that-popular platform (such as Haiku), you can
> only use image surfaces, and then you have to work out how to integrate
> them well with the toolkit provided by that platform, and things start
> to go downhill from there.

Ok, I understand.

> Besides, it will bring us no benefit at all, except to cause annoyance
> to many users.  (Have you ever tried making Fontconfig work properly on
> other platforms?  Cairo needs that for fonts.)  Most of the mess we have
> results from having to take care of the idiosyncrasies of each window
> system, and not implementing the basic drawing operations for that
> window system.

So you are lobbying for implementing Emacs own graphic context abstraction? :)

In general I think Emacs already has the code needed, but refactoring it is
probably quite a work. But it can be done :).

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> So you are lobbying for implementing Emacs own graphic context
> abstraction? :)

No, I'm lobbying for keeping the status quo, which will continue to
serve us well (or at least, better than the competition.)

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> The answer is same as the answer to this question:
>> "How can the old game called Mario is able to have the same HUD on
>> countless platforms?"
>> If you study this the answer will become apparent.
>
> Emacs is not a game based on displaying 8-bit graphics tiles, if that's
> what you mean.  But I'm afraid I don't understand what you're trying to
> allude to here.

Not to be a devil's advocate, but if an 8-bit game can achieve this, than maybe
there is something to learn from it? Don't you think it is an achievement? I am
not trying to be rude or annyoing, just a reflection.

>> I believe we have different pictures in our heads regarding how much of
>> the features of Office is desired inside Emacs, which cancels this
>> this conversation and opens another big one, which I do not want right
>> now.

I have never looked at that list, but when I see it now, I think several of
those listed features are implementable already, as the Emacs is at the
moment. I have commented under those that I think are not impossible to
implement or are not very hard:

> The features I am referring to are the features listed in etc/TODO.
> Here is a copy of that list for your convenience:

>  . export to a PDF file
Isn't that already possible via 3rd party pacakges? Org-mode? 

>  . apply a bold / italic / underline / strikethrough effect
>  . superscripts / subscripts
>  . apply a left / center / right / justified effect
>  . change the font color and the background color
>  . pixel-level text fill, justification, and indentation (so that
>    variable-pitch fonts could be freely used)
Isn't all of this possible already? Anyone interested could attach that to an
svg button, or plain text button for an interested major/minor mode? I did
center, left, right and pixelwise when I tested transparency patach a couple
weeks ago. Org already have syntax to specify bold, italcis
(bugged). superscirpts etc. It could be instead connected to a menu choice or a button.

>  . create a list
What kind of list? Any symbol in emacs is a potential list, what is meant with this.

>  . insert and change a table
What kind of table? org-table? sql-table?

>  . insert a picture
Same as above, you could attach lisp functions to text or svg buttons already

>  . define / use / modify styles
What styles are we talking about here?

>  . use footnotes
>  . change page headers and footers
Doesn't org-mnode already implement this?

>  . save all the properties and settings mentioned above with the text
>    to a file, so that they are restored when later visiting that file
Which file? Emacs does not have custom format. I don't see reason for it to have
one either becaue probably most of people would prefer their text to be readable
in other software. Otherwise dump buffer + text properties as lisp objects to a
file with print and read them back with read. Is that not workable for some
reason? Texr properties are a plist, so they should be dumpable, right? I am not
sure if interval for a text property is internal to C core, of if it is exposed
to Lisp. If it is not exposed, and stored in text property list, than it would
need to be done so or to recieve special care. Sorry if I am not familiar with
all the details, I am not using Emacs in this way, so I never tried this either.

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I have understanding that you hae implemented quite advanced text
>> renderer at least on X;  I am not sure if you do same on win32 or Emacs
>> uses built-in OS text rendering on Windows.
>
> Emacs doesn't implement its own text renderer anywhere, I think.  We use
> libraries that can be considered part of the system for that everywhere.
I think I have expressed myself badly here; anyway what I meant, Emacs could use
pango and harfbuzz and whatever else it uses on X together with freetype2 to render
text on all platforms. 

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> I have never looked at that list, but when I see it now, I think
> several of those listed features are implementable already, as the
> Emacs is at the moment. I have commented under those that I think are
> not impossible to implement or are not very hard:

I think that those features are wanted in a complete system, and not as
individual pieces scattered around in random places such as org-mode
(which isn't WYSIWYG either.)

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> I think I have expressed myself badly here; anyway what I meant, Emacs
> could use pango and harfbuzz and whatever else it uses on X together
> with freetype2 to render text on all platforms.

We don't use Pango on X for anything more than converting the output of
the GTK font selection dialog to a font spec.

HarfBuzz is already used on MS-Windows, and the idea is to eventually
use it on macOS as well.

As for using FreeType, what benefit would it bring?  Rendering text with
FreeType is not very easy and involves writing a lot of interface code
for each platform, often more than using the platform's built-in
interface.  (For simple examples, see the deleted ftx driver, or the
ftbe driver that was deleted, and for non-trivial examples, see
ftcrfont.c and xftfont.c.)

It usually involves Fontconfig as well, which doesn't work very well
non-Unix systems.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 23 Dec 2021 12:53:18 +0100
> Cc: Madhu <enometh@meer.net>, emacs-devel@gnu.org
> 
> Ok. We have all seen how much personal guidance you have needed from
> Eli on even a minor details to get your offsceen lines working.

That was basically the second time Po Lu implemented something in the
display engine, and the first time he had to deal with layout code, so
some guidance should be expected, for a complex piece of software that
takes more than 40K LOC.  From my POV, the guidance he needed was
relatively minor; most of the discussion was about the various
implementation strategies.

Re: Motif support

[dick]

PL> I don't have a lot of time to work on Emacs, I just try to make good
PL> use of the time I do have (which probably comes out to around 1/7th
PL> of each day.)

GNU Emacs should be relieved to be spared of the other 6/7th.

Re: Motif support

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Date: Thu, 23 Dec 2021 09:36:46 -0500
> Cc: emacs-devel@gnu.org
> 
> PL> I don't have a lot of time to work on Emacs, I just try to make good
> PL> use of the time I do have (which probably comes out to around 1/7th
> PL> of each day.)
> 
> GNU Emacs should be relieved to be spared of the other 6/7th.

What code should or shouldn't be admitted into Emacs is not up to you,
so please withhold your judgment, as we are not interested in it.

And once again, please stop ad-hominem attacks on people here.

Re: Motif support

[dick]

Your allowing someone to mangle an emacs primitive in d54d8a8 for the
benefit of his "precision" pixel scrolling pet project is inexcusable.

Yes, that is ad hominem, in the sense that bad code doesn't write itself.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02250.html
From: Eli Zaretskii

> >>> Games usually do all GUI drawing themselves.
> >> So you are saying that so should we??
>
> > Believe it or not, Emacs is much more reminiscent of a game engine than
> > a desktop app.

> I indeed don't believe it.

Do you say this having used and inspected the source code of multiple
relatively recent game engines?  If that is the case, an elaboration
from someone of your experience level would be valuable.

Re: Motif support

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 10:01:27 -0500
> 
> Your allowing someone to mangle an emacs primitive in d54d8a8 for the
> benefit of his "precision" pixel scrolling pet project is inexcusable.
> 
> Yes, that is ad hominem, in the sense that bad code doesn't write itself.

Quite a few people tell me off-list that we should ban you.  So here's
your last chance: either stop your obnoxious conduct and watch your
language and words on this list, or you will have the dubious honor to
be the first person, ever, to be banned from emacs-devel.

Your call.

Re: Motif support

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 16:05:12 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, arthur.miller@live.com, ofv@wanadoo.es
> 
> > > Believe it or not, Emacs is much more reminiscent of a game engine than
> > > a desktop app.
> 
> > I indeed don't believe it.
> 
> Do you say this having used and inspected the source code of multiple
> relatively recent game engines?  If that is the case, an elaboration
> from someone of your experience level would be valuable.

I'm saying this as someone who is familiar with the Emacs display
code.

Re: Motif support

[dick]

I know my banning is an inevitability at this point.

At the same time, emacs has given me something to do in the waning years
of my productive life, and I'll continue to advocate for it in the
strongest possible terms.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 23, 2021, 18:07 by Eli Zaretskii:

>> From: dick:
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 23 Dec 2021 10:01:27 -0500
>>
>> Your allowing someone to mangle an emacs primitive in d54d8a8 for the
>> benefit of his "precision" pixel scrolling pet project is inexcusable.
>>
>> Yes, that is ad hominem, in the sense that bad code doesn't write itself.
>>
>
> Quite a few people tell me off-list that we should ban you.  So here's
> your last chance: either stop your obnoxious conduct and watch your
> language and words on this list, or you will have the dubious honor to
> be the first person, ever, to be banned from emacs-devel.
>
> Your call.
>

Surely it is desirable to have a critical voice, as long as it's grounded in
reality and is reasonably within emacs-devel tone parameters?  What I
would find more disturbing than an aggressive tone is the lack of these
kind of marginal discussions, and you having to be in Atlas' shoes
explaining everything.  I even encountered you at some point on some
obscure package's GitHub page, solving issues for people!  Kudos.

Re: Motif support

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 10:33:40 -0500
> 
> I know my banning is an inevitability at this point.

It isn't.  It depends on how you behave here from this moment onwards.

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I have never looked at that list, but when I see it now, I think
>> several of those listed features are implementable already, as the
>> Emacs is at the moment. I have commented under those that I think are
>> not impossible to implement or are not very hard:
>
> I think that those features are wanted in a complete system, and not as
> individual pieces scattered around in random places such as org-mode
> (which isn't WYSIWYG either.)
They are not in random places; they are in one place, emacs lisp. Org-mode is
not "scattered around", it is a coherent piece of work.

Put it the other way around, thse feature are implemented already in
emacslisp. Any mode can connect them to buttons and use them already.

There were few features on that list that require work, multiple columns are not
straightforward as it is now. Pdf/rtf importers are just labourous, but specs are
freely avialable, anyone could sit and write importer/exporter. I personally
don't think rtf is important and I dislike the pdf for many reasons. I
understand it is popular, but just becasuse something is popular it does not
mean it is good.

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I think I have expressed myself badly here; anyway what I meant, Emacs
>> could use pango and harfbuzz and whatever else it uses on X together
>> with freetype2 to render text on all platforms.
>
> We don't use Pango on X for anything more than converting the output of
> the GTK font selection dialog to a font spec.
>
> HarfBuzz is already used on MS-Windows, and the idea is to eventually
> use it on macOS as well.
>
> As for using FreeType, what benefit would it bring?  Rendering text with
The benefit of using unified platform and not needing to use os built-ins?
This discussion started with someone wanted Emacs to do it's own drawing since
Emacs GUI is relatively simple and does not require full-fledged GUI
toolkit. Freetype would be one tool to achieve this.

>                                                      Rendering text with
> FreeType is not very easy and involves writing a lot of interface code
> for each platform, often more than using the platform's built-in
> interface.  (For simple examples, see the deleted ftx driver, or the
I dont understand what different interfaces are with freetype you are talking
about nor what is difficult with freetype? Freetype gives you platform
independent interface to read, parse and render fonts files to bitmaps. You can
also do your own rendering if you want. Lots of platform independent
applications use Freetype to render fonts.

> It usually involves Fontconfig as well, which doesn't work very well
> non-Unix systems.

Freetype does not need fontconfig. I don't understand why bring fontconfig
here. Fontcnfig uses freetype to read and parse font files, but freetype does
not need fontconfig. 

Anyway, I find this discusion with you immature. You are sitting here and trying
to find anything opposite for the sake of sake of saying opposite. Sorry, all
best to you, I wish you Merry Christmass and all best, but I am out.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 23 Dec 2021 12:53:18 +0100
>> Cc: Madhu <enometh@meer.net>, emacs-devel@gnu.org
>> 
>> Ok. We have all seen how much personal guidance you have needed from
>> Eli on even a minor details to get your offsceen lines working.
>
> That was basically the second time Po Lu implemented something in the
> display engine, and the first time he had to deal with layout code, so
> some guidance should be expected, for a complex piece of software that
> takes more than 40K LOC.  From my POV, the guidance he needed was
> relatively minor; most of the discussion was about the various
> implementation strategies.
Of course guidance is needed and expected. I have no problem with that, I just
reac on him saying it is missinformation to say that Emacs is not so easy to
hack. You say it's complex, he says it's easy :).

And as said, amount of time he seems to have to spend on all kind of different
OS:s, Emacs parts and all different discussion seems to be quite
tremendous. Expecting everyone to have that time is unrealistic. 

But yes of course the guidance is needed for people new to it, and everyone
needs help; I have got help, and everyone else gets help, so it should be of
course. But nobody needs accusation for spreading missinformation when saying
things are complex and could be simpler.

Anyway, good for him if it's easy for him; kudos. Means he can improve Emacs
more, so everyone happy :).

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02409.html
From: Arthur Miller

I seriously suspect that he does this intentionally, to frustrate others
into giving up.  He did mention he is trying to maintain some kind of
status quo, so his reading comprehension is sometimes perfect and
sometimes inexplicable.  If Emacs did it's own drawing, that could be
easy to maintain for anyone who has done reading in introductory
Computer Graphics, and be cross-platform.  However, his "status quo"
requires the "specialty" of gluing together widget libraries for every
differnt platform.  Something stinks here.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: luangruo@yahoo.com,  enometh@meer.net,  emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 18:47:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That was basically the second time Po Lu implemented something in the
> > display engine, and the first time he had to deal with layout code, so
> > some guidance should be expected, for a complex piece of software that
> > takes more than 40K LOC.  From my POV, the guidance he needed was
> > relatively minor; most of the discussion was about the various
> > implementation strategies.
> Of course guidance is needed and expected. I have no problem with that, I just
> reac on him saying it is missinformation to say that Emacs is not so easy to
> hack. You say it's complex, he says it's easy :).

That's not a contradiction, however strange it may sound.  Doing
localized changes is relatively easy even in a complex piece of
software.  The guidance that is needed is just to point to the
relevant functions.

> And as said, amount of time he seems to have to spend on all kind of different
> OS:s, Emacs parts and all different discussion seems to be quite
> tremendous. Expecting everyone to have that time is unrealistic. 

The time you need for a change depends on how simple or complex the
change is.  Not everyone is expected to make significant changes,
there's a lot of place for relatively simple ones.

> But yes of course the guidance is needed for people new to it, and everyone
> needs help; I have got help, and everyone else gets help, so it should be of
> course. But nobody needs accusation for spreading missinformation when saying
> things are complex and could be simpler.

Accusations aside, I think your impression of the Emacs code being an
impenetrable undocumented mess is way too extreme.

Re: Motif support

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 19:05:37 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, ofv@wanadoo.es, eliz@gnu.org, luangruo@yahoo.com
> 
> I seriously suspect that he does this intentionally, to frustrate others
> into giving up.

Please don't assume others here post not in good faith, it's unkind
and unfair.

> If Emacs did it's own drawing, that could be easy to maintain for
> anyone who has done reading in introductory Computer Graphics, and
> be cross-platform.

That is an exaggeration at best.  If you already studied the Emacs
display code, and that is your conclusion, then we are probably
reading two very different codebases, because I think an introductory
CG textbook is way insufficient for implementing anything close to the
Emacs display subsystem.  If you didn't yet study the code, I suggest
you do, and maybe you will then judge what Po Lu says less harshly.

Re: Motif support

[dick]

EZ> because I think an introductory CG textbook is way insufficient for implementing
EZ> anything close to the Emacs display subsystem.

I don't know whether to laugh or cry.

And now for my own bit of Po Lu-style grandstanding, I'll claim to be
the global authority on the display code, having largely rewritten it to
handle long lines.

If you can convert a two dimensional array into a single-dimensional
vector (something within reach of most first-year undergraduates), you
can understand the display code.  The hard part is brushing past the
obfuscative hacks, which is more than 50% of the code.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02423.htmlFrom: Eli Zaretskii

> Please don't assume others here post not in good faith, it's unkind
> and unfair.

Apologies. I accept, but so is what Arthur Miller or I have been subjected
to by some of Po Lu's replies.

> That is an exaggeration at best. If you already studied the Emacs
> display code, and that is your conclusion, then we are probably
> reading two very different codebases, because I think an introductory
> CG textbook is way insufficient for implementing anything close to the
> Emacs display subsystem. If you didn't yet study the code, I suggest
> you do, and maybe you will then judge what Po Lu says less harshly.

May I request file/line pointer to a function where such an advanced
domain algorithm is implemented?  Those then don't apply to what
I argued but I doubt they are a large percentage in terms of LOC.
Or better yet, request where one is delegated to one those libraries?
(Except text rendering, which I didn't suggest Emacs should do all
by itself.)

Re: Motif support

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 13:57:28 -0500
> 
> EZ> because I think an introductory CG textbook is way insufficient for implementing
> EZ> anything close to the Emacs display subsystem.
> 
> I don't know whether to laugh or cry.
> 
> And now for my own bit of Po Lu-style grandstanding

OK, that's it: since all the warnings didn't help, and you continue
misbehaving in the same obnoxious ways, you are now banned from this
list.

Congratulations.

Re: Motif support

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 20:04:36 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, arthur.miller@live.com, luangruo@yahoo.com,
> 	ofv@wanadoo.es
> 
> > That is an exaggeration at best. If you already studied the Emacs
> > display code, and that is your conclusion, then we are probably
> > reading two very different codebases, because I think an introductory
> > CG textbook is way insufficient for implementing anything close to the
> > Emacs display subsystem. If you didn't yet study the code, I suggest
> > you do, and maybe you will then judge what Po Lu says less harshly.
> 
> May I request file/line pointer to a function where such an advanced
> domain algorithm is implemented?

Most low-level display-related code for X is in xterm.c and xfns.c.

> Or better yet, request where one is delegated to one those libraries?

Xlib calls are all over the place in those two files.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 23 Dec 2021 19:05:37 +0100 (CET)
>> From: xenodasein@tutanota.de
>> Cc: emacs-devel@gnu.org, ofv@wanadoo.es, eliz@gnu.org, luangruo@yahoo.com
>> 
>> I seriously suspect that he does this intentionally, to frustrate others
>> into giving up.
>
> Please don't assume others here post not in good faith, it's unkind
> and unfair.

That was my thought too, and that is why I didn't want to answer on that one. I
felt him syaing that, was admitting to trolling so I didn't want to continue
more there. The "todo list" was another such place as well as freetype
discussion. He is probably a good chap, but I find him immature. I would expect
that kind of conducting disussion on reddit not here. About the good faith he is
not shy of accusing others, so don't what to say you there.

Anyway, I do this for my own recreation and because I find solving problems
and experimenting with Emacs fun. That is my own free time and escape from
stress, so I don't poiseness discussions and crap from neither some Po or Schwab
or anyone else, so thank for you patience with me, and time, and of course the
help I got from you and others on this list. 

I do sicncerely with Merry Christmass and Happy New Year to you all.

Best wishes

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: luangruo@yahoo.com,  enometh@meer.net,  emacs-devel@gnu.org
>> Date: Thu, 23 Dec 2021 18:47:09 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > That was basically the second time Po Lu implemented something in the
>> > display engine, and the first time he had to deal with layout code, so
>> > some guidance should be expected, for a complex piece of software that
>> > takes more than 40K LOC.  From my POV, the guidance he needed was
>> > relatively minor; most of the discussion was about the various
>> > implementation strategies.
>> Of course guidance is needed and expected. I have no problem with that, I just
>> reac on him saying it is missinformation to say that Emacs is not so easy to
>> hack. You say it's complex, he says it's easy :).
>
> That's not a contradiction, however strange it may sound.  Doing
> localized changes is relatively easy even in a complex piece of
> software.  The guidance that is needed is just to point to the
> relevant functions.
>
>> And as said, amount of time he seems to have to spend on all kind of different
>> OS:s, Emacs parts and all different discussion seems to be quite
>> tremendous. Expecting everyone to have that time is unrealistic. 
>
> The time you need for a change depends on how simple or complex the
> change is.  Not everyone is expected to make significant changes,
> there's a lot of place for relatively simple ones.
>
>> But yes of course the guidance is needed for people new to it, and everyone
>> needs help; I have got help, and everyone else gets help, so it should be of
>> course. But nobody needs accusation for spreading missinformation when saying
>> things are complex and could be simpler.
>
> Accusations aside, I think your impression of the Emacs code being an
> impenetrable undocumented mess is way too extreme.

I didn't say it is "impentrenable undocumented mess", I said it could be
nicer. I also said it has got much better in later years, but 10k sloc files
with lots of if-defs are not very nice.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> The benefit of using unified platform and not needing to use os
> built-ins?  This discussion started with someone wanted Emacs to do
> it's own drawing since Emacs GUI is relatively simple and does not
> require full-fledged GUI toolkit. Freetype would be one tool to
> achieve this.

That benefit is hardly established.

> I dont understand what different interfaces are with freetype you are
> talking about nor what is difficult with freetype? Freetype gives you
> platform independent interface to read, parse and render fonts files
> to bitmaps. You can also do your own rendering if you want. Lots of
> platform independent applications use Freetype to render fonts.

What about locating the font files to open? Scaling glyphs, which is
usually the job of the platform, and essentially required for color
Emoji? What about displaying the resulting bitmap, or decomposed glyph
outline?

All those tasks need platform-dependent code, and about the same amount
as supporting the native font rasterizer.

> Freetype does not need fontconfig. I don't understand why bring
> fontconfig here. Fontcnfig uses freetype to read and parse font files,
> but freetype does not need fontconfig.

Then take a look at ftfont.c, the "abstract" FreeType font driver,
unless you're saying we should also reinvent the (platform-specific)
code to detect and use installed fonts?

Re: Motif support

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Most low-level display-related code for X is in xterm.c and xfns.c.

There are also the three font drivers we use on X: ftcrfont.c, xftfont.c
and xfont.c.

Thanks.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Anyway, I find this discusion with you immature. You are sitting here
> and trying to find anything opposite for the sake of sake of saying
> opposite. Sorry, all best to you, I wish you Merry Christmass and all
> best, but I am out.

Merry Christmas.

You'll notice that I was not trying to find "anything opposite", but
mostly sticking to the same points, which a cursory inspection of the
existing FreeType-based font drivers (and also why it's "drivers" and
not "driver") will confirm.

Thanks.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 03:38 by luangruo@yahoo.com:

> That benefit is hardly established.
>

We could establish deeper, but any developer who worked
on both traditional desktop apps or graphical apps with their
own rendering like "games" will tell you same things.


> What about locating the font files to open? Scaling glyphs, which is
> usually the job of the platform, and essentially required for color
> Emoji? What about displaying the resulting bitmap, or decomposed glyph
> outline?
>
> All those tasks need platform-dependent code, and about the same amount
> as supporting the native font rasterizer.
>
> Then take a look at ftfont.c, the "abstract" FreeType font driver,
> unless you're saying we should also reinvent the (platform-specific)
> code to detect and use installed fonts?
>

You kinda have to use platform dependent features directly, as we
are not programming into aether.  However, painting menus isn't one.
You don't need a third-party solution, whether it is from platform itself
like legacy win32 GUI elements or another library.  Using them is like
using a sledgehammer to drive a nail in Emacs' case. We could even do
the text rendering itself too, provided an expert would contribute it to
Emacs.  But no one said let's do text rendering, AFAIK.

Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> You kinda have to use platform dependent features directly, as we are
> not programming into aether. However, painting menus isn't one.  You
> don't need a third-party solution, whether it is from platform itself
> like legacy win32 GUI elements or another library. Using them is like
> using a sledgehammer to drive a nail in Emacs' case. We could even do
> the text rendering itself too, provided an expert would contribute it
> to Emacs.

That is simply untrue.  Besides, people _want_ the platform specific
widgets, or otherwise we'd just be porting oldXMenu everywhere.

> But no one said let's do text rendering, AFAIK.

That's what Authur said about FreeType.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 04:24 by luangruo@yahoo.com:

> That is simply untrue.  Besides, people _want_ the platform specific
> widgets, or otherwise we'd just be porting oldXMenu everywhere.
>

I agree those should remain as long as there is demand and someone
who knows how to maintain them, just like text interface still works
despite being the less popular choice.

Re: Motif support

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> That is simply untrue.  Besides, people _want_ the platform specific
> widgets,

Do they?  VSCode is pretty popular, and their users don't seem to care
about that at all.

FWIW, I think it would be highly preferable if Emacs could look and
behave the same across all platforms.

Re: Motif support

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Do they?  VSCode is pretty popular, and their users don't seem to care
> about that at all.

I don't know about VS Code, but IntelliJ IDEA has the same decoration
style everywhere, and many people at work seem to complain about that.

RE: [External] : Re: Motif support

[Drew Adams]

> FWIW, I think it would be highly preferable if Emacs
> could look and behave the same across all platforms.

OK, why do you think that would be highly preferable?

Could, or must?  If there were an option that enabled
that, that would be one thing.  Making that happen as
the only choice would be something else.

How similar are you aiming for?  And would that be by
limiting what's possible on some platforms (lowest
common denominator)?

RE: [External] : Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 05:59 by drew.adams@oracle.com:

>> FWIW, I think it would be highly preferable if Emacs
>> could look and behave the same across all platforms.
>>
>
> OK, why do you think that would be highly preferable?
>
> Could, or must?  If there were an option that enabled
> that, that would be one thing.  Making that happen as
> the only choice would be something else.
>
> How similar are you aiming for?  And would that be by
> limiting what's possible on some platforms (lowest
> common denominator)?
>

Damn, I wasn't planning to work on a renderer for Emacs
when I decided get active. :)  It would essentially be a
"Third Way."  Whereas currently there is two, it would be
"Emacs the Terminal", "Emacs the Gedit" and "Emacs the ?"
First runs even without X, second is we are used to.  They
don't necessarily hinder each other.

Re: [External] : Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> "Emacs the ?"  First runs even without X, second is we are used to. 
> They don't necessarily hinder each other.

In other words, you want a build of Emacs with `--with-x-toolkit=no'?
Where the menu bar, tool bar, and scroll bar are all displayed by Emacs
itself?

That already exists.

Re: [External] : Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 06:26 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> "Emacs the ?"  First runs even without X, second is we are used to. 
>> They don't necessarily hinder each other.
>>
>
> In other words, you want a build of Emacs with `--with-x-toolkit=no'?
> Where the menu bar, tool bar, and scroll bar are all displayed by Emacs
> itself?
>
> That already exists.
>

This lack of imagination is disheartening.

Platform independent graphical display for Emacs

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> FWIW, I think it would be highly preferable if Emacs
>> could look and behave the same across all platforms.
>
> OK, why do you think that would be highly preferable?

I don't think that what we do necessarily translates very well to the
widgets provided by common toolkits.  For example, the mode line is not
rendered by a toolkit.

OTOH, I can see plenty of benefits with doing things ourselves.

With regards to tooltips, in VSCode they can also include links to
relevant actions.  I don't think we can currently do that (or e.g. use
faces and have them work).

Dialogs are basically not very useful or Emacsy as is.  When they pop
up, you are completely outside of "Emacs land", and there is no way for
us to add keybindings, style them, etc. or do much of anything really.

Our scrollbars are fairly subpar compared to the ones in VSCode, at
least in GTK.  Admittedly that might be to some extent because it is
hard to style them from Lisp themes (I guess that's not currently
possible).

There is a similar story with the tab bar, tab line and toolbar.

Then we have things like the posframe package, where the minibuffer pops
up on top of the current buffers.  That currently works with a hack (a
separate frame) but we could imagine having our own widget for that.
IMO, we would ideally want that to look the same across platforms.

I think there are many more things that we could do if we wanted to.
You can fire up an editor made by the competition and see what they do
for more ideas.

That said, all of this would obviously be a lot of work and until and
unless someone starts such work this is all rather academic.

> How similar are you aiming for?

No idea.  I guess the menus would be different on macOS.

> And would that be by limiting what's possible on some platforms
> (lowest common denominator)?

I don't think it would necessarily imply that, no.

Re: Platform independent graphical display for Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I don't think that what we do necessarily translates very well to the
> widgets provided by common toolkits.  For example, the mode line is
> not rendered by a toolkit.

That's because it's part of an Emacs window, not a widget.

> Dialogs are basically not very useful or Emacsy as is.  When they pop
> up, you are completely outside of "Emacs land", and there is no way for
> us to add keybindings, style them, etc. or do much of anything really.

Just as in gedit and other graphical editors, no?

> Our scrollbars are fairly subpar compared to the ones in VSCode, at
> least in GTK.  Admittedly that might be to some extent because it is
> hard to style them from Lisp themes (I guess that's not currently
> possible).

The built-in (as in, no toolkit) scrollbar is even worse, though can be
styled via some X resources.

> There is a similar story with the tab bar, tab line and toolbar.

The tool bar is displayed by Emacs itself on all platforms except GTK
and NS, and the tab line and tab bar are always displayed by Emacs
itself.

> Then we have things like the posframe package, where the minibuffer pops
> up on top of the current buffers.  That currently works with a hack (a
> separate frame) but we could imagine having our own widget for that.
> IMO, we would ideally want that to look the same across platforms.

Child frames basically look the same regardless of platform, as long as
window decorations are turned off (if they are on, again, that's outside
our control).  They are even implemented the same way widgets are on X,
via an X window with a parent, so I don't really see the difference.

> No idea.  I guess the menus would be different on macOS.

NS users will complain.  Besides, I find the global menu bar concept
rather nice from my limited usage of GNUstep, and I hope more programs
will grow to support such behaviour.

It is certainly better than the fat-finger-button-hamburger-menu GNOME
people want these days.

RE: [External] : Platform independent graphical display for Emacs

[Drew Adams]

> >> FWIW, I think it would be highly preferable if Emacs
> >> could look and behave the same across all platforms.
> >
> > OK, why do you think that would be highly preferable?
> 
> I don't think that what we do necessarily translates very well to the
> widgets provided by common toolkits.  For example, the mode line is not
> rendered by a toolkit.  OTOH, I can see plenty of benefits with doing
> things ourselves.

I see that you changed the topic (and the Subject line).
OK.

What you had said was that it's preferable for Emacs to
have the same look & feel across all platforms.  That's
what I responded to, with questions about that.

Now you're talking about the question of Emacs itself
implementing things, instead of relying on toolkits
etc.  That's not the same proposal/question.

Assuming Emacs dev provided everything, without relying
on toolkits etc. provided by/for particular platforms
etc., why would it be highly preferable for Emacs to
provide only one look and behavior across all platforms?

I ask about "only one", because, as I said, _allowing_
for the same everywhere is one thing.  _Not allowing_
for any differences is a different thing.

If the aim is to limit Emacs behavior to be only what
can be made available to all platforms (lowest common
denominator), then I think that would be unfortunate
(too limiting, for no particular gain).

IIUC, one explicit aim is to have GNU/Linux be the
most feature-full, out of the box.  Emacs doesn't
pursue development that's only for MS Windows, for
example.  But nothing currently limits Emacs to
providing only behavior that works on all platforms.
___

As for what you're talking about now: I don't have
a problem with that.  If Emacs develops improved
tooltips, dialog boxes, menus, or whatever, so much
the better.  I'm assuming that there's no policy
road-block in the way of that, and that all that's
perhaps lacking is enough volunteer energy.

Re: Platform independent graphical display for Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I don't think that what we do necessarily translates very well to the
>> widgets provided by common toolkits.  For example, the mode line is
>> not rendered by a toolkit.
>
> That's because it's part of an Emacs window, not a widget.

Yes.  I was under the impression that this was well understood, and
didn't need pointing out.

>> Dialogs are basically not very useful or Emacsy as is.  When they pop
>> up, you are completely outside of "Emacs land", and there is no way for
>> us to add keybindings, style them, etc. or do much of anything really.
>
> Just as in gedit and other graphical editors, no?

Yes, but I expect more from Emacs than from other editors.

>> Our scrollbars are fairly subpar compared to the ones in VSCode, at
>> least in GTK.
>
> The built-in (as in, no toolkit) scrollbar is even worse,

That's true, but to be clear I am not talking about that build.

> Child frames basically look the same regardless of platform, as long as
> window decorations are turned off (if they are on, again, that's outside
> our control).  They are even implemented the same way widgets are on X,
> via an X window with a parent, so I don't really see the difference.

I don't really understand your argument here; I see a significant
difference between widgets and frames.

>> No idea.  I guess the menus would be different on macOS.
>
> NS users will complain.

I meant that the menus would likely be global on macOS.  I think you
will agree that they would not complain about that.

Re: Platform independent graphical display for Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Yes, but I expect more from Emacs than from other editors.

How about we extend the existing menus to do whatever couldn't be done
before, which presumably compelled you to ask this question?

> I don't really understand your argument here; I see a significant
> difference between widgets and frames.

If we implemented some kind of popup widget, it would probably be
implemented similarly to child frames.

> I meant that the menus would likely be global on macOS.  I think you
> will agree that they would not complain about that.

I'm fine by that then, but that means we won't be able to draw the menus
ourselves (it is actually not possible under NS).

Thanks.

Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 02:17:32 +0100 (CET)
> Cc: emacs-devel@gnu.org
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> You kinda have to use platform dependent features directly, as we
> are not programming into aether.  However, painting menus isn't one.
> You don't need a third-party solution, whether it is from platform itself
> like legacy win32 GUI elements or another library.  Using them is like
> using a sledgehammer to drive a nail in Emacs' case. We could even do
> the text rendering itself too, provided an expert would contribute it to
> Emacs.  But no one said let's do text rendering, AFAIK.

But we already have all that -- that's the X build without any
toolkits.  Almost no one uses it, because any toolkit version looks
much nicer, so we can conclude today what would be the result of your
suggestions.  Producing a good-looking GUI application is a lot of
low-level work, and suggesting that we do all or most of that "by
hand" is really a non-starter.

Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 02:37:32 +0100 (CET)
> Cc: emacs-devel@gnu.org
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> text interface still works despite being the less popular choice.

I invite you to read the Emacs Reddit for some time, where you will
learn that quite a few people use the text-mode UI _by_choice_.  It's
quite popular.

Re: [External] : Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 04:36:31 +0100 (CET)
> Cc: emacs-devel@gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>  Drew Adams <drew.adams@oracle.com>
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> > In other words, you want a build of Emacs with `--with-x-toolkit=no'?
> > Where the menu bar, tool bar, and scroll bar are all displayed by Emacs
> > itself?
> >
> > That already exists.
> >
> 
> This lack of imagination is disheartening.

Perhaps you haven't explained yourself well enough for us to imagine
that.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 23 Dec 2021 20:30:42 -0800
> 
> With regards to tooltips, in VSCode they can also include links to
> relevant actions.  I don't think we can currently do that (or e.g. use
> faces and have them work).

In toolkit-provided tooltips, we don't.  But Emacs has its own native
tooltips, where everything that works in a "normal" frame can work in
a tooltip.

> That said, all of this would obviously be a lot of work and until and
> unless someone starts such work this is all rather academic.

Not only that, I'd hesitate to accept such a contribution, because its
long-term maintenance would most probably be a constant burden, and if
the person(s) who develop such a "native" toolkit go on to greener
pastures, we will be left with an unmaintained subsystem.

So I don't think it is a good idea for Emacs to develop its own
toolkit.  We should use what's out there.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 10:24 by eliz@gnu.org:

>> Date: Fri, 24 Dec 2021 02:37:32 +0100 (CET)
>> Cc: emacs-devel@gnu.org
>> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
>> text interface still works despite being the less popular choice.
>>
>
> I invite you to read the Emacs Reddit for some time, where you will
> learn that quite a few people use the text-mode UI _by_choice_.  It's
> quite popular.
>

I know, I am one of them, and I mentioned it several times.
Emacs' text interface is less popular than it's GUI.
Is previous statement false?  That is what I said there.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02518.html
From: Eli Zaretskii

> Not only that, I'd hesitate to accept such a contribution, because its
> long-term maintenance would most probably be a constant burden, and if
> the person(s) who develop such a "native" toolkit go on to greener
> pastures, we will be left with an unmaintained subsystem.
>
> So I don't think it is a good idea for Emacs to develop its own
> toolkit.  We should use what's out there.
>

Please take a look, and try to understand my frustration.

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02034.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02517.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02515.html

It would be nice to mention this before sending me on my way to
waste time.  I should have suspected you were going to do that
but I regrettably have taken the course of assuming good faith first.

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02221.html

Also very relevant:

https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00885.html

Re: Motif support

[Stefan Kangas]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Emacs' text interface is less popular than it's GUI.
> Is previous statement false?  That is what I said there.

Among the respondents in the Emacs Survey last year, 91.5 % used
graphical Emacs, and 31.9 % used it in the terminal.

    https://emacssurvey.org/2020/

Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 09:06:21 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> Dec 24, 2021, 10:24 by eliz@gnu.org:
> 
> >> Date: Fri, 24 Dec 2021 02:37:32 +0100 (CET)
> >> Cc: emacs-devel@gnu.org
> >> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> >> text interface still works despite being the less popular choice.
> >>
> >
> > I invite you to read the Emacs Reddit for some time, where you will
> > learn that quite a few people use the text-mode UI _by_choice_.  It's
> > quite popular.
> >
> 
> I know, I am one of them, and I mentioned it several times.
> Emacs' text interface is less popular than it's GUI.
> Is previous statement false?

It isn't clear to me whether it is true or false.  The text-mode UI is
popular enough to not make any assumptions here.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 09:10:20 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, drew.adams@oracle.com,
> 	rms@gnu.org
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02518.html
> From: Eli Zaretskii
> 
> > Not only that, I'd hesitate to accept such a contribution, because its
> > long-term maintenance would most probably be a constant burden, and if
> > the person(s) who develop such a "native" toolkit go on to greener
> > pastures, we will be left with an unmaintained subsystem.
> >
> > So I don't think it is a good idea for Emacs to develop its own
> > toolkit.  We should use what's out there.
> >
> 
> Please take a look, and try to understand my frustration.

I apologize for causing frustration, but if that was what you meant
from the beginning, it was (and still is) hard for me to understand
that this is the way you intend to go.  It is a misunderstanding, and
I apologize for my part of it.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 11:41 by eliz@gnu.org:

> I apologize for causing frustration, but if that was what you meant
> from the beginning, it was (and still is) hard for me to understand
> that this is the way you intend to go.  It is a misunderstanding, and
> I apologize for my part of it.
>

I gladly accept it, I also apologize because I am also aware
that I am neither a clear nor a refined mailer.

Also I feel like there is a case to be made there somewhere,
about perils of mail driven development, but I don't want
to force my luck. :)

Cheers.

Re: Platform independent graphical display for Emacs

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Dialogs are basically not very useful or Emacsy as is.  When they pop
> up, you are completely outside of "Emacs land", and there is no way for
> us to add keybindings, style them, etc. or do much of anything really.

Yeah, it's annoying.

> Our scrollbars are fairly subpar compared to the ones in VSCode, at
> least in GTK.  Admittedly that might be to some extent because it is
> hard to style them from Lisp themes (I guess that's not currently
> possible).

It's popular to switch them off, though.  😀

> That said, all of this would obviously be a lot of work and until and
> unless someone starts such work this is all rather academic.

There's definitely different cultures surrounding the toolkit issue.
Some people want all their applications on the OS they use to look the
same, and some people want the application they use to look the same on
all OS-es.  I think the astounding success of VSCode points to the first
group of people putting up with it if they have to, but there's a lot of
grumbling.

Anyway, this inspired me to have a look at the no-toolkit build of Emacs
for the first time in years, and...  it's a bit rough.  There's no HiDPI
support, apparently, so all the icons/menus look unusably tiny on this
screen.  And the scroll bar apparently works the same as an xterm in
1989?  That is, left/right mouse clicks goes down/up, and you can't drag
it at all.

So it's no wonder that few people are using that.  But if want to cater
more to people that want Emacs to look the same on all operating
systems, there's at least a base to start working from, because it seems
to work fine otherwise.

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

Re: Platform independent graphical display for Emacs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And the scroll bar apparently works the same as an xterm in 1989?
> That is, left/right mouse clicks goes down/up, and you can't drag it
> at all.

You can drag it with mouse-2, just like in xterm -- in fact, it's
actually derived from the exact same scrollbar code that xterm used.

Re: Platform independent graphical display for Emacs

[Stephen Berman]

On Fri, 24 Dec 2021 10:55:03 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> There's definitely different cultures surrounding the toolkit issue.
> Some people want all their applications on the OS they use to look the
> same, and some people want the application they use to look the same on
> all OS-es.  I think the astounding success of VSCode points to the first
> group of people putting up with it if they have to, but there's a lot of
> grumbling.
>
> Anyway, this inspired me to have a look at the no-toolkit build of Emacs
> for the first time in years, and...  it's a bit rough.  There's no HiDPI
> support, apparently, so all the icons/menus look unusably tiny on this
> screen.  And the scroll bar apparently works the same as an xterm in
> 1989?  That is, left/right mouse clicks goes down/up, and you can't drag
> it at all.
>
> So it's no wonder that few people are using that.  But if want to cater
> more to people that want Emacs to look the same on all operating
> systems, there's at least a base to start working from, because it seems
> to work fine otherwise.

Perhaps the main issue keeping me from regularly using the no-toolkit
build is the inability to navigate menu-bar menus and select entries
from them with the keyboard (I disable the menu bar but not infrequently
pop up the global menu with F10).  If I had enough knowledge and time,
this would be one of the first things I would fix.

Steve Berman

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Ideally, in its final form this new system should reminiscent a simple
browser that runs Elisp instead of JS, with some level of drawing
capability.  It's functions will not be terminal compatible. It should
exist side-by-side with legacy (current) toolkit based GUI which is
already interoperable with text interface, for the foreseeable future.
(Text terminal will of course be forever.) Then there is the question
of which one is the default.

Or it could just be a toolkit=no on steroids.  Very open to discussion.

It could start developing as the latter, in time evolving into the
former, or we could design it as a completely new GUI from beginning.
This is also about reducing non-gnu linked libraries to a minimum and
reinventing relatively easy to reinvent things inside Emacs. As long
as it reduces maintenance burden compared to linking with something,
reducing the damage to Emacs to minimum from things like X/Wayland
split, or GNOME mess.

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> As long as it reduces maintenance burden compared to linking with
> something, reducing the damage to Emacs to minimum from things like
> X/Wayland split, or GNOME mess.

It will mean we will have to deal with Wayland directly, which is much,
much more complicated than letting GTK do it for us.

That's not the case with X, but it is for Wayland.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 14:07 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> As long as it reduces maintenance burden compared to linking with
>> something, reducing the damage to Emacs to minimum from things like
>> X/Wayland split, or GNOME mess.
>>
>
> It will mean we will have to deal with Wayland directly, which is much,
> much more complicated than letting GTK do it for us.
>
> That's not the case with X, but it is for Wayland.
>

Something to consider.  I forgot to emphasis being cross-platform,
would it play well?

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Something to consider.  I forgot to emphasis being cross-platform,
> would it play well?

What do you mean by "it" here?

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 14:31 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Something to consider.  I forgot to emphasis being cross-platform,
>> would it play well?
>>
>
> What do you mean by "it" here?
>

GTK.  It looked intrusive to me, while making things easier on Wayland
would it also make things harder on other places?  Especially if it is
not available.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But if want to cater
> more to people that want Emacs to look the same on all operating
> systems, there's at least a base to start working from, because it seems
> to work fine otherwise.

I don't use the platform's dialogs (they are a joke compared to what
Emacs provides) and can switch from Emacs-lucid on GNU/Linux to Emacs on
MS-Windows without perceptible psychic trauma. Well, actually, without
noticing.

About those people wanting Emacs to look "platform-native" (1):

If a new display backend makes possible new features which enhances
productivity (or even just aesthetics) it is reasonable to expect that
some of them will accept the change as a good trade-off. Furthermore, it
hopefully will attract new users which will provide an even stronger
stream of complaints on future changes.

And you can't keep everyone happy all the time. We all know that the
slightest change on Emacs upsets someone, somewhere. This would be a
reason to stop development. But then the absence of change on Emacs also
upsets other people, so... you can't keep everyone happy all the time.

1: What is "platform-native" varies with each new major release of GTK
   and Windows.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 24 Dec 2021 10:55:03 +0100
> Cc: Po Lu <luangruo@yahoo.com>, Drew Adams <drew.adams@oracle.com>,
>  "xenodasein--- via Emacs development discussions." <emacs-devel@gnu.org>
> 
> Anyway, this inspired me to have a look at the no-toolkit build of Emacs
> for the first time in years, and...  it's a bit rough.  There's no HiDPI
> support, apparently, so all the icons/menus look unusably tiny on this
> screen.  And the scroll bar apparently works the same as an xterm in
> 1989?  That is, left/right mouse clicks goes down/up, and you can't drag
> it at all.

That's no surprise: no one develops that configuration since it
exists.  So it's a kind-of vicious circle: this configuration doesn't
get any love because no one likes it, and no one likes it because it
doesn't get any love.

> So it's no wonder that few people are using that.  But if want to cater
> more to people that want Emacs to look the same on all operating
> systems, there's at least a base to start working from, because it seems
> to work fine otherwise.

Please note that the code still is full of Xlib calls, so making it
work on other systems will not be trivial.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 24 Dec 2021 12:45:56 +0100
> 
> 1: What is "platform-native" varies with each new major release of GTK
>    and Windows.

But it changes for all the GUI applications, not just for Emacs.

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> GTK. It looked intrusive to me, while making things easier on Wayland
> would it also make things harder on other places? Especially if it is
> not available.

We don't use GTK where it's not available, and use of GTK will always
stay optional, so I don't understand what you're trying to say.

Anyway, using GTK for Wayland support doesn't affect what we do
elsewhere.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 15:08 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> GTK. It looked intrusive to me, while making things easier on Wayland
>> would it also make things harder on other places? Especially if it is
>> not available.
>>
>
> We don't use GTK where it's not available, and use of GTK will always
> stay optional, so I don't understand what you're trying to say.
>
Optional?  What I understood from you that it would be the only
connection between Emacs and Wayland in the new system, to avoid
dealing with the Wayland directly.

> Anyway, using GTK for Wayland support doesn't affect what we do
> elsewhere.
>
Surely intrusive, event-driven libs like GTK necessitate changes in our
code, which are otherwise unnecessary complexity elsewhere, when
GTK isn't even used?

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Optional?  What I understood from you that it would be the only
> connection between Emacs and Wayland in the new system, to avoid
> dealing with the Wayland directly.

Yes, but we will not run only on Wayland.  Besides, I wasn't talking
about a "new system", I was referring to what we have now as the PGTK
port.

> Surely intrusive, event-driven libs like GTK necessitate changes in
> our code, which are otherwise unnecessary complexity elsewhere, when
> GTK isn't even used?

Being "event-driven" is hardly why GTK is problematic.  A small file
named xgselect.c takes care of the GLib event loop with some clever
code, so we don't have to worry about it anywhere else.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 15:27 by luangruo@yahoo.com:

>> Surely intrusive, event-driven libs like GTK necessitate changes in
>> our code, which are otherwise unnecessary complexity elsewhere, when
>> GTK isn't even used?
>>
>
> Being "event-driven" is hardly why GTK is problematic.  A small file
> named xgselect.c takes care of the GLib event loop with some clever
> code, so we don't have to worry about it anywhere else.
>

I grepped a bit, and there many conditional modifications to frame
related functions through #ifdef USE_GTK.  This doesn't bode well for
a cross-platform frame logic, IMO.  Is this what you referred to as
problematic?

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I grepped a bit, and there many conditional modifications to frame
> related functions through #ifdef USE_GTK.  This doesn't bode well for
> a cross-platform frame logic, IMO.  Is this what you referred to as
> problematic?

That's only the tip of the iceberg, but is completely unrelated to event
handling, where the relevant conditional is `HAVE_GLIB'.

The problem could be easily resolved if the GTK+ developers actually
paid attention to our reasonable requests, but they refuse to do so
because Emacs is, in their opinion, not a well-behaved program.

Case in point: the nearly 20-year old GTK bug where GTK aborts when a
display is closed.  We used to longjmp out, but that used to cause GLib
to emit a large amount of warnings, so that workaround was turned off,
and doesn't work nowadays either.

Another case in point: try resizing or creating a frame on a GTK build
that is smaller than its menu bar, see what GTK does to it, and compare
that behaviour (which cannot be turned off, at least when I tried) to
the behaviour under an Xt or no-toolkit build.

Then of course, there are the many other instances where the GTK
developers refused to implement a basic feature, such as the ability to
adjust the thumb size of a scrollbar, because they did not think it fit
with their idea of how a program should behave appearance-wise.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1: What is "platform-native" varies with each new major release of GTK
>>    and Windows.
>
> But it changes for all the GUI applications, not just for Emacs.

Which means that they value consistency with other applications that
follow the platform standard.

However, Emacs is already largely deviant from the platform's UI. On
MS-Windows, things like customize-variable shows an interface which has
nothing to do with the platform's standard GUI widgets. It seems that
the only elements which are "native" in the MS-Windows port are the menu
and the dialogs.

If we add to that that Emacs has its own way of doing things (M-x
command system, interaction through the minibuffer instead of dialogs,
different keyboard shorcuts for standard actions like cut&paste, etc.)
we could conclude that Emacs already is very alien to
MS-Windows/GTK/MacOS UI standards.

So I can hardly imagine a typical Emacs user that could make a big issue
about the menus or dialogs being a bit different from what his
platform's standard ones are, as long as the replacement is not ugly
("ugly" in the sense the motif menu is ugly compared to Lucid and GTK.)

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> So I can hardly imagine a typical Emacs user that could make a big
> issue about the menus or dialogs being a bit different from what his
> platform's standard ones are, as long as the replacement is not ugly
> ("ugly" in the sense the motif menu is ugly compared to Lucid and
> GTK.)

The Lucid menu was mostly designed after the Motif menu.  They also look
mostly identical.  Anyway, the reason support for those toolkits was
added is that people care for them, and that's also why nobody uses the
no-toolkit build anymore.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 24 Dec 2021 14:19:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1: What is "platform-native" varies with each new major release of GTK
> >>    and Windows.
> >
> > But it changes for all the GUI applications, not just for Emacs.
> 
> Which means that they value consistency with other applications that
> follow the platform standard.
> 
> However, Emacs is already largely deviant from the platform's UI. On
> MS-Windows, things like customize-variable shows an interface which has
> nothing to do with the platform's standard GUI widgets.

Isn't that so on other platforms as well?  Wherever Emacs invented its
own UI, that UI and its widgets will always be different from the
platform standards.

> It seems that the only elements which are "native" in the MS-Windows
> port are the menu and the dialogs.

And the scroll bars.  And the frame decorations.

Is that different from other toolkits?  OK, so with GTK we also use
their tool bar and tooltips (and get to live with their limitations),
but other than that?

> If we add to that that Emacs has its own way of doing things (M-x
> command system, interaction through the minibuffer instead of dialogs,
> different keyboard shorcuts for standard actions like cut&paste, etc.)
> we could conclude that Emacs already is very alien to
> MS-Windows/GTK/MacOS UI standards.

That's an exaggeration.

> So I can hardly imagine a typical Emacs user that could make a big issue
> about the menus or dialogs being a bit different from what his
> platform's standard ones are, as long as the replacement is not ugly
> ("ugly" in the sense the motif menu is ugly compared to Lucid and GTK.)

That's an "ad absurdum" kind of argument.

In general, Emacs does do some (quite a few) thing differently, and
where it does, it does so uniformly on all platforms, more or less (I
think NS is the largest outlier here, with its Cmd key).  But this is
a tangent: we weren't discussing the entire UI and its conventions, we
only discussed the GUI aspects of the Emacs appearance.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So I can hardly imagine a typical Emacs user that could make a big
>> issue about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and
>> GTK.)
>
> The Lucid menu was mostly designed after the Motif menu.  They also look
> mostly identical.

No, the Lucid menu here shows a nice, modern font, while the Motif menu
shows some pixelated thing from the eighties.

> Anyway, the reason support for those toolkits was
> added is that people care for them,

I'm sure that at some point the motif port was appreciated as an
improvement. I tried it when you reinstated the configure option, and it
was like going back 30 years. I saw no reason to prefer it to what I use
(Lucid), quite the contrary.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> However, Emacs is already largely deviant from the platform's UI. On
>> MS-Windows, things like customize-variable shows an interface which has
>> nothing to do with the platform's standard GUI widgets.
>
> Isn't that so on other platforms as well?

Sure.

> Wherever Emacs invented its own UI, that UI and its widgets will
> always be different from the platform standards.

Yes, so deviating a bit more from the platform's UI shouldn't be a
problem as long as it provides some advantage.

>> It seems that the only elements which are "native" in the MS-Windows
>> port are the menu and the dialogs.
>
> And the scroll bars.

Yep, forgot those. Maybe because I use different versions of MS-Windows
and the scroll bars look different on each.

> And the frame decorations.

The frame decorations usually are provided by the Window Manager, they
are not something which are under Emacs' control (although MS-Windows
allows to change them to a large extent, other systems do not.)

> Is that different from other toolkits?  OK, so with GTK we also use
> their tool bar and tooltips (and get to live with their limitations),
> but other than that?
>
>> If we add to that that Emacs has its own way of doing things (M-x
>> command system, interaction through the minibuffer instead of dialogs,
>> different keyboard shorcuts for standard actions like cut&paste, etc.)
>> we could conclude that Emacs already is very alien to
>> MS-Windows/GTK/MacOS UI standards.
>
> That's an exaggeration.

Well, that's your opinion about my perception ;-) I still remember very
well when I learned Emacs 20 years ago. It was otherworldly to me.
Neither then (when I was using MS-Windows only) nor now (when I'm
primarly a GNU/Linux user) there is anything that is vaguely similar to
Emacs on the set of applications used by the people I know.

>> So I can hardly imagine a typical Emacs user that could make a big issue
>> about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and GTK.)
>
> That's an "ad absurdum" kind of argument.
>
> In general, Emacs does do some (quite a few) thing differently, and
> where it does, it does so uniformly on all platforms, more or less (I
> think NS is the largest outlier here, with its Cmd key).  But this is
> a tangent: we weren't discussing the entire UI and its conventions, we
> only discussed the GUI aspects of the Emacs appearance.

I'm discussing the GUI too, but both the xenodasein and me are not
concerned with putting some lipstick on top of current Emacs GUI. IIUC
the change he is proposing is directed towards simplyfing the GUI code
*and* expanding what we can show, which would set the basis for a whole
lot of new features.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02557.html
From: Po Lu

> That's only the tip of the iceberg...

Wow, saving this mail.  Thanks.

This is just my $0.02 when it comes to some new system.

It is very valid to work only towards improving Emacs in its current
form without fundamental changes, making it a more pleasant experience
for the stable user base.  Especially for people who aren't into
programming, and can't be expected to fix their environmental all the
time.  Making fundamental changes to expand user base is the risky move
and what would be the gain apart from ideological significance; bragging
rights?

If it is to be done though, new things must be tried. A "Do. Or do not.
There is no try." situation if you will.

Like ditching GTK altogether.  Maybe it will instead attract contributors
that value knowing what goes under the hood, and would much rather
spend time with documentation of Wayland?  Passion for computing
is the common ground for Emacs users after all.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > Another case in point: try resizing or creating a frame on a GTK build
 > that is smaller than its menu bar, see what GTK does to it, and compare
 > that behaviour (which cannot be turned off, at least when I tried) to
 > the behaviour under an Xt or no-toolkit build.

What precisely is the problem with the menu bar?

Here it is problematic to shrink the width of a frame to some size less
than that required for the tool bar.  But that's moot currently given
the fact that my tool bar icons have so far inexplicably vanished from
all GTK frames on Debian bullseye and I get only plain text instead of
them.

martin

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> No, the Lucid menu here shows a nice, modern font, while the Motif
> menu shows some pixelated thing from the eighties.

Your version of Motif is either too old to support Xft, or your system
is incorrectly configured.

Try adding the following resources to your X server:

  *.renderTable: variable
  *.renderTable.variable.fontName: Sans
  *.renderTable.variable.fontSize: 8
  *.renderTable.variable.fontType: FONT_IS_XFT

Re: Platform independent graphical display for Emacs

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> Here it is problematic to shrink the width of a frame to some size
> less than that required for the tool bar.  But that's moot currently
> given the fact that my tool bar icons have so far inexplicably
> vanished from all GTK frames on Debian bullseye and I get only plain
> text instead of them.

That too, but the menu bar does the same thing as the toolbar.  Also try
running with x-gtk-stock-map set to nil, and x-gtk-stock-cache set to an
empty hash table, to see if the icons come back.

Thanks.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 24.12.2021 10:33, Eli Zaretskii wrote:
>> That said, all of this would obviously be a lot of work and until and
>> unless someone starts such work this is all rather academic.
> Not only that, I'd hesitate to accept such a contribution, because its
> long-term maintenance would most probably be a constant burden,

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.

I would hate to discourage someone from taking the initiative a trying 
to create a better "no-toolkit" port which supports font scaling, for 
example. And also some existing interface details which people mentioned 
before (customize widgets, popups, tabs, scroll bars), which are 
currently not very well integrated with the existing toolkits, in a more 
organic way. Better performance would help, too (like child frames are 
faster on older ports than on GTK3 one).

 >  and if
 > the person(s) who develop such a "native" toolkit go on to greener
 > pastures, we will be left with an unmaintained subsystem.

Worst-case scenario, we'd just have to drop that "port", wouldn't we?

> So I don't think it is a good idea for Emacs to develop its own
> toolkit.  We should use what's out there.

Like some people said previously, Emacs feels similar in spirit to 
another popular FLOSS project: Blender. Community of professionals, 
keyboard-driven interface, power and customizability.

Blender never used an existing GUI toolkit. And I think it looks pretty 
good (even though I hope it has grown a light-bg theme by now):

https://docs.blender.org/manual/en/latest/_images/editors_preferences_section_interface.png
https://b3d.interplanety.org/wp-content/upload_content/2016/09/01-4.jpg

Of course, the Blender community is much larger and better funded, but 
OTOH the number of different UI elements we'd need to support is much 
smaller as well.

And we could tap into some existing community talent by having a lot of 
the UI logic implemented in Lisp. Similarly to how a number of recent 
web browser projects have their UIs implemented with JS+HTML.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> No, the Lucid menu here shows a nice, modern font, while the Motif
>> menu shows some pixelated thing from the eighties.
>
> Your version of Motif is either too old to support Xft, or your system
> is incorrectly configured.

I'm using Debian Testing.

> Try adding the following resources to your X server:
>
>   *.renderTable: variable
>   *.renderTable.variable.fontName: Sans
>   *.renderTable.variable.fontSize: 8
>   *.renderTable.variable.fontType: FONT_IS_XFT

No, I don't need to tinker with configuration files for any other app to
look good and I wont start doing it for something that offers no benefit
over what I already use.

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Your version of Motif is either too old to support Xft, or your system
>> is incorrectly configured.

> I'm using Debian Testing.

That doesn't tell if your Motif is installed correctly with the
appropriate build options.

>> Try adding the following resources to your X server:
>>
>>   *.renderTable: variable
>>   *.renderTable.variable.fontName: Sans
>>   *.renderTable.variable.fontSize: 8
>>   *.renderTable.variable.fontType: FONT_IS_XFT

> No, I don't need to tinker with configuration files for any other app to
> look good and I wont start doing it for something that offers no benefit
> over what I already use.

If you aren't interested, then I suggest you ignore the problem: Motif
users will use CDE, which configures Motif properly by default, or have
their system configured to suit them.

Similarly, you will get Courier drawn through Core Fonts if you build
the Lucid toolkit without Xft or Cairo support.

Re: Platform independent graphical display for Emacs

[Jose A. Ortega Ruiz]

On Fri, Dec 24 2021, Po Lu wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So I can hardly imagine a typical Emacs user that could make a big
>> issue about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and
>> GTK.)
>
> The Lucid menu was mostly designed after the Motif menu.  They also look
> mostly identical.  Anyway, the reason support for those toolkits was
> added is that people care for them, and that's also why nobody uses the
> no-toolkit build anymore.

i use it.  and have been using it for the last 20 years.  i want an
emacs with graphical capabilities but i don't use any toolkit element
ever.

i wish you'd be as nice with the non-toolikit option as you've been with
the motif one, if possible.

thanks,
jao
-- 
There are no whole truths; all truths are half-truths. It is trying to
treat them as whole truths that plays the devil. -Alfred Whitehead

Re: Platform independent graphical display for Emacs

[Po Lu]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> i use it.  and have been using it for the last 20 years.  i want an
> emacs with graphical capabilities but i don't use any toolkit element
> ever.
>
> i wish you'd be as nice with the non-toolikit option as you've been
> with the motif one, if possible.

I don't know how to improve the no-toolkit build.  Feel free to work on
that, however.

Thanks.

Re: Platform independent graphical display for Emacs

[Jose Antonio Ortega Ruiz]

On Sat, Dec 25 2021, Po Lu wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> i use it.  and have been using it for the last 20 years.  i want an
>> emacs with graphical capabilities but i don't use any toolkit element
>> ever.
>>
>> i wish you'd be as nice with the non-toolikit option as you've been
>> with the motif one, if possible.
>
> I don't know how to improve the no-toolkit build.  Feel free to work on
> that, however.

i don't need any improvement.  i'll be content if it doesn't disappear
under the false premise that "nobody uses it".

thanks,
jao
-- 
It does not do to leave a live dragon out of your calculations, if you
live near him. -J.R.R. Tolkien, novelist and philologist (1892-1973)

Re: Platform independent graphical display for Emacs

[Po Lu]

Jose Antonio Ortega Ruiz <jao@gnu.org> writes:

> i don't need any improvement.  i'll be content if it doesn't disappear
> under the false premise that "nobody uses it".

It will not disappear as it adds no extra complexity to maintainence,
and it is also important at least for testing purposes.

For example, it was very helpful during the development of the XInput 2
support, before I managed to make it work with GTK+.

Thanks.

Re: Platform independent graphical display for Emacs

[LdBeth]

>>>>> In <87lf09gye1.fsf@gnus.jao.io> 
>>>>>	"Jose A. Ortega Ruiz" <jao@gnu.org> wrote:
jao> On Fri, Dec 24 2021, Po Lu wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So I can hardly imagine a typical Emacs user that could make a big
>> issue about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and
>> GTK.)
>
> The Lucid menu was mostly designed after the Motif menu.  They also look
> mostly identical.  Anyway, the reason support for those toolkits was
> added is that people care for them, and that's also why nobody uses the
> no-toolkit build anymore.

jao> i use it.  and have been using it for the last 20 years.  i want an
jao> emacs with graphical capabilities but i don't use any toolkit element
jao> ever.

jao> i wish you'd be as nice with the non-toolikit option as you've been with
jao> the motif one, if possible.

jao> thanks,
jao> jao
jao> -- 
jao> There are no whole truths; all truths are half-truths. It is trying to
jao> treat them as whole truths that plays the devil. -Alfred Whitehead

Same situtation here. I'm using Emacs on a nearly 20 years old laptop
with Gentoo Linux. I don't use any other GUI programs other than Emacs
and a terminal emulator, nor any GUI toolkit element for Emacs.  It's
just I don't like to compile and install GTK for solely a GUI build of
Emacs.

Please continue to keeps the non-toolikit option, or at least consider
using a light weight toolkit. Thanks.
-- 
LDB

Re: Platform independent graphical display for Emacs

[Po Lu]

LdBeth <andpuke@foxmail.com> writes:

> Please continue to keeps the non-toolikit option, or at least consider
> using a light weight toolkit. Thanks.

We are not (and hopefully never) going to remove the no-toolkit build.

While I said that support for Motif was added because people cared for
it, I didn't say that we would remove features like the no-toolkit
build, which I think very little people really care for.

OTOH, both Motif and lwlib/Athena are relatively lightweight (compared
to GTK+) and will probably serve you just as well as the no-toolkit
build for your purposes.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Jose Antonio Ortega Ruiz <jao@gnu.org>
> Date: Sat, 25 Dec 2021 05:12:18 +0000
> Cc: emacs-devel@gnu.org
> 
> > I don't know how to improve the no-toolkit build.  Feel free to work on
> > that, however.
> 
> i don't need any improvement.  i'll be content if it doesn't disappear
> under the false premise that "nobody uses it".

It won't, don't worry.  The no-toolkit build is the basis for
everything else, so it should be always available.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Cc: luangruo@yahoo.com, drew.adams@oracle.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 25 Dec 2021 02:30:25 +0200
> 
> On 24.12.2021 10:33, Eli Zaretskii wrote:
> >> That said, all of this would obviously be a lot of work and until and
> >> unless someone starts such work this is all rather academic.
> > Not only that, I'd hesitate to accept such a contribution, because its
> > long-term maintenance would most probably be a constant burden,
> 
> 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.

> I would hate to discourage someone from taking the initiative a trying 
> to create a better "no-toolkit" port which supports font scaling, for 
> example.

The suggestion was not to improve the no-toolkit configuration and
leave all the supported toolkits in place.  The suggestion was to drop
all the others.

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.)

> Worst-case scenario, we'd just have to drop that "port", wouldn't we?

We cannot just "drop" the only toolkit we have.

> Like some people said previously, Emacs feels similar in spirit to 
> another popular FLOSS project: Blender. Community of professionals, 
> keyboard-driven interface, power and customizability.
> 
> Blender never used an existing GUI toolkit. And I think it looks pretty 
> good (even though I hope it has grown a light-bg theme by now):
> 
> https://docs.blender.org/manual/en/latest/_images/editors_preferences_section_interface.png
> https://b3d.interplanety.org/wp-content/upload_content/2016/09/01-4.jpg
> 
> Of course, the Blender community is much larger and better funded, but 
> OTOH the number of different UI elements we'd need to support is much 
> smaller as well.

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.

> And we could tap into some existing community talent by having a lot of 
> the UI logic implemented in Lisp. Similarly to how a number of recent 
> web browser projects have their UIs implemented with JS+HTML.

I think this hope is misguided, because Emacs Lisp was not designed to
be a UI programming language, it was designed as a text-processing
language.  So it would need significant extensions to get closer to
your dream.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > That too, but the menu bar does the same thing as the toolbar.

My memory is failing.  I even menitoned that in PROBLEMS.

BTW - the pgtk build seems to refuse shrinking a frame via mouse
dragging in such case.  The gtk build apparently doesn't.

 > Also try
 > running with x-gtk-stock-map set to nil, and x-gtk-stock-cache set to an
 > empty hash table, to see if the icons come back.

Thanks.  I will look into them next time I'm on that machine.

martin

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > I don't know how to improve the no-toolkit build.  Feel free to work on
 > that, however.

It lacks horizontal scroll bars.  It should be easy to do, yet I never
finished that code.

martin

Re: Platform independent graphical display for Emacs

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> BTW - the pgtk build seems to refuse shrinking a frame via mouse
> dragging in such case.  The gtk build apparently doesn't.

I think that boils down to the regular GTK build receiving
ConfigureNotify before GTK does (and runs its size allocation
machinery), while with the PGTK build GTK receives it and can do its
thing first.

I might be able to solve this.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 10:25, Eli Zaretskii wrote:

>> On 24.12.2021 10:33, Eli Zaretskii wrote:
>>>> That said, all of this would obviously be a lot of work and until and
>>>> unless someone starts such work this is all rather academic.
>>> Not only that, I'd hesitate to accept such a contribution, because its
>>> long-term maintenance would most probably be a constant burden,
>>
>> 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.

>> I would hate to discourage someone from taking the initiative a trying
>> to create a better "no-toolkit" port which supports font scaling, for
>> example.
> 
> The suggestion was not to improve the no-toolkit configuration and
> leave all the supported toolkits in place.  The suggestion was to drop
> all the others.
> 
> 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.

It might become feasible to remove a number of them, though. If my hunch 
is right that people have been holding on to no-toolkit, or Motif, or 
Lucid, because they each have some pet bug which is present on newer 
toolkit ports, but not on their chosen one.

>> Worst-case scenario, we'd just have to drop that "port", wouldn't we?
> 
> We cannot just "drop" the only toolkit we have.
> 
>> Like some people said previously, Emacs feels similar in spirit to
>> another popular FLOSS project: Blender. Community of professionals,
>> keyboard-driven interface, power and customizability.
>>
>> Blender never used an existing GUI toolkit. And I think it looks pretty
>> good (even though I hope it has grown a light-bg theme by now):
>>
>> https://docs.blender.org/manual/en/latest/_images/editors_preferences_section_interface.png
>> https://b3d.interplanety.org/wp-content/upload_content/2016/09/01-4.jpg
>>
>> Of course, the Blender community is much larger and better funded, but
>> OTOH the number of different UI elements we'd need to support is much
>> smaller as well.
> 
> 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.

>> And we could tap into some existing community talent by having a lot of
>> the UI logic implemented in Lisp. Similarly to how a number of recent
>> web browser projects have their UIs implemented with JS+HTML.
> 
> I think this hope is misguided, because Emacs Lisp was not designed to
> be a UI programming language, it was designed as a text-processing
> language.  So it would need significant extensions to get closer to
> your dream.

There is not much in JS that would make it a UI language. Other Lisps 
compile to it without problems. Other editors had been written in lisp 
as well (such a LightTable -- in ClojureScript).

Perhaps better concurrency story would make it a tad easier (e.g. better 
stdlib for working with threads, or a counterpart to Web Workers), but 
IIRC when LightTable was developed, JavaScript had neither.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> 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.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.

Maintaining a toolkit, even more so one that supports as many platforms
as we do, is not a one-person job, especially in this rapidly changing
world.

Case in point: Wayland (which we definitely want to support.)

A single expert (or even a small group of experts) will have a very hard
time maintaining a toolkit that will work with Wayland, seeing as you
have to understand XML, a complicated wire protocol and several very
rapidly changing "standard" extensions to do any meaningful work with
it.  For example, an unstable extension is required for a toplevel to
obtain the input focus, and another is required to handle input methods.

Seeing as other programs such as Chromium (and by extension VS-Code) and
even toolkits with ample funding and full-time developers such as Qt
still struggle with Wayland support, I think it would be a very, very
bad idea for us to take that task onto ourselves.

Besides, we will probably not be able to implement everything on other
platforms such as NS, Haiku, or MS-Windows, so such a configuration will
likely be specific to X, which begs the question of why we should use
that configuration instead of the other in-tree X toolkit Lucid.

> 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.

You can't really switch "from one no-toolkit configuration" to another,
because they cannot be much different by definition.

My idea of the only remotely practical way to implement a similar
configuration is for everything on the display (such as menu bars and
scroll bars, but not dialog boxes or popup menus) to be drawn by
redisplay through the RIF similarly to how the tool bar is displayed at
present in all platforms except NS and GTK.  I think we can already do
that with the menu bar as well -- the only job that's left is to make it
look nicer, possibly by applying a box and a gray background to the
individual buttons there.

Ideally, this won't require significant changes to the X specific code
at all.

However, exposing that to Lisp would be a bad idea.  If the tab bar
feature is anything to judge by, this seems to be quite difficult and
also tends to create obscure bugs, such as the image relief bugs with
the tab bar.

> It might become feasible to remove a number of them, though. If my
> hunch is right that people have been holding on to no-toolkit, or
> Motif, or Lucid, because they each have some pet bug which is present
> on newer toolkit ports, but not on their chosen one.

People might also have a preference for Lucid or Motif, or even GTK+.
There are also people who want to use Motif/Lucid specific resources, or
GTK stylesheets.

I hope we will not remove any of the toolkit code, no matter what.

> Having a port like that developed could get us +1 such expect.

That assumes someone exists and is willing to do the work.  I don't
think we can magically "have" such a port developed and gain such an
expert.

Would you like to volunteer?

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 14:38, Eli Zaretskii wrote:

>> 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.

I suppose.

And I think the BeOS port had been accepted under the same conditions 
recently.

> 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.

We should be able to drop unmaintained ports. Even if we're reluctant, 
in general, to remove features that someone is using. After all, the 
history of changes is saved, so as soon as a volunteer arrives to 
resurrect it, they can start with 'git revert' and continue.

>>> 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?

In my mind, the new port would, similar to Blender, or VS Code, or IDEA, 
have their own set of widgets for menus, buttons, tabs, etc, which would 
remain consistent across platforms and look at least somewhat 
fresh/modern-ish. And it would support HiDPI scaling.

But the details are ultimately up to the developer.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> 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:57:40 +0200
> 
> > 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.
> 
> I suppose.
> 
> And I think the BeOS port had been accepted under the same conditions 
> recently.

Because we did have someone who volunteered, and because nothing would
be lost on platforms of interest to us if the BeOS port bitrots.

> > 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.
> 
> We should be able to drop unmaintained ports.

Once again, a single toolkit on which all the platforms depend cannot
be dropped.  So it's a huge difference from the BeOS port.

> Even if we're reluctant, in general, to remove features that someone
> is using. After all, the history of changes is saved, so as soon as
> a volunteer arrives to resurrect it, they can start with 'git
> revert' and continue.

That's generally not a practical possibility, because the code changes
very rapidly, and what you revert won't even compile in most cases.

> > 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?
> 
> In my mind, the new port would, similar to Blender, or VS Code, or IDEA, 
> have their own set of widgets for menus, buttons, tabs, etc, which would 
> remain consistent across platforms and look at least somewhat 
> fresh/modern-ish. And it would support HiDPI scaling.

So your dream is even more in the fantasy-land than I thought.  Of
course, even such fantasies could come true if we have someone to do
the job and stick around to keep it working.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> And I think the BeOS port had been accepted under the same conditions
> recently.

I don't plan to abandon it, and besides, it's not vital for the
functioning of Emacs.

> We should be able to drop unmaintained ports. Even if we're reluctant,
> in general, to remove features that someone is using. After all, the
> history of changes is saved, so as soon as a volunteer arrives to
> resurrect it, they can start with 'git revert' and continue.

IMO, we should just let them be.  If someone notices once they get
broken, and is interested in fixing them, he will probably do that.

There's also the chance that an unmaintained port will simply continue
to work.

I think that's the situation with the MS-DOS port as well.

> In my mind, the new port would, similar to Blender, or VS Code, or
> IDEA, have their own set of widgets for menus, buttons, tabs, etc,
> which would remain consistent across platforms and look at least
> somewhat fresh/modern-ish. And it would support HiDPI scaling.

Please see my other reply to you on why that's simply not feasible for a
single expert, which we will probably not even get.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

Why oh why you don't just say "go ahead and we will look at your work
when you have something to show" ?

Then, after a long time (because this project will require a loooong
time) *if* something comes out, you evaluate the result as any other
contribution and decide what to do. Why so many "what-ifs" before even
seeing the first patch and without understanding the proposal in full?
(see below.)

This is very discouraging, not only for the OP, but for any bystander
would-be contributor.

> 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.

Yes, because having a single, modern, sane, popular cross-platform
graphics library (let's say Skia, for instance) would make things much
worse than the current status-quo, with N entangled backends requiring
the participation of multiple experts every time a new feature is
implemented :-/

To insist: the proposed system would have three characteristics:

1. Cross-platform (as the proposal's subject says)

2. Simplicity, compared to what we have now.

3. New graphical capabilities that will make possible new high-level
   features.

I don't know why you keep ignoring point 3, which is the most important,
and reduce the proposal to "oh, someone wants to add one more graphical
backend."

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Yes, because having a single, modern, sane, popular cross-platform
> graphics library (let's say Skia, for instance) would make things much
> worse than the current status-quo, with N entangled backends requiring
> the participation of multiple experts every time a new feature is
> implemented :-/

No "cross-platform graphics library" is either truly cross-platform or
acceptable for our purposes.

Skia itself is simply a no-goer.  That abomination is impossible to
build outside the context of Chromium (or some other Google-endorsed
program).  Their API is also unstable and changes rapidly.

On the other hand, the current status quo seems to work: I can't really
think of an instance where the people interested in a port to a
different platform didn't spend the small effort required to implement a
new feature in Emacs to that platform.

And that effort is usually minor.  It took me about 15 minutes to add
tab bar support to the NS port, for example, and that was without any
prior experience in both the NS port code and Cocoa in general.

> 3. New graphical capabilities that will make possible new high-level
>    features.

> I don't know why you keep ignoring point 3, which is the most important,
> and reduce the proposal to "oh, someone wants to add one more graphical
> backend."

Please explain in detail what the new graphical capabilities are, and
how using a different graphics library will help.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 25 Dec 2021 13:20:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Why oh why you don't just say "go ahead and we will look at your work
> when you have something to show" ?

I did -- but that was before I understood what was being proposed.
The OP wanted assurance that the code will be accepted once done, and
I cannot in good faith give him that, given what's being actually
proposed.  Doing so would be betraying the OP's trust, especially if
eventually we don't like the results.

> > 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.
> 
> Yes, because having a single, modern, sane, popular cross-platform
> graphics library (let's say Skia, for instance) would make things much
> worse than the current status-quo, with N entangled backends requiring
> the participation of multiple experts every time a new feature is
> implemented :-/

That's not what on the table, AFAIU.

> To insist: the proposed system would have three characteristics:
> 
> 1. Cross-platform (as the proposal's subject says)
> 
> 2. Simplicity, compared to what we have now.
> 
> 3. New graphical capabilities that will make possible new high-level
>    features.
> 
> I don't know why you keep ignoring point 3, which is the most important,
> and reduce the proposal to "oh, someone wants to add one more graphical
> backend."

I'm not ignoring anything.  You, OTOH, ignore both what is being
proposed and the rest of the discussion.  In effect, you are talking
about an entirely different proposal, one about which I said it
_would_ make sense.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

FWIW, a lot of conversation seem to happen in this line of thread that
have wrong judgment on what is being suggested.  It may not be
complete or perfectly clear, but already contradicts some of things
written after it.

Please see:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02539.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02574.html

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:29, Po Lu wrote:
> Skia itself is simply a no-goer.  That abomination is impossible to
> build outside the context of Chromium (or some other Google-endorsed
> program).

I really wouldn't call Mozilla Firefox a Google-endorsed program at this 
point.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 15:29, Po Lu wrote:

> I really wouldn't call Mozilla Firefox a Google-endorsed program at
> this point.

Firefox spends much of its time dealing with Skia breakage (and I think
only supports being built with a particular version of Skia at any
time.)

Their development team is also many orders of magnitudes larger, and
they get paid.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:06, Eli Zaretskii wrote:
>> 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:57:40 +0200
>>
>>> 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.
>>
>> I suppose.
>>
>> And I think the BeOS port had been accepted under the same conditions
>> recently.
> 
> Because we did have someone who volunteered, and because nothing would
> be lost on platforms of interest to us if the BeOS port bitrots.

Which would be also true when someone initially proposes the new "single 
toolkit" port for inclusion.

>>> 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.
>>
>> We should be able to drop unmaintained ports.
> 
> Once again, a single toolkit on which all the platforms depend cannot
> be dropped.  So it's a huge difference from the BeOS port.

Once again: we would only get to that point after the "single toolkit" 
port is functional, accepted by the majority of us, and probably 
"adopted" by a few regular contributors as their area of interest.

Only then we could realistically vote to drop all other ports.

I'm sure a contributor who would propose such new port would understand 
all of this.

>> Even if we're reluctant, in general, to remove features that someone
>> is using. After all, the history of changes is saved, so as soon as
>> a volunteer arrives to resurrect it, they can start with 'git
>> revert' and continue.
> 
> That's generally not a practical possibility, because the code changes
> very rapidly, and what you revert won't even compile in most cases.

Yes and no: I'm sure having the previous code available will be a lot of 
help. As opposed to rewriting the same port from scratch.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 15:37 by eliz@gnu.org:

> I did -- but that was before I understood what was being proposed.
> The OP wanted assurance that the code will be accepted once done,
> and I cannot in good faith give him that, given what's being actually
> proposed. Doing so would be betraying the OP's trust, especially if
> eventually we don't like the results.
> 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.

It would be extremely unfair to expect any sort of guarantee.  IMHO
only things required are plans and desire to have that sort of thing
inside the Emacs.  If the end result is disliked by the community,
it must not be included, and wait available for revisions.

See: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02203.html

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:54, Po Lu wrote:
> Their development team is also many orders of magnitudes larger, and
> they get paid.

OTOH, the surface area of their code dealing with Skia must be much 
larger as well.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Date: Sat, 25 Dec 2021 14:00:07 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, ofv@wanadoo.es
> 
> Dec 25, 2021, 15:37 by eliz@gnu.org:
> 
> > I did -- but that was before I understood what was being proposed.
> > The OP wanted assurance that the code will be accepted once done,
> > and I cannot in good faith give him that, given what's being actually
> > proposed. Doing so would be betraying the OP's trust, especially if
> > eventually we don't like the results.
> > 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.
> 
> It would be extremely unfair to expect any sort of guarantee.  IMHO
> only things required are plans and desire to have that sort of thing
> inside the Emacs.  If the end result is disliked by the community,
> it must not be included, and wait available for revisions.

No one needs anyone's permission to work on Emacs.  It is Free
Software.  If you want to work on it, you are most welcome, and none
of this discussion was necessary.  If this was due to my
misunderstanding, I again apologize.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> OTOH, the surface area of their code dealing with Skia must be much
> larger as well.

"Surface area" doesn't really matter when Skia developers make changes
to fundamental features at random.

From a maintainability perspective, Cairo is much better for a program
like Emacs.  The portability problems are basically the same with both
libraries.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> 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 14:59:34 +0200
> 
> > Because we did have someone who volunteered, and because nothing would
> > be lost on platforms of interest to us if the BeOS port bitrots.
> 
> Which would be also true when someone initially proposes the new "single 
> toolkit" port for inclusion.

No, it won't.  The "single" part makes the crucial difference.

> > Once again, a single toolkit on which all the platforms depend cannot
> > be dropped.  So it's a huge difference from the BeOS port.
> 
> Once again: we would only get to that point after the "single toolkit" 
> port is functional, accepted by the majority of us, and probably 
> "adopted" by a few regular contributors as their area of interest.
> 
> Only then we could realistically vote to drop all other ports.

You are responding to what I wrote on the assumption that this was
being proposed up front.

> I'm sure a contributor who would propose such new port would understand 
> all of this.

That wasn't my understanding.

> > That's generally not a practical possibility, because the code changes
> > very rapidly, and what you revert won't even compile in most cases.
> 
> Yes and no: I'm sure having the previous code available will be a lot of 
> help. As opposed to rewriting the same port from scratch.

Much more is needed than just the code which at some point did work.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:06, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> And I think the BeOS port had been accepted under the same conditions
>> recently.
> 
> I don't plan to abandon it,

It's still bus factor of 1.

>> We should be able to drop unmaintained ports. Even if we're reluctant,
>> in general, to remove features that someone is using. After all, the
>> history of changes is saved, so as soon as a volunteer arrives to
>> resurrect it, they can start with 'git revert' and continue.
> 
> IMO, we should just let them be.  If someone notices once they get
> broken, and is interested in fixing them, he will probably do that.
> 
> There's also the chance that an unmaintained port will simply continue
> to work.
> 
> I think that's the situation with the MS-DOS port as well.

That's just the argument of when we call a port "unmaintained". E.g., I 
would say a port is unmaintained when there are known usability-breaking 
bugs. Or you can call it that when it stops compiling (for a certain 
period of time).

But there *is* value in dropping unused ports: the trimming of the 
#ifdefs forest, as well as less work for regular contributors to keep 
code compiling under various conditions.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Yes, because having a single, modern, sane, popular cross-platform
>> graphics library (let's say Skia, for instance) would make things much
>> worse than the current status-quo, with N entangled backends requiring
>> the participation of multiple experts every time a new feature is
>> implemented :-/
>
> No "cross-platform graphics library" is either truly cross-platform or
> acceptable for our purposes.

Because you know them all and you, and only you, define what is
acceptable for our purposes.

> Skia itself is simply a no-goer.  That abomination is impossible to
> build outside the context of Chromium

Just to check your assertion, I tried to build Skia on my Debian box
and, sure enough, after ten minutes of work the build succesfully
completed. I had some issues that were swiftly solved with a web search.
No Chromium involved, not even for doing the web search ;-)

A closer look at Skia makes me think that it is not a good candidate for
Emacs, for several reasons. But Skia was just an example, we (or, better
said, the OP) can examine what other options are available.

>> 3. New graphical capabilities that will make possible new high-level
>>    features.
>
>> I don't know why you keep ignoring point 3, which is the most important,
>> and reduce the proposal to "oh, someone wants to add one more graphical
>> backend."
>
> Please explain in detail what the new graphical capabilities are, and
> how using a different graphics library will help.

We could turn the frame into a canvas. Take
display-fill-column-indicator for instance. Instead of faking a line
with characters, we could simply draw the line as a graphic object.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 16:05 by eliz@gnu.org:
> No one needs anyone's permission to work on Emacs. It is Free
> Software. If you want to work on it, you are most welcome, and none
> of this discussion was necessary. If this was due to my
> misunderstanding, I again apologize.

In my eyes there is nothing to apologize for, as maintainers are
already busy with a lot of things and cannot be expected to keep in
memory every single mail flying around.  A digest should be provided
to them after any detailed discussion.  (I also don't have the most
stable mind.  Apologies.)

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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.
>> 
>> Why oh why you don't just say "go ahead and we will look at your work
>> when you have something to show" ?
>
> I did -- but that was before I understood what was being proposed.
> The OP wanted assurance that the code will be accepted once done,

Oh, I missed that part. xenodasein: is that really what you want or is
there a misunderstanding here?

> and
> I cannot in good faith give him that, given what's being actually
> proposed.

Obviously you can't give that type of assurances for any proposal.

>> To insist: the proposed system would have three characteristics:
>> 
>> 1. Cross-platform (as the proposal's subject says)
>> 
>> 2. Simplicity, compared to what we have now.
>> 
>> 3. New graphical capabilities that will make possible new high-level
>>    features.
>> 
>> I don't know why you keep ignoring point 3, which is the most important,
>> and reduce the proposal to "oh, someone wants to add one more graphical
>> backend."
>
> I'm not ignoring anything.  You, OTOH, ignore both what is being
> proposed and the rest of the discussion.  In effect, you are talking
> about an entirely different proposal, one about which I said it
> _would_ make sense.

Well, maybe I'm thinking on what *I* would like to see instead on what
the OP is actually proposing.

xenodasein: would you say that my 3 points above fully describe your
proposal?

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 25 Dec 2021 14:09:02 +0100
> 
> A closer look at Skia makes me think that it is not a good candidate for
> Emacs, for several reasons. But Skia was just an example, we (or, better
> said, the OP) can examine what other options are available.

Yes, examples are being thrown here and there without any relevance,
just to make a point in a dispute, it seems.  It doesn't help to have
a useful discussion.

> > Please explain in detail what the new graphical capabilities are, and
> > how using a different graphics library will help.
> 
> We could turn the frame into a canvas. Take
> display-fill-column-indicator for instance. Instead of faking a line
> with characters, we could simply draw the line as a graphic object.

If you think this kind of enhancement could materialize just by
changing the *term backends of the Emacs display, you don't have a
clear idea about the relevant architecture aspects of that.  It is
nigh impossible to do something like that without the knowledge of
xdisp.c and dispnew.c.  I'm telling you that as the single person
around here who has any kind of practical experience in implementing
something like that: the TTY menus do something very similar, and that
code gets away by the skin of its teeth, and would be probably simply
impossible with GUI display.

Throwing around such ideas without any real knowledge is simply
irresponsible.  Someone might believe you and spend some non-trivial
time trying to implement that.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 14:51, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> 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.
> 
> Maintaining a toolkit, even more so one that supports as many platforms
> as we do, is not a one-person job, especially in this rapidly changing
> world.
> 
> Case in point: Wayland (which we definitely want to support.)

AFAIK, no ports other than PGTK have any Wayland support either.

So with the transition of GNU/Linux world from X to Wayland, we'd either 
have drop all other ports (aside from w32 and ns, I suppose), or end up 
dealing with this somehow anyway.

> A single expert (or even a small group of experts) will have a very hard
> time maintaining a toolkit that will work with Wayland, seeing as you
> have to understand XML, a complicated wire protocol and several very
> rapidly changing "standard" extensions to do any meaningful work with
> it.  For example, an unstable extension is required for a toplevel to
> obtain the input focus, and another is required to handle input methods.
> 
> Seeing as other programs such as Chromium (and by extension VS-Code) and
> even toolkits with ample funding and full-time developers such as Qt
> still struggle with Wayland support, I think it would be a very, very
> bad idea for us to take that task onto ourselves.

I suppose the hope at this point is that Wayland and set of its 
extensions will stabilize soon-ish, because it would also help with 
adoption by other programs.

> Besides, we will probably not be able to implement everything on other
> platforms such as NS, Haiku, or MS-Windows, so such a configuration will
> likely be specific to X, which begs the question of why we should use
> that configuration instead of the other in-tree X toolkit Lucid.

Lucid doesn't look nice, nor does it support modern features like 
scaling. But for all I know, the potential developer could start with 
improving Lucid instead, and at some point reach the state where they 
are satisfied with how things work.

After that, it might be a question whether people want to try unifying 
the w32 and ns ports too (by switching to rendering widgets with e.g. 
OpenGL). Or not.

>> 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.
> 
> You can't really switch "from one no-toolkit configuration" to another,
> because they cannot be much different by definition.
> 
> My idea of the only remotely practical way to implement a similar
> configuration is for everything on the display (such as menu bars and
> scroll bars, but not dialog boxes or popup menus) to be drawn by
> redisplay through the RIF similarly to how the tool bar is displayed at
> present in all platforms except NS and GTK.  I think we can already do
> that with the menu bar as well -- the only job that's left is to make it
> look nicer, possibly by applying a box and a gray background to the
> individual buttons there.
> 
> Ideally, this won't require significant changes to the X specific code
> at all.
> 
> However, exposing that to Lisp would be a bad idea.  If the tab bar
> feature is anything to judge by, this seems to be quite difficult and
> also tends to create obscure bugs, such as the image relief bugs with
> the tab bar.

Can't comment on that.

>> It might become feasible to remove a number of them, though. If my
>> hunch is right that people have been holding on to no-toolkit, or
>> Motif, or Lucid, because they each have some pet bug which is present
>> on newer toolkit ports, but not on their chosen one.
> 
> People might also have a preference for Lucid or Motif, or even GTK+.
> There are also people who want to use Motif/Lucid specific resources, or
> GTK stylesheets.
> 
> I hope we will not remove any of the toolkit code, no matter what.
> 
>> Having a port like that developed could get us +1 such expect.
> 
> That assumes someone exists and is willing to do the work.  I don't
> think we can magically "have" such a port developed and gain such an
> expert.
> 
> Would you like to volunteer?

This discussion started with a person expressing interest.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

For my answer, see:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02634.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02639.html

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Sorry for double mail.  I think we have exactly the same thing in mind:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02628.html

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> AFAIK, no ports other than PGTK have any Wayland support either.

> So with the transition of GNU/Linux world from X to Wayland, we'd
> either have drop all other ports (aside from w32 and ns, I suppose),
> or end up dealing with this somehow anyway.

We are not going to drop the X port.  Wayland is important, but it's
only available on a small amount of systems, certainly not all the
Unix-like systems currently support.

Other free systems such as FreeBSD immediately come to mind.

> I suppose the hope at this point is that Wayland and set of its
> extensions will stabilize soon-ish, because it would also help with
> adoption by other programs.

I too hope that, but a decade of Wayland development hasn't brought us
much in that direction.

> Lucid doesn't look nice, nor does it support modern features like
> scaling. But for all I know, the potential developer could start with
> improving Lucid instead, and at some point reach the state where they
> are satisfied with how things work.

I would welcome improvements to the Lucid toolkit.  Scaling is mostly
not the tookit's job under X, we just use GDK functions to get the
display's scale and apply that when creating the Cairo surface, AFAIU.

> After that, it might be a question whether people want to try unifying
> the w32 and ns ports too (by switching to rendering widgets with
> e.g. OpenGL). Or not.

OpenGL is not practical for many things such as text rendering.  It is
also slow over X forwarding.

> This discussion started with a person expressing interest.

No, it started with a person saying that we should decide to adopt his
approach.  He did not volunteer to write it and do the work required to
integrate it with Emacs, I think.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But there *is* value in dropping unused ports: the trimming of the
> #ifdefs forest, as well as less work for regular contributors to keep
> code compiling under various conditions.

I took care to keep the ifdefs down to a minimum when developing the
Haiku port.  I would consider it being referred to as an "ifdef forest"
to be an insult.

IME, image.c and xterm.c are the only places where an "ifdef forest"
related to toolkits and window systems really exists.  With image.c,
someone just has to put the work required to clean it up, there need not
be any changes elsewhere.

With xterm.c, 90% of the problem is GTK.  Other toolkits and the
no-toolkit build don't really contribute to the "maze of ifdefs" effect.

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Just to check your assertion, I tried to build Skia on my Debian box
> and, sure enough, after ten minutes of work the build succesfully
> completed. I had some issues that were swiftly solved with a web search.

Now try to link it with Emacs, enjoy the pages of linker errors, and get
frustrated two weeks later when the Skia developers change the signature
of some basic function causing the program to not work anymore.

That's been my experience working with Skia, and I think other people
will agree as well.

> A closer look at Skia makes me think that it is not a good candidate for
> Emacs, for several reasons. But Skia was just an example, we (or, better
> said, the OP) can examine what other options are available.

I would really appreciate names.

> We could turn the frame into a canvas. Take
> display-fill-column-indicator for instance. Instead of faking a line
> with characters, we could simply draw the line as a graphic object.

Alternatively, we could also ask RIF->draw_window_divider (which already
exists in every graphical port) to draw a line there.

It's just that nobody has put in the work to make that happen.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

IMHO something like Skia would be very overkill,
and damaging to Emacs' independence.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> A closer look at Skia makes me think that it is not a good candidate for
>> Emacs, for several reasons. But Skia was just an example, we (or, better
>> said, the OP) can examine what other options are available.
>
> Yes, examples are being thrown here and there without any relevance,
> just to make a point in a dispute, it seems.  It doesn't help to have
> a useful discussion.

It also happens that people make a big fuss over minor details instead
of dicussing the meat of the matter.

I don't think the outcome of this "dispute" depends on an example of
what it could be used. 

BTW, on the Skia-Emacs inadequacy issue, I would not be sure about what
part to blame the most.

>> > Please explain in detail what the new graphical capabilities are, and
>> > how using a different graphics library will help.
>> 
>> We could turn the frame into a canvas. Take
>> display-fill-column-indicator for instance. Instead of faking a line
>> with characters, we could simply draw the line as a graphic object.
>
> If you think this kind of enhancement could materialize just by
> changing the *term backends of the Emacs display, you don't have a
> clear idea about the relevant architecture aspects of that.  It is
> nigh impossible to do something like that without the knowledge of
> xdisp.c and dispnew.c.  I'm telling you that as the single person
> around here who has any kind of practical experience in implementing
> something like that: the TTY menus do something very similar, and that
> code gets away by the skin of its teeth, and would be probably simply
> impossible with GUI display.
>
> Throwing around such ideas without any real knowledge is simply
> irresponsible.  Someone might believe you and spend some non-trivial
> time trying to implement that.

You are overthinking something that's actually very simple: locating the
x coordinate of the n-th column and drawing a vertical line from top to
bottom of the window on each redisplay. Any sane graphics system can do
that simple, trivial thing. If it is difficult to do it in Emacs, that
only demonstrates how limited the display engine is on its capabilities.

If I were the hacker implementing the proposal, I would start with the
data structures that hold what needs to be shown and with a surface:
then, do the rendering. I know it is not as straightfordward as just
throwing a bunch of text on a textbox, but what I've seen on the sources
and your claims makes me think that any attempt at reusing the legacy
code (the one that actually paints the frame's contents) would be a
waste of time.

You are talking as if the complexity, quirks and limitations of Emacs'
display engine were something good, something to be preserved, when it
is quite the contrary, ever more when so few people understands it. By
your description, the current display engine is a big liability and any
proposal that could end with replacing it with something comprehensible
by mere mortals should be welcome.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 16:31, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> AFAIK, no ports other than PGTK have any Wayland support either.
> 
>> So with the transition of GNU/Linux world from X to Wayland, we'd
>> either have drop all other ports (aside from w32 and ns, I suppose),
>> or end up dealing with this somehow anyway.
> 
> We are not going to drop the X port.  Wayland is important, but it's
> only available on a small amount of systems, certainly not all the
> Unix-like systems currently support.
> 
> Other free systems such as FreeBSD immediately come to mind.

PGTK still supports X. And supports well, AFAIK.

But with it becoming increasingly irrelevant over the coming decade, it 
should become more and more practical to drop the other ports. Though 
I'm sure we'll be reluctant to do that.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 16:31, Po Lu wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> AFAIK, no ports other than PGTK have any Wayland support either.
>> 
>>> So with the transition of GNU/Linux world from X to Wayland, we'd
>>> either have drop all other ports (aside from w32 and ns, I suppose),
>>> or end up dealing with this somehow anyway.
>> We are not going to drop the X port.  Wayland is important, but it's
>> only available on a small amount of systems, certainly not all the
>> Unix-like systems currently support.
>> Other free systems such as FreeBSD immediately come to mind.
>
> PGTK still supports X. And supports well, AFAIK.
>
> But with it becoming increasingly irrelevant over the coming decade,
> it should become more and more practical to drop the other ports.
> Though I'm sure we'll be reluctant to do that.

Yes.

Some people write here as if time doesn't exist, as if living in some
sort of static universe or on a pre-industrial age :-)

I would be surprised if the proposed system were ready to be released as
an experimental feature in less than 4 years. Add another 4 to stabilize
before it can be considered as a replacement for the legacy graphical
backends.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 25 Dec 2021 15:08:17 +0100
> 
> > If you think this kind of enhancement could materialize just by
> > changing the *term backends of the Emacs display, you don't have a
> > clear idea about the relevant architecture aspects of that.  It is
> > nigh impossible to do something like that without the knowledge of
> > xdisp.c and dispnew.c.  I'm telling you that as the single person
> > around here who has any kind of practical experience in implementing
> > something like that: the TTY menus do something very similar, and that
> > code gets away by the skin of its teeth, and would be probably simply
> > impossible with GUI display.
> >
> > Throwing around such ideas without any real knowledge is simply
> > irresponsible.  Someone might believe you and spend some non-trivial
> > time trying to implement that.
> 
> You are overthinking something that's actually very simple: locating the
> x coordinate of the n-th column and drawing a vertical line from top to
> bottom of the window on each redisplay.

I think you have very inaccurate idea of what a redisplay cycle looks
like.

> If I were the hacker implementing the proposal, I would start with the
> data structures that hold what needs to be shown and with a surface:
> then, do the rendering. I know it is not as straightfordward as just
> throwing a bunch of text on a textbox, but what I've seen on the sources
> and your claims makes me think that any attempt at reusing the legacy
> code (the one that actually paints the frame's contents) would be a
> waste of time.

You are actually talking about redesigning the current display engine.
Which is a Good Thing, I think, because it was designed 23 years ago,
and nowadays we clearly see its limitations.  So please keep going
with this, and hopefully we will have a new display engine capable of
much more, and much better matching today's technologies and
expectations.

But saying that this can be done by just "drawing a vertical line" is
inaccurate at best.

> You are talking as if the complexity, quirks and limitations of Emacs'
> display engine were something good, something to be preserved, when it
> is quite the contrary, ever more when so few people understands it.

No, I'm saying that we shouldn't pretend we can implement features
like the one you mentioned without redesigning the display engine.
Just changing or replacing its terminal-specific backend will not be
enough.

Which is why replacing the toolkit(s) should have quite a different
perspective and different goals.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> PGTK still supports X. And supports well, AFAIK.

It supports X with many fundamental limitations such as crashing when a
display is closed.  The quality of support GTK gives X is nowhere close
to the X port itself.

There are also several bugs that can't really be fixed, such as
bug#52737, bug#52655 and bug#52677.

> But with it becoming increasingly irrelevant over the coming decade,
> it should become more and more practical to drop the other
> ports.

I don't see it becoming "increasingly irrelevant".  The world is not
only the bleeding edge GNU/Linux systems, there are also older systems,
systems that don't have enough memory for compositing, people who don't
want to use Xwayland (face it, it still doesn't work right), and people
who have to run an X server on platforms such as MS-Windows or the other
free Unix variants.

Re: Platform independent graphical display for Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I don't see it becoming "increasingly irrelevant".  The world is not
> only the bleeding edge GNU/Linux systems,

Your argument seems to suggest that it will still be relevant for some
time in certain configurations, not that it's relevance won't decrease.

Re: Platform independent graphical display for Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Your argument seems to suggest that it will still be relevant for some
> time in certain configurations, not that it's relevance won't
> decrease.

It'll always remain relevant enough for us to support.  Besides, 10
years is awfully optimistic for Wayland adoption.

People who want frame placement (i.e. by Speedbar) or session
restoration to work correctly will always have to run Emacs inside X (or
under Xwayland) as well, because even under Wayland X clients have the
ability to arbitrarily position windows.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > Also try
 > running with x-gtk-stock-map set to nil, and x-gtk-stock-cache set to an
 > empty hash table, to see if the icons come back.

I tried all these with no avail.  This behavior seems systemic to my GTK
setup on that machine.  I still have to investigate whether the fact
that the toolbar item text is shown instead (and not some graphical
artifact indicating the absence of the requested icon) is in some way
indicative.

martin

Re: Platform independent graphical display for Emacs

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> I tried all these with no avail.  This behavior seems systemic to my
> GTK setup on that machine.

Then I have no idea what is going on, unfortunately.