Re: Motif support

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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:

> 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

[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

[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

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

> 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

[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

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

> 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

[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

[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:

>> 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

[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: 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

[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

[Ó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: Ó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

[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:

> 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

[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

[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

[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

[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

[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

[Ó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

[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

[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

[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

[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

[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

[Ó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

[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

[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

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

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

[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

[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

[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

[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: 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: 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: 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: 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

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

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]

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

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

[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

[Ó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

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

Ó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

[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

[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

[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

[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

[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

[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: 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

[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

[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

[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

[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

[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

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

> 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

[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

[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

[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

[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

[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

[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

[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

[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: 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

[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

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

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

[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

[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

[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

[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

[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

[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: 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

[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

[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

[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

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

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

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