Would there be a drawback of using the same graphical toolkit on every platform?

Would there be a drawback of using the same graphical toolkit on every platform?

[emacsq via Users list for the GNU Emacs text editor]

Just wondering if a free toolkit like Gtk supports multiple platforms out of the box then would it make sense to use the same GTK-based code on every graphical platform? So using the same toolkit for everything graphics, instead of implementing features for windows, linux, etc. separately?

Is there something which native UI code does in emacs UI which GTK could not support?

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

emacsq via Users list for the GNU Emacs text editor wrote:

> Just wondering if a free toolkit like Gtk supports multiple
> platforms [...]

Indeed, GTK is cross-platform and available for Linux and
other systems as well. See:

  https://www.gtk.org/

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[emacsq via Users list for the GNU Emacs text editor]

> Indeed, GTK is cross-platform and available for Linux and other systems as well.

Right, so would it be advantageous for emacs to use the same code for graphic UI on every OS, or is there something which emacs can currently do by accessing the native APIs directly which cannot be done via GTK?

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

emacsq via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>> Indeed, GTK is cross-platform and available for Linux and other
>> systems as well.

> Right, so would it be advantageous for emacs to use the same code for
> graphic UI on every OS, or is there something which emacs can
> currently do by accessing the native APIs directly which cannot be
> done via GTK?

It isn't available on Haiku and doesn't work very well on MS-Windows,
macOS, and even GNU/Linux.

For example, it crashes during a display disconnect, fights with Emacs
over the size of frames, it cannot utilize selections when connected to
multiple displays, correctly position frames on X, warp the mouse
pointer, and so on and so forth.

The only use for GTK is to support window systems that we don't
otherwise support, such as Wayland and Broadway.  Otherwise, using that
window system directly will almost certainly lead to a better user
experience.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> It isn't available on Haiku and doesn't work very well on MS-Windows,
> macOS, and even GNU/Linux.
>
> For example, it crashes during a display disconnect, fights with Emacs
> over the size of frames, it cannot utilize selections when connected to
> multiple displays, correctly position frames on X, warp the mouse
> pointer, and so on and so forth.
>
> The only use for GTK is to support window systems that we don't
> otherwise support, such as Wayland and Broadway.  Otherwise, using that
> window system directly will almost certainly lead to a better user
> experience.

FWIW,I've been trying to port the PGTK version of Emacs to GTK 4 (which
will eventually replace GTK 3) without relying on any obsolete APIs such
as Cairo, and so far it hasn't worked very well.  I thought it would
have been finished by December, but the GTK 4 drawing model leaves too
much to be desired.

Not to mention that I had to reinvent file dialogs, menu bars, and popup
menus, since there are no reasonably designed versions of those in GTK 4
which don't involve a single static XML file.

So sticking to GTK is not a good choice, and certainly not a long-term
option.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[emacsq]

>
> It isn't available on Haiku and doesn't work very well on MS-Windows,
> macOS, and even GNU/Linux.
>

Thanks, I didn't use GTK on Windows or Mac, so I just assumed it
worked well on those too after 20 years of development.

It's strange that after all that time there are still such rough
edges.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> It's strange that after all that time there are still such rough
> edges.

It's simply not a very high priority for the GTK developers, AFAICT.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[emacsq]

>
> It's simply not a very high priority for the GTK developers, AFAICT.

There is also Qt as the other free toolkit (commercial, but dual licensed,
also available with  L/GPL license).

It also supports multiple OSs, it has Wayland support and likely works
betten on various platform, since there is a company making a living
from it.

Have you considered making a "Pure Qt" branch?

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

emacsq <laszlomail@protonmail.com> writes:

> There is also Qt as the other free toolkit (commercial, but dual licensed,
> also available with  L/GPL license).
>
> It also supports multiple OSs, it has Wayland support and likely works
> betten on various platform, since there is a company making a living
> from it.
>
> Have you considered making a "Pure Qt" branch?

Qt is not an option, and its Wayland support is much worse than GTK.  It
would be unacceptable to rely on C++ for an important part of Emacs.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

emacsq <laszlomail@protonmail.com> writes:

>>
>> It isn't available on Haiku and doesn't work very well on MS-Windows,
>> macOS, and even GNU/Linux.
>>
>
> Thanks, I didn't use GTK on Windows or Mac, so I just assumed it
> worked well on those too after 20 years of development.
>
> It's strange that after all that time there are still such rough
> edges.

Nah. Gtk is fine on it's own, it is just not designed to be used the way it is
used in Emacs. For the Qt that come up in later comments, there is nothing wrong
to rely on a C++ library or libraries, since Emacs is designed to work with GCC
almost exclusively. For example, Emacs already rely on a Rust library
(librsvg). However Qt does not have C interface, it is C++ exclusive library,
and Emacs would probably have same issues with Qt as with Gtk. That is because
Emacs reverse the framowork roles, which does not work always well with toolkits
that are designed to be in driving seat of the application main loop and
display. There is an interesting post about Emacs and how it threats graphical
displays by D. Colascione who I believe implemented, or helped to implement
double buffering in Emacs:

https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10107017870677858%7D&path=%2Fnotes%2Fnote%2F&refsrc=deprecated&_rdr

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[emacsq]

> That is because
> Emacs reverse the framowork roles, which does not work always well with toolkits
> that are designed to be in driving seat of the application main loop and
> display. There is an interesting post about Emacs and how it threats graphical displays by D. Colascione

An excerpt:

"One simple approach to implementing redisplay is to just redraw all the frames, windows, and buffers from scratch. This approach might be good enough for a shitty 2016 video game like Nuclide or Eclipse, but not Emacs.
Emacs was designed for much more constrained systems. Men were men, women were women, and bandwidth was expensive. Consequently, Emacs tries very hard to optimize redisplay."

Since today bandwidth is not expensive, does this mean Emacs could
move avay from the current redisplay to a simpler method which just
redraws everything when required?

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Sat, 19 Feb 2022 19:20:35 +0000
> From: emacsq <laszlomail@protonmail.com>
> Cc: Po Lu <luangruo@yahoo.com>,
>  emacsq via Users list for the GNU Emacs text editor
>  <help-gnu-emacs@gnu.org>
> 
> > That is because
> > Emacs reverse the framowork roles, which does not work always well with toolkits
> > that are designed to be in driving seat of the application main loop and
> > display. There is an interesting post about Emacs and how it threats graphical displays by D. Colascione
> 
> An excerpt:
> 
> "One simple approach to implementing redisplay is to just redraw all the frames, windows, and buffers from scratch. This approach might be good enough for a shitty 2016 video game like Nuclide or Eclipse, but not Emacs.
> Emacs was designed for much more constrained systems. Men were men, women were women, and bandwidth was expensive. Consequently, Emacs tries very hard to optimize redisplay."

This is almost unrelated to the issue at hand, which AFAIU is what
toolkits to use.  Toolkits have almost no role in the Emacs redisplay
and no influence on it

> Since today bandwidth is not expensive, does this mean Emacs could
> move avay from the current redisplay to a simpler method which just
> redraws everything when required?

No.  Redrawing all the windows on all the frames would be unbearably
slow, even today.  A small example: in Emacs, even moving the cursor
one buffer position to the right or to the left triggers a redisplay
cycle.  Redrawing everything upon each cursor movement would be very
slow and will cause an annoying flickering.

Redisplay optimizations still count, even today.  One (but not the
only one) reason is that computers became faster, but people's
expectations from them changed accordingly.  No one would like to have
a 0.5 sec delay in response to some command like cursor motion of
window scroll.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

> That is because Emacs reverse the framowork roles, which does not work
> always well with toolkits that are designed to be in driving seat of
> the application main loop and display. There is an interesting post
> about Emacs and how it threats graphical displays by D. Colascione who
> I believe implemented, or helped to implement double buffering in
> Emacs:
>
> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10107017870677858%7D&path=%2Fnotes%2Fnote%2F&refsrc=deprecated&_rdr

That article is misleading.

The GLib (GTK) event loop is the least of our problems, which is handled
very well with a small amount of code in xgselect.c.  That toolkit has
its own ideas of how not to listen to the programmer which makes it very
annoying to deal with (i.e. in both the X and PGTK builds, it keeps
fighting with Emacs over the size of frames, and it's the only build
where `scroll-bar-width' doesn't work.)

It also has various bugs in features the developers deem uncommon, such
as crashing when a display connection is closed.

Using GTK all by itself also leads to various missing features and
problems with keyboard input.  There was a thread on emacs-devel about
it lately, and countless bug reports, which cannot be resolved.

The event loop is certainly not the problem, since none of these
problems are present in the Haiku port where the event loop for each
window is run by the toolkit itself in a separate thread, or in an X or
Xt build where Emacs drives the event loop with pselect, XPending, and
XtDispatchEvent.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> That is because Emacs reverse the framowork roles, which does not work
>> always well with toolkits that are designed to be in driving seat of
>> the application main loop and display. There is an interesting post
>> about Emacs and how it threats graphical displays by D. Colascione who
>> I believe implemented, or helped to implement double buffering in
>> Emacs:
>>
>> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10107017870677858%7D&path=%2Fnotes%2Fnote%2F&refsrc=deprecated&_rdr
>
> That article is misleading.

Is it?

> The GLib (GTK) event loop is the least of our problems, which is handled
> very well with a small amount of code in xgselect.c.  That toolkit has
> its own ideas of how not to listen to the programmer which makes it very
> annoying to deal with (i.e. in both the X and PGTK builds, it keeps
> fighting with Emacs over the size of frames, and it's the only build
> where `scroll-bar-width' doesn't work.)
>
> It also has various bugs in features the developers deem uncommon, such
> as crashing when a display connection is closed.

Several entire desktops and countless applications implemented with Gtk
for different OS:s certainly speak in favor of your arguments.

Cetainly it must be problem to Gtk and someone elses incompetence, can't be
that Emacs is using it in a manner it wasn't supposed to be used.

> Using GTK all by itself also leads to various missing features and
> problems with keyboard input.  There was a thread on emacs-devel about
> it lately, and countless bug reports, which cannot be resolved.
>
> The event loop is certainly not the problem, since none of these
> problems are present in the Haiku port where the event loop for each
> window is run by the toolkit itself in a separate thread, or in an X or
> Xt build where Emacs drives the event loop with pselect, XPending, and
> XtDispatchEvent.

So Gtk should be designed as Haiku? Otherwise it is a bug? :)

You can either do as you do and consider a framework design to be a bug
because it does not fit into your wishful expectations, or you can recognize
that the design does not fit a particular application in this case Emacs. There
is nothing wrong with that, none framework is required to fit each and every use
case in existence. Emacs uses Gtk in a way it is not supposed to and that
creates some friction. I don't understand why you need to blame that on Gtk? I
am not even very fond of Gtk myself, but there is no reason to be unfair.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sun, 20 Feb 2022 14:46:30 +0100
> Cc: emacsq <laszlomail@protonmail.com>,
>  emacsq via Users list for the GNU Emacs text editor
>  <help-gnu-emacs@gnu.org>
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> >> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10107017870677858%7D&path=%2Fnotes%2Fnote%2F&refsrc=deprecated&_rdr
> >
> > That article is misleading.
> 
> Is it?

You should listen to Po Lu: he knows what he's talking about.

> > The GLib (GTK) event loop is the least of our problems, which is handled
> > very well with a small amount of code in xgselect.c.  That toolkit has
> > its own ideas of how not to listen to the programmer which makes it very
> > annoying to deal with (i.e. in both the X and PGTK builds, it keeps
> > fighting with Emacs over the size of frames, and it's the only build
> > where `scroll-bar-width' doesn't work.)
> >
> > It also has various bugs in features the developers deem uncommon, such
> > as crashing when a display connection is closed.
> 
> Several entire desktops and countless applications implemented with Gtk
> for different OS:s certainly speak in favor of your arguments.
> 
> Cetainly it must be problem to Gtk and someone elses incompetence, can't be
> that Emacs is using it in a manner it wasn't supposed to be used.

How many "other applications" using GTK support dynamic menus and
allow users to create their own menus?  How many "other applications"
using GTK support user-level threads?  How many of them let user code
control the display to a degree that Emacs does?

Yes, Emacs stands out, because it does all of those, and more.

> You can either do as you do and consider a framework design to be a bug
> because it does not fit into your wishful expectations, or you can recognize
> that the design does not fit a particular application in this case Emacs. There
> is nothing wrong with that, none framework is required to fit each and every use
> case in existence. Emacs uses Gtk in a way it is not supposed to and that
> creates some friction. I don't understand why you need to blame that on Gtk? I
> am not even very fond of Gtk myself, but there is no reason to be unfair.

You never tried to futz with the GTK code in Emacs, did you?  It is a
collective experience of several generations of Emacs developers that
GTK uses some techniques that make Emacs's life very difficult.  This
is not about assigning blame, nor about fairness, this is just the
facts of life.  So please understand us when we very much hope a
toolkit emerges that is more "friendly" to Emacs than GTK.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

> GTK uses some techniques that make Emacs's life very difficult.  This
> is not about assigning blame, nor about fairness, this is just the
> facts of life.

Please, how is essence of that different from what I said? Gtk chooses to do
things that does not fit Emacs, i.e, Gtk is not designed to be used the way that
fits Emacs, or with other Words, Emacs use-case does not fit Gtk design.

I opposed to the rhetorics of Po who is blaming it on Gtk bugs and devs having
their own ideas on input, or what he wrote I don't remember, instead of simply
saying that Gtk does not fit Emacs needs. I have tried to say why Gtk and Emacs
does not fit well, instead of leaving the original poster wondering how come
that Gtk was so rough around the edges after more than 20 years of development,
as Po has painted it.

>                 So please understand us when we very much hope a
> toolkit emerges that is more "friendly" to Emacs than GTK.

I think you are missunderstanding me here. I am not arguing for Gtk to become
one and only toolkit in Emacs. I am definitely not the one that favours Gtk as
such for Emacs. I was ranting about Gtk tooltips once, considering that Emacs is
completely capable of rendering tooltips on its own, no idea if you remember. If
you ask me, I would be very happy with Emacs doing its own menus and toolbars,
but that is not gonna happen.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 20 Feb 2022 18:53:45 +0100
> 
> I opposed to the rhetorics of Po who is blaming it on Gtk bugs and devs having
> their own ideas on input, or what he wrote I don't remember, instead of simply
> saying that Gtk does not fit Emacs needs. I have tried to say why Gtk and Emacs
> does not fit well, instead of leaving the original poster wondering how come
> that Gtk was so rough around the edges after more than 20 years of development,
> as Po has painted it.

Well, some of the problems _are_ due to the GTK developers' decisions
about what a GUI program should or should not have.  An example is the
lack of support for dynamic menus.

And you are wrong emphasizing the input issues.  Our problems with GTK
go far beyond that, as I tried to explain.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Sun, 20 Feb 2022 18:53:45 +0100
>> 
>> I opposed to the rhetorics of Po who is blaming it on Gtk bugs and devs having
>> their own ideas on input, or what he wrote I don't remember, instead of simply
>> saying that Gtk does not fit Emacs needs. I have tried to say why Gtk and Emacs
>> does not fit well, instead of leaving the original poster wondering how come
>> that Gtk was so rough around the edges after more than 20 years of development,
>> as Po has painted it.
>
> Well, some of the problems _are_ due to the GTK developers' decisions
> about what a GUI program should or should not have.  An example is the
> lack of support for dynamic menus.

At least it seems like dynamic menus is something they work on:

> You can of course build dynamic menus out of the GMenu and GMenuModel API. The things become slightly more complex if you have extension points, like plugins, that add and remove menus and menu items depending on whether they have been enabled or disabled at run time. We lack a decent API for that.

> AFAIR, @hergertme had some wrapper API for GNOME Builder; I think we could expand the API in GIO to have a better story for extensible menus.

From: https://discourse.gnome.org/t/gtk4-and-dynamical-menus/8529/3

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

>> You can of course build dynamic menus out of the GMenu and
>> GMenuModel API. The things become slightly more complex if you have
>> extension points, like plugins, that add and remove menus and menu
>> items depending on whether they have been enabled or disabled at run
>> time. We lack a decent API for that.

That isn't an option.  You cannot attach arbitrary data to such menus,
only a GVariant that can be serialized to disk (or stored in HTML).

The programmatic GMenu and GMenuModel API also leaves much else to be
desired.  It is slow, involves recreating the menu bar widget every time
something changes, and makes it impossible to create menu elements such
as checkboxes which are possible in the XML-based API.

`hidden-when' isn't an option, since there is no way to record all the
information required for Emacs's very deeply nested menus.

After struggling with both interfaces in my GTK 4 port, I decided to
create two separate widgets, LwPopupMenu and LwMenuBar, which build
their menu contents dynamically based on the contents of a
`widget_value'.  It cannot look and behave exactly like the native GTK 4
menus, is a lot of code to maintain (and it was already broken once by
the changes to layout processing in GTK 4.4), but it's the best that can
be done in GTK 4.

Meanwhile, the GtkMenu interface that we have used all the way back to
GTK+ 2.x works fine, but was deleted by the GTK developers for GTK 4.

>> AFAIR, @hergertme had some wrapper API for GNOME Builder; I think we
>> could expand the API in GIO to have a better story for extensible
>> menus.

I won't be convinced until I see such an expansion.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> That isn't an option.  You cannot attach arbitrary data to such menus,
> only a GVariant that can be serialized to disk (or stored in HTML).
                                                               ^^^^
Sorry, this should have been "XML".

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>>> You can of course build dynamic menus out of the GMenu and
>>> GMenuModel API. The things become slightly more complex if you have
>>> extension points, like plugins, that add and remove menus and menu
>>> items depending on whether they have been enabled or disabled at run
>>> time. We lack a decent API for that.
>
> That isn't an option.  You cannot attach arbitrary data to such menus,
> only a GVariant that can be serialized to disk (or stored in HTML).
>
> The programmatic GMenu and GMenuModel API also leaves much else to be
> desired.  It is slow, involves recreating the menu bar widget every time
> something changes, and makes it impossible to create menu elements such
> as checkboxes which are possible in the XML-based API.
>
> `hidden-when' isn't an option, since there is no way to record all the
> information required for Emacs's very deeply nested menus.
>
> After struggling with both interfaces in my GTK 4 port, I decided to
> create two separate widgets, LwPopupMenu and LwMenuBar, which build
> their menu contents dynamically based on the contents of a
> `widget_value'.  It cannot look and behave exactly like the native GTK 4
> menus, is a lot of code to maintain (and it was already broken once by
> the changes to layout processing in GTK 4.4), but it's the best that can
> be done in GTK 4.
>
> Meanwhile, the GtkMenu interface that we have used all the way back to
> GTK+ 2.x works fine, but was deleted by the GTK developers for GTK 4.

I understand; but they have probably changed API because of some reason that
suits their goals. Every project prioritize their own goals, that is how life
is. They certainly didn't do it to piss off Emacs devs.

>>> AFAIR, @hergertme had some wrapper API for GNOME Builder; I think we
>>> could expand the API in GIO to have a better story for extensible
>>> menus.
>
> I won't be convinced until I see such an expansion.

It looks to me more like an invite to contribute an API, so there is your chance
to get it the way you like. 

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

> I understand; but they have probably changed API because of some
> reason that suits their goals. Every project prioritize their own
> goals, that is how life is. They certainly didn't do it to piss off
> Emacs devs.

Where did we say they did it to piss off Emacs developers?  We simply
wish that a toolkit friendlier to Emacs will emerge at some point and
become as popular as GTK is.

> It looks to me more like an invite to contribute an API, so there is
> your chance to get it the way you like.

It would involve reverting several changes that were installed for GTK
4, which I'm sure they're not willing to take.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I understand; but they have probably changed API because of some
>> reason that suits their goals. Every project prioritize their own
>> goals, that is how life is. They certainly didn't do it to piss off
>> Emacs devs.
>
> Where did we say they did it to piss off Emacs developers?  We simply
> wish that a toolkit friendlier to Emacs will emerge at some point and
> become as popular as GTK is.
>
>> It looks to me more like an invite to contribute an API, so there is
>> your chance to get it the way you like.
>
> It would involve reverting several changes that were installed for GTK
> 4, which I'm sure they're not willing to take.

Why designing an API means reverting changes? I dont' think designing an API is
reverting it back to old API.

Anyway, summarizing all you write her eand in other mails, it is
where the thread initially started, Gtk is not designed to be used the way Emacs
would like it. Gtk works fine for applications that use it the way it is
designed, Emacs has different needs and it does not work well for Emacs.

You call it a bug, they call it design, and there I think is the friction.

Is there a way to reproduce this bug on a singel machine with one monitor?

Can I do it from within a virtual machine(s) or somethinig? I am not so familiar
with setting up networks and virtual machines and such.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

> Why designing an API means reverting changes? I dont' think designing
> an API is reverting it back to old API.

Because the API we need is precisely the one that was deleted.  On
purpose.

> Is there a way to reproduce this bug on a singel machine with one
> monitor?

Yes: run Xephyr (or Xnest) like this:

  Xephyr :2

Then select File -> New frame on Display Server from the menu bar, enter
:2, then close the Xephyr window.  Emacs will either abort (on the X and
GTK build), or simply exit without warning (on the PGTK build.)

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Why designing an API means reverting changes? I dont' think designing
>> an API is reverting it back to old API.
>
> Because the API we need is precisely the one that was deleted.  On
> purpose.

They have obviously had reasons to delete it. That the "design" part :).

And as the quoted (and linked) answer from Bassi shows, they are not against the
API, they want better one. So it would be more constructive to help them desing
a new API in accordance to the new GTK design, than complaning and being grumpy
about the old API. They obviously won't put back the old API, they wouldn't
delete in the first place if that would be the case. There is actually a
chance that you can affect the desing of Gtk so it suites better Emacs needs,
but you are refusing under different excuses.

>> Is there a way to reproduce this bug on a singel machine with one
>> monitor?
>
> Yes: run Xephyr (or Xnest) like this:
>
>   Xephyr :2
>
> Then select File -> New frame on Display Server from the menu bar, enter
> :2, then close the Xephyr window.  Emacs will either abort (on the X and
> GTK build), or simply exit without warning (on the PGTK build.)

Ok, thanks, I'll try with Xephyr and Gtk.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[tomas]

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

On Sun, Feb 20, 2022 at 06:53:45PM +0100, Arthur Miller wrote:

[...]

> I opposed to the rhetorics of Po who is blaming it on Gtk bugs and devs having
> their own ideas on input [...]

Now we're in blame territory. The "close X display thing" is actually a
long standing Gtk bug (around Gtk 2). X programs could always connect to
more than one display, and could close one or more of them. Gtk chose
to just crash the program when closing a display. This was acknowledged
as a bug, but never fixed.

Have a look here [1] for that long winded history.

Now you can describe calling this "a bug" as rhethoric, but to me, a
spade is a spade is a spade. Don't get me wrong: the Gtk people are
in their full right to WONTFIX this, of course.

Cheers

[1] https://bugzilla.gnome.org/show_bug.cgi?id=85715

-- 
t

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

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Sun, Feb 20, 2022 at 06:53:45PM +0100, Arthur Miller wrote:
>
> [...]
>
>> I opposed to the rhetorics of Po who is blaming it on Gtk bugs and devs having
>> their own ideas on input [...]
>
> Now we're in blame territory. The "close X display thing" is actually a
> long standing Gtk bug (around Gtk 2). X programs could always connect to
> more than one display, and could close one or more of them. Gtk chose
> to just crash the program when closing a display. This was acknowledged
> as a bug, but never fixed.
>

It was the only one concrete mentioned, but there were also words like "various"
and some other statments on devs having strange ideas, not working well on
Windows, while it seems to work fine for many applications etc.

> Have a look here [1] for that long winded history.

Thank you for the link.

> Now you can describe calling this "a bug" as rhethoric, but to me, a
> spade is a spade is a spade. Don't get me wrong: the Gtk people are
> in their full right to WONTFIX this, of course.

 I don't see it as a "wontfix", it looks to me like they
are just asking for more comprehensible stack traces:

> Emacs calls abort() when closing the display to deal with something that GTK 2 did when coupled with Emacs's own client/server architecture where any process can suddenly become the owner of a display connection. People keep posting useless stack traces that end with the intentional abort() call inside Emacs, useless comments about "this still happens to me" (yes: Emacs still calls abort()), or any other random Emacs stack trace coming from any other random issue they have.

> GDK could use somebody going through the code with a smaller test case than the whole of Emacs, to check if closing a display connection on different backends breaks the existing API contract. If that happens:

>    open a new bug
>    track the stack traces and see where we're trying to access a display post-closure
>    possibly open a merge request that fixes all the instances

> Until that time, I'm going to close this issue because it's ridiculous.

Quoted from: https://gitlab.gnome.org/GNOME/gtk/-/issues/221

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[tomas]

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

On Sun, Feb 20, 2022 at 07:57:30PM +0100, Arthur Miller wrote:

[...]

>  I don't see it as a "wontfix", it looks to me like they
> are just asking for more comprehensible stack traces:

That's exactly how I read this long-winded bug thread.
> 
> > Emacs calls abort()  [...]

Note that Emacs calls that abort to not run into this
bug. This is explicitly mentioned in the thread.

Cheers
-- 
t

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

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

tomas@tuxteam.de writes:

> Note that Emacs calls that abort to not run into this bug. This is
> explicitly mentioned in the thread.

More history: Emacs used to call signal to break out of the X error
handler before GDK had a chance to call _exit.  Until recently a longjmp
out of the GLib event loop would only cause lots of warnings to be
printed, so that call to signal would avoid the code path where GDK
would deliberately shut down the application.

That was replaced by a call to abort some time ago since the warnings
tended to make Emacs slow and flood .Xsession-errors with up to 50 GBs
of warning messages.  But since recently the call to signal cannot work
anymore, since GLib will immediately crash upon next entering its event
loop.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[tomas]

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

On Mon, Feb 21, 2022 at 09:18:17AM +0800, Po Lu wrote:
> tomas@tuxteam.de writes:
> 
> > Note that Emacs calls that abort to not run into this bug. This is
> > explicitly mentioned in the thread.
> 
> More history: Emacs used to call signal to break out of the X error
> handler before GDK had a chance to call _exit [...]

Thanks for that history :)

Cheers
-- 
t

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

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

<tomas@tuxteam.de> writes:

> Now we're in blame territory. The "close X display thing" is actually a
> long standing Gtk bug (around Gtk 2). X programs could always connect to
> more than one display, and could close one or more of them. Gtk chose
> to just crash the program when closing a display. This was acknowledged
> as a bug, but never fixed.

FTR, the longer explanation is that GTK+ originally didn't have the
ability to connect to multiple displays, so that was missing from the
GTK+ build of Emacs for a long time.  At some point in the GTK+ 2.x
release cycle (2.6 or 2.8, AFAIR), such a feature was implemented, but
people soon discovered that closing a display would cause a crash in the
toolkit.  That was actually fixed for a couple of releases but soon
reappeared, after which their developers stopped wanting to fix that
bug.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

> Is it?

It is.

> Several entire desktops and countless applications implemented with
> Gtk for different OS:s certainly speak in favor of your arguments.

Emacs is more complicated and demanding a program than most of those
desktops and applications.  For instance, they typically don't support
connecting to and displaying windows on multiple displays from the same
process.

> Cetainly it must be problem to Gtk and someone elses incompetence,
> can't be that Emacs is using it in a manner it wasn't supposed to be
> used.

So we should limit our features to what GTK provides?  Just to name a
few, that would entail removing support for multi-TTY, distinguishing
"C-S-u" from "C-u", controlling the size of scroll bars, reliable
control over frame size?

If you want such an experience, by all means use the PGTK build.  But
those features are important to many other people, so we cannot rely on
PGTK.

> So Gtk should be designed as Haiku? Otherwise it is a bug? :)

I'm not, but the problem has nothing to do with how Emacs handles the
toolkit event loop.

> You can either do as you do and consider a framework design to be a
> bug because it does not fit into your wishful expectations

I expect a toolkit which people expect to become the basis of the Emacs
GUI to be designed suitably, which is hardly wishful thinking.

> or you can recognize that the design does not fit a particular
> application in this case Emacs. There is nothing wrong with that, none
> framework is required to fit each and every use case in
> existence. Emacs uses Gtk in a way it is not supposed to and that
> creates some friction.

Whether or not it's suitable for other applications, the friction
between Emacs and GTK cannot be resolved, so that indeed makes GTK
unsuitable as the sole window system for Emacs.

> I don't understand why you need to blame that on Gtk? I am not even
> very fond of Gtk myself, but there is no reason to be unfair.

When a toolkit that is part of the GNU project makes deliberate design
decisions which prevents it from being used to implement Emacs, I think
it is quite right to complain.  Especially when older versions of said
toolkit used to work fine.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Is it?
>
> It is.
>
>> Several entire desktops and countless applications implemented with
>> Gtk for different OS:s certainly speak in favor of your arguments.
>
> Emacs is more complicated and demanding a program than most of those
> desktops and applications.  For instance, they typically don't support
> connecting to and displaying windows on multiple displays from the same
> process.

>> Cetainly it must be problem to Gtk and someone elses incompetence,
>> can't be that Emacs is using it in a manner it wasn't supposed to be
>> used.
>
> So we should limit our features to what GTK provides?  Just to name a
> few, that would entail removing support for multi-TTY, distinguishing
> "C-S-u" from "C-u", controlling the size of scroll bars, reliable
> control over frame size?
>
> If you want such an experience, by all means use the PGTK build.  But
> those features are important to many other people, so we cannot rely on
> PGTK.
>
>> So Gtk should be designed as Haiku? Otherwise it is a bug? :)
>
> I'm not, but the problem has nothing to do with how Emacs handles the
> toolkit event loop.
>
>> You can either do as you do and consider a framework design to be a
>> bug because it does not fit into your wishful expectations
>
> I expect a toolkit which people expect to become the basis of the Emacs
> GUI to be designed suitably, which is hardly wishful thinking.

I think you will have to reflect on what I have said. I have posted an article
about why Emacs is not very compatible with Gtk, and probably wouldn't be
compatible with Qt either, even if there was a suitable C interface Emacs could
use. We can certainly agree to disagree about the article, but you should
definitely reflect better over what I wrote and why. I didn't lobbied for Gtk to
become the one and only toolkit to use, I just opposed your rhetorics about Gtk
bugs, "devs strange ideas" and what not, and the impression you left on the
person. I am not trying to be impolite or unrespectful, but I find your
arguments and rhetorics often dogmatic.

>> or you can recognize that the design does not fit a particular
>> application in this case Emacs. There is nothing wrong with that, none
>> framework is required to fit each and every use case in
>> existence. Emacs uses Gtk in a way it is not supposed to and that
>> creates some friction.
>
> Whether or not it's suitable for other applications, the friction
> between Emacs and GTK cannot be resolved, so that indeed makes GTK
> unsuitable as the sole window system for Emacs.

Sure we can agree on that one. But you used rhetorics that left impression it
depends on bugs, and Gtk devs having their own strange ideas about
something. Those are different reasons but not being suitable by design. Read my
very first replay in this thread, it should have been clear there.

>> I don't understand why you need to blame that on Gtk? I am not even
>> very fond of Gtk myself, but there is no reason to be unfair.
>
> When a toolkit that is part of the GNU project makes deliberate design
> decisions which prevents it from being used to implement Emacs, I think
> it is quite right to complain.

Why would it be a right to complain? There are many other libraries and
frameworks that are not suitable for use in Emacs. It is no ones obligation to
make their software fit someones particular needs. I am quite sure they are
trying to make it usable for the most applications out there. If Emacs is not
one of those, so be it. But it is not their obligation to make it usable for
each and every application under the Sun either, just like Emacs does not have
obligation to fit into everyones wishes and desires either.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

> I think you will have to reflect on what I have said. I have posted an
> article about why Emacs is not very compatible with Gtk, and probably
> wouldn't be compatible with Qt either, even if there was a suitable C
> interface Emacs could use. We can certainly agree to disagree about
> the article, but you should definitely reflect better over what I
> wrote and why. I didn't lobbied for Gtk to become the one and only
> toolkit to use, I just opposed your rhetorics about Gtk bugs, "devs
> strange ideas" and what not, and the impression you left on the
> person. I am not trying to be impolite or unrespectful, but I find
> your arguments and rhetorics often dogmatic.

Your argument can only be convincing if you have spent most of the past
week dealing with various instances of using GTK interfaces such as
`gtk_window_set_geometry_hints' according to their documentation, only
to see them do something completely different.

I have.  And I'm not convinced.

> Sure we can agree on that one. But you used rhetorics that left
> impression it depends on bugs, and Gtk devs having their own strange
> ideas about something. Those are different reasons but not being
> suitable by design. Read my very first replay in this thread, it
> should have been clear there.

Many of the problems in GTK affecting Emacs are bugs contradicting their
documented behavior that the GTK developers don't want to fix, since
they find Emacs not sufficiently important.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I think you will have to reflect on what I have said. I have posted an
>> article about why Emacs is not very compatible with Gtk, and probably
>> wouldn't be compatible with Qt either, even if there was a suitable C
>> interface Emacs could use. We can certainly agree to disagree about
>> the article, but you should definitely reflect better over what I
>> wrote and why. I didn't lobbied for Gtk to become the one and only
>> toolkit to use, I just opposed your rhetorics about Gtk bugs, "devs
>> strange ideas" and what not, and the impression you left on the
>> person. I am not trying to be impolite or unrespectful, but I find
>> your arguments and rhetorics often dogmatic.
>
> Your argument can only be convincing if you have spent most of the past
> week dealing with various instances of using GTK interfaces such as
> `gtk_window_set_geometry_hints' according to their documentation, only
> to see them do something completely different.
>
> I have.  And I'm not convinced.
>
>> Sure we can agree on that one. But you used rhetorics that left
>> impression it depends on bugs, and Gtk devs having their own strange
>> ideas about something. Those are different reasons but not being
>> suitable by design. Read my very first replay in this thread, it
>> should have been clear there.
>
> Many of the problems in GTK affecting Emacs are bugs contradicting their
> documented behavior that the GTK developers don't want to fix, since
> they find Emacs not sufficiently important.

I don't see them saying we won't fix this, nor that Emacs is not important, 2315
is still open.

What I also see myself is that for about last ~15 years, it is only Emacs
users that seems to be affected by this bugs.

I have read, just of my own curiosity through entire of those bug
threads:

https://gitlab.gnome.org/GNOME/gtk/-/issues/221
https://gitlab.gnome.org/GNOME/gtk/-/issues/2315

What I see them say, more or less is help us to help you. I won't say it is bug
in Emacs nor will I say it is bug in Gtk, I'll just say leave some reservation
that Emacs could maybe could do something else. You seem to be very knowledgable
about Gtk and Eli says you know what you are doing, have you try to work with
them to solve the problem?

But maybe for Emacs devs this is not important either, in which case we are just
arguing about smoke :).

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

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

> I don't see them saying we won't fix this, nor that Emacs is not
> important, 2315 is still open.
>
> What I also see myself is that for about last ~15 years, it is only
> Emacs users that seems to be affected by this bugs.

Because Emacs is the only program that will be affected by these bugs?
And the program the GTK+ multi-display API was created for in the first
place, AFAIR.

> What I see them say, more or less is help us to help you. I won't say
> it is bug in Emacs nor will I say it is bug in Gtk, I'll just say
> leave some reservation that Emacs could maybe could do something else.
> You seem to be very knowledgable about Gtk and Eli says you know what
> you are doing, have you try to work with them to solve the problem?

What extra help could we offer?  That bug has been trivially
reproducible (and not just via Emacs) for the past 15+ years.

It was even fixed for a few releases of GTK+ before it reappeared.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Max Brieiev]

Po Lu <luangruo@yahoo.com> writes:

> So we should limit our features to what GTK provides?  Just to name a
> few, that would entail removing support for multi-TTY, distinguishing
> "C-S-u" from "C-u", controlling the size of scroll bars, reliable
> control over frame size?
>
> If you want such an experience, by all means use the PGTK build.  But
> those features are important to many other people, so we cannot rely on
> PGTK.

From what I have read in this thread, does it mean that `--with-pgtk`
build is less featureful (more buggy?) than "non-pure" build?

And as a consequence, does it mean that Emacs on Wayland is more quirky
than on X, due to the "problems" with GTK?

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

Max Brieiev <max.brieiev@gmail.com> writes:

> From what I have read in this thread, does it mean that `--with-pgtk`
> build is less featureful (more buggy?) than "non-pure" build?

Yes, and that non-pure build will generally work worse than a Lucid or
Motif build.

> And as a consequence, does it mean that Emacs on Wayland is more
> quirky than on X, due to the "problems" with GTK?

Indeed.  And some of the problem lies with the Wayland protocol as well.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Byung-Hee HWANG]

Po Lu <luangruo@yahoo.com> writes:

> Max Brieiev <max.brieiev@gmail.com> writes:
>
>> [...]
>> And as a consequence, does it mean that Emacs on Wayland is more
>> quirky than on X, due to the "problems" with GTK?
>
> Indeed.  And some of the problem lies with the Wayland protocol as well.

Really i would be to use pgtk things,
so when will the 28.1 (GNU Emacs) be released?

(and thanks for the explanation Po ^^^)

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

Byung-Hee HWANG <soyeomul@doraji.xyz> writes:

> Really i would be to use pgtk things,
> so when will the 28.1 (GNU Emacs) be released?

The PGTK port will not be part of Emacs 28.1, you will need to wait for
Emacs 29.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Byung-Hee HWANG]

Po Lu <luangruo@yahoo.com> writes:

> Byung-Hee HWANG <soyeomul@doraji.xyz> writes:
>
>> Really i would be to use pgtk things,
>> so when will the 28.1 (GNU Emacs) be released?
>
> The PGTK port will not be part of Emacs 28.1, you will need to wait for
> Emacs 29.

Ah... yes! I'll wait for Emacs 29!

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Byung-Hee HWANG <soyeomul@doraji.xyz> [2022-02-22 15:42]:
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Byung-Hee HWANG <soyeomul@doraji.xyz> writes:
> >
> >> Really i would be to use pgtk things,
> >> so when will the 28.1 (GNU Emacs) be released?
> >
> > The PGTK port will not be part of Emacs 28.1, you will need to wait for
> > Emacs 29.
> 
> Ah... yes! I'll wait for Emacs 29!

Come on, just use 🐃 Emacs development version:

(emacs-version) ⇒ "GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
 of 2022-02-18"

$ git clone git://git.sv.gnu.org/emacs.git

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Byung-Hee HWANG]

Jean Louis <bugs@gnu.support> writes:

> * Byung-Hee HWANG <soyeomul@doraji.xyz> [2022-02-22 15:42]:
>> Po Lu <luangruo@yahoo.com> writes:
>> 
>> > Byung-Hee HWANG <soyeomul@doraji.xyz> writes:
>> >
>> >> Really i would be to use pgtk things,
>> >> so when will the 28.1 (GNU Emacs) be released?
>> >
>> > The PGTK port will not be part of Emacs 28.1, you will need to wait for
>> > Emacs 29.
>> 
>> Ah... yes! I'll wait for Emacs 29!
>
> Come on, just use 🐃 Emacs development version:
>
> (emacs-version) ⇒ "GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
>  of 2022-02-18"
>
> $ git clone git://git.sv.gnu.org/emacs.git

Hellow Jean!

Thanks for guidance! However, still i'm beginner in Emacs.

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Byung-Hee HWANG <soyeomul@doraji.xyz> [2022-02-22 15:03]:
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Max Brieiev <max.brieiev@gmail.com> writes:
> >
> >> [...]
> >> And as a consequence, does it mean that Emacs on Wayland is more
> >> quirky than on X, due to the "problems" with GTK?
> >
> > Indeed.  And some of the problem lies with the Wayland protocol as well.
> 
> Really i would be to use pgtk things,
> so when will the 28.1 (GNU Emacs) be released?

You can always use Emacs Development version and all of the new
un-released features. That is what I use.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

Some comparison of toolkits:

GUI Toolkit Comparison - LXDE.org
https://wiki.lxde.org/en/GUI_Toolkit_Comparison


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Samuel Banya]

Not going to lie, but this discussion between the great Linux greybeard wizards has been fascinating.

Just wanted to put it out there that you guys are awesome :)

Thanks for the inputs on all sides, very cool to see these perspectives.

Sincerely,

Sam

On Sun, Feb 20, 2022, at 9:12 AM, Jean Louis wrote:
> Some comparison of toolkits:
> 
> GUI Toolkit Comparison - LXDE.org
> https://wiki.lxde.org/en/GUI_Toolkit_Comparison
> 
> 
> -- 
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/
> 
> 

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Sergey Organov]

Po Lu <luangruo@yahoo.com> writes:

> emacsq via Users list for the GNU Emacs text editor
> <help-gnu-emacs@gnu.org> writes:
>
>>> Indeed, GTK is cross-platform and available for Linux and other
>>> systems as well.
>
>> Right, so would it be advantageous for emacs to use the same code for
>> graphic UI on every OS, or is there something which emacs can
>> currently do by accessing the native APIs directly which cannot be
>> done via GTK?
>
> It isn't available on Haiku and doesn't work very well on MS-Windows,
> macOS, and even GNU/Linux.
>

I was under impression that GIMP uses GTK and then it works fine for me
on at least GNU/Linux and MS-Windows. Is Emacs more demanding than GIMP?

Thanks,
-- Sergey Organov

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Po Lu]

Sergey Organov <sorganov@gmail.com> writes:

> I was under impression that GIMP uses GTK and then it works fine for me
> on at least GNU/Linux and MS-Windows. Is Emacs more demanding than GIMP?

Indeed.  Some trivial examples: interrupt-based input cannot work
outside Wayland and X11 in the PGTK build, and the GTK input methods
process keys in such a way that information important to Emacs is lost.

And there's also the show-stopper bug where GTK crashes when a display
connection is closed, which also affects the regular GTK build.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Byung-Hee HWANG]

Sergey Organov <sorganov@gmail.com> writes:

> [...]
> I was under impression that GIMP uses GTK and then it works fine for me
> on at least GNU/Linux and MS-Windows. Is Emacs more demanding than GIMP?

+1; and thanks!

> Thanks,
> -- Sergey Organov

Sincerely, GTK fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Fri, 18 Feb 2022 20:59:38 +0000
> From:  emacsq via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Just wondering if a free toolkit like Gtk supports multiple platforms out of the box then would it make sense to use the same GTK-based code on every graphical platform? So using the same toolkit for everything graphics, instead of implementing features for windows, linux, etc. separately?

Emacs currentl;y supports building with GTK only on GNU and Unix
systems.

> Is there something which native UI code does in emacs UI which GTK could not support?

GTK has many problems, so I very much hope the future of Emacs is not
with GTK, but with some better toolkit.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> Emacs currentl;y supports building with GTK only on GNU and
> Unix systems.

:)

George W Bush was once asked on a press conference what
journalists eat. He answered, "They eat cheese and Brie"

:)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Sat, 19 Feb 2022 08:38:09 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Eli Zaretskii wrote:
> 
> > Emacs currently supports building with GTK only on GNU and
> > Unix systems.
> 
> :)
> 
> George W Bush was once asked on a press conference what
> journalists eat. He answered, "They eat cheese and Brie"

Are you sure the joke isn't on you?

The first line of the GNU Manifesto says:

    What's GNU? Gnu's Not Unix!

(https://www.gnu.org/gnu/manifesto.en.html)

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>>> Emacs currently supports building with GTK only on GNU and
>>> Unix systems.
>> 
>> George W Bush was once asked at a press conference what
>> journalists eat. He answered, "They eat cheese and Brie" :)
>
> Are you sure the joke isn't on you?
>
> The first line of the GNU Manifesto says:
>
>     What's GNU? Gnu's Not Unix!

_That_'s the joke ...

GNU isn't UNIX but it sure is Unix!

As is Linux ...

See that "x"? Ever contemplated what that means? X marks
the unknown?

So GNU/Linux that's even Unix**2 ...

OpenBSD and so on are also Unix. But not macOS or Android, how
ever that would work? Don't be silly ...

POSIX = Portable Operating System Interface, coined by RMS ...
or am I wrong?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Sat, 19 Feb 2022 10:09:01 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Eli Zaretskii wrote:
> 
> > The first line of the GNU Manifesto says:
> >
> >     What's GNU? Gnu's Not Unix!
> 
> _That_'s the joke ...

Not really.  The _acronym_ is a joke, but not the idea.

> GNU isn't UNIX but it sure is Unix!
> 
> As is Linux ...

No, they aren't.  The kernel is very different, most of the utilities
are very different, etc.

> POSIX = Portable Operating System Interface, coined by RMS ...
> or am I wrong?

You are wrong.  POSIX indeed covers both Unix and GNU systems, so if I
said "POSIX and GNU", that would be a funny mistake.  But that's not
what I said.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>>> The first line of the GNU Manifesto says:
>>>
>>>     What's GNU? Gnu's Not Unix!
>> 
>> _That_'s the joke ...
>
> Not really. The _acronym_ is a joke, but not the idea.

The acronym is a joke and the joke is/conveys the correct,
non-joke idea and goal of the whole project, namely that GNU
both _isn't_ Unix (i.e. AT&T's proprietary version) yet _is_
or intends to be a NEW, free Unix.

>> GNU isn't UNIX but it sure is Unix!
>> 
>> As is Linux ...
>
> No, they aren't. The kernel is very different, most of the
> utilities are very different, etc.

GNU has a maximalist approach so there are more options than
for example in the BSD toolchain, as they have a minimalist
approach. The kernels (Linux, the BSD kernel whatever it/they
are called, Hurd etc) are different since they are different,
separate projects. But that's the _implementation_ side,
implementations will always differ, what is alike isn't the
implementations but what they implement, which is a Unix
system. Note that alike does not mean "the same" or
"identical", they are alike in the sense they all implement
and make possible Unix systems, thus they are all Unix.

>> POSIX = Portable Operating System Interface, coined by RMS
>> ... or am I wrong?
>
> You are wrong. POSIX indeed covers both Unix and GNU
> systems, so if I said "POSIX and GNU", that would be a funny
> mistake. But that's not what I said.

GNU is not just a microkernel but also a toolchain
of software. Both are Unix, and bundle them up you get
a Unix system. But there are other kernels, including several
monolithic kernels that you might have heard of, that are also
Unix since they are implementation of the Unix model just as
much, i.e. IPC, PCBs, pipes, etc etc etc, and if they are
combined with the GNU toolchain they are also, just as much,
Unix + Unix = Unix.

Unix is a family of systems, they are all just as much Unix.

Have you ever heard of the United states of America?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Pankaj Jangid]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>>     What's GNU? Gnu's Not Unix!
>
> _That_'s the joke ...
>
> GNU isn't UNIX but it sure is Unix!
>
> As is Linux ...

GNU utilities do make it appear like that. Otherwise, even the most
basic shell commands are incompatible - ls/xargs/find...

And Linux is a kernel.

> See that "x"? Ever contemplated what that means? X marks
> the unknown?
>
> So GNU/Linux that's even Unix**2 ...
>
> OpenBSD and so on are also Unix. But not macOS or Android, how
> ever that would work? Don't be silly ...
>
> POSIX = Portable Operating System Interface, coined by RMS ...
> or am I wrong?

If GNU were UNIX, then there was no need for POSIX.

I am talking purely from the user’s point-of-view. If we talk about the
idea then the gap is even wider.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Pankaj Jangid wrote:

>>> What's GNU? Gnu's Not Unix!
>>
>> _That_'s the joke ...
>>
>> GNU isn't UNIX but it sure is Unix!
>>
>> As is Linux ...
>
> GNU utilities do make it appear like that. Otherwise, even
> the most basic shell commands are incompatible -
> ls/xargs/find...

But that's the way you do it. Uniform base,
specialized superstructure.

See this for tools, machines and other gear:
  https://en.wikipedia.org/wiki/French_cleat

Or in sports. The team is organized with a collective of basic
technicians, full-blooded professionals that do the simple
things the right way without hesitation, with confidence and
force.

However an individual player ... can be creative and break the
pattern to add variety, the unexpected to their game, maybe
sometimes even brilliant and unique attack vectors never heard
of until then ...

You have to have both!

> And Linux is a kernel.

...

> If GNU were UNIX, then there was no need for POSIX.

POSIX is a family of standards. GNU is an implementation of an
operating system concept. So it is up to the people active
doing that to what degree what standards should
be implemented ...

(Note that standards that are not implemented, let's say not
even once, that doesn't mean they have no value.)

> I am talking purely from the user’s point-of-view. If we
> talk about the idea then the gap is even wider.

Gaps are wider here and smaller there. It happens all the time
and changes all the time. Don't worry about them. And if they
get too wide to jump across, let's climb down instead and
examine what cool stuff are down there ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-19 12:17]:
> Eli Zaretskii wrote:
> 
> >>> Emacs currently supports building with GTK only on GNU and
> >>> Unix systems.
> >> 
> >> George W Bush was once asked at a press conference what
> >> journalists eat. He answered, "They eat cheese and Brie" :)
> >
> > Are you sure the joke isn't on you?
> >
> > The first line of the GNU Manifesto says:
> >
> >     What's GNU? Gnu's Not Unix!
> 
> _That_'s the joke ...
> 
> GNU isn't UNIX but it sure is Unix!

Come on, impossible. Unix is only operating system that fits into some
Unix standards by those who have Unix trademark.

GNU does not fit. It is Unix-like or similar to Unix. But it is not
Unix.

I am sure that GNU on Linux kernel does not follow this below:

Single UNIX Specification - Wikipedia
https://en.wikipedia.org/wiki/Single_UNIX_Specification

Though GNU is Unix-like, that is what society of computer users agree
to call it that way.

If you ask me, hippopotamus is rhinoceros-like to me, but they are not
same.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> GNU isn't UNIX but it sure is Unix!
>
> Come on, impossible. Unix is only operating system that fits
> into some Unix standards by those who have Unix trademark.

Unix was freed and reimplemented in many forms by the efforts
of tons of people all over the world, these people include the
GNU, BSD and Linux people but also our efforts writing
Elisp yesterday. It is aaaall interconnected, OMG what
a realization!

But relax - if you manage to write Elisp that changes the
GNU/Linux Unix to a point it isn't Unix anymore, I'll call
you out in front of everyone. "You are out of line, son.
One more line of that and you are _cut off_. You will not be
using Unix anymore, ever; because you are are not allowed
to return. God be with ye!"

> GNU does not fit. It is Unix-like or similar to Unix. But it
> is not Unix.

A standard is a piece of paper, an OS concept implementation
is a computer. It is just a matter of greedy people
wanting money, don't fall for that.

> I am sure that GNU on Linux kernel does not follow this below:
>
> Single UNIX Specification - Wikipedia
> https://en.wikipedia.org/wiki/Single_UNIX_Specification

It was a lie, Jean. The standard was never meant to
do anything. It was just another system of control ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-20 01:43]:
> Jean Louis wrote:
> 
> >> GNU isn't UNIX but it sure is Unix!
> >
> > Come on, impossible. Unix is only operating system that fits
> > into some Unix standards by those who have Unix trademark.
> 
> Unix was freed and reimplemented in many forms by the efforts
> of tons of people all over the world, these people include the
> GNU, BSD and Linux people but also our efforts writing
> Elisp yesterday. It is aaaall interconnected, OMG what
> a realization!

Yes. Unix-like free operating systems were made to be more or less
Unix compatible for sake of freedom.

> But relax - if you manage to write Elisp that changes the
> GNU/Linux Unix to a point it isn't Unix anymore, I'll call
> you out in front of everyone. "You are out of line, son.
> One more line of that and you are _cut off_. You will not be
> using Unix anymore, ever; because you are are not allowed
> to return. God be with ye!"

😈

> > GNU does not fit. It is Unix-like or similar to Unix. But it
> > is not Unix.
> 
> A standard is a piece of paper, an OS concept implementation
> is a computer. It is just a matter of greedy people
> wanting money, don't fall for that.

Of course it is about money. They make specification ABC to get money
out of using the specification. I do understand it. That however, does
not say that GNU complies to specification ABC.

You have specification XYZ, which however, is not yet published, and
determines that GNU is Unix. How about telling us closely about it?


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Of course it is about money. They make specification ABC to
> get money out of using the specification. I do understand
> it. That however, does not say that GNU complies to
> specification ABC.

It isn't about money, trust me FOSS world work hours divided
... uhm

Sum closes in on 0 cent LOL

> You have specification XYZ, which however, is not yet
> published, and determines that GNU is Unix. How about
> telling us closely about it?

That question, is it really a question? And if not, does that
make it a question-like question?

And whose questions are you calling rhetorical?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-02-19 10:34]:
> > Date: Fri, 18 Feb 2022 20:59:38 +0000
> > From:  emacsq via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> > 
> > Just wondering if a free toolkit like Gtk supports multiple platforms out of the box then would it make sense to use the same GTK-based code on every graphical platform? So using the same toolkit for everything graphics, instead of implementing features for windows, linux, etc. separately?
> 
> Emacs currentl;y supports building with GTK only on GNU and Unix
> systems.

That means on Unix-like systems. It is better expressed that way. GNU
is Not Unix, true, though it is very much Unix-like, such systems are
mentioned as Unices if I remember well. 

GNU is Unix-like and there are variations, there is also GNU with
FreeBSD kernel, though I don't know if there are still users. GNU with
Hurd kernel is Unix like, and GNU with Linux is also so much Unix like
system.

GNU is not Unix because it is free software and also free not to
follow constraints and standards -- though my impression is that it
does follow it.

I feel fine with DragonFlyBSD and GNU/Linux-libre systems, as user I
do not see differences, majority of basic command line tools are more
or less same. I do prefer GNU tools for reasons of --help and
--version and some consistency.

Though when I use Haiku, that is something totally different, and
proprietary Windoze systems which I encounter at other people's
computers look rather too simple as there is no much options to change
how desktop looks like, and one is forced to use mouse so much by many
applications.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Samuel Banya]

Hey Jean,

Saw your post on Dragonfly BSD and Linux in general.

Curious, do you have any of your dotfiles anywhere? 

Was always curious to maybe switch to a BSD but haven't found one that had a decent installer. 

Would be neat to check out your dotfiles if you have any.

Thanks,

Sam

On Sat, Feb 19, 2022, at 12:51 PM, Jean Louis wrote:
> * Eli Zaretskii <eliz@gnu.org> [2022-02-19 10:34]:
> > > Date: Fri, 18 Feb 2022 20:59:38 +0000
> > > From:  emacsq via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> > > 
> > > Just wondering if a free toolkit like Gtk supports multiple platforms out of the box then would it make sense to use the same GTK-based code on every graphical platform? So using the same toolkit for everything graphics, instead of implementing features for windows, linux, etc. separately?
> > 
> > Emacs currentl;y supports building with GTK only on GNU and Unix
> > systems.
> 
> That means on Unix-like systems. It is better expressed that way. GNU
> is Not Unix, true, though it is very much Unix-like, such systems are
> mentioned as Unices if I remember well. 
> 
> GNU is Unix-like and there are variations, there is also GNU with
> FreeBSD kernel, though I don't know if there are still users. GNU with
> Hurd kernel is Unix like, and GNU with Linux is also so much Unix like
> system.
> 
> GNU is not Unix because it is free software and also free not to
> follow constraints and standards -- though my impression is that it
> does follow it.
> 
> I feel fine with DragonFlyBSD and GNU/Linux-libre systems, as user I
> do not see differences, majority of basic command line tools are more
> or less same. I do prefer GNU tools for reasons of --help and
> --version and some consistency.
> 
> Though when I use Haiku, that is something totally different, and
> proprietary Windoze systems which I encounter at other people's
> computers look rather too simple as there is no much options to change
> how desktop looks like, and one is forced to use mouse so much by many
> applications.
> 
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/
> 
> 

DragonFlyBSD

[Jean Louis]

* Samuel Banya <sbanya@fastmail.com> [2022-02-19 21:00]:
> Hey Jean,
> 
> Saw your post on Dragonfly BSD and Linux in general.
> 
> Curious, do you have any of your dotfiles anywhere? 
> 
> Was always curious to maybe switch to a BSD but haven't found one that had a decent installer. 
> 
> Would be neat to check out your dotfiles if you have any.

The only important dot file on my side is dot directory ~/.emacs.d/
and everything inside.

Otherwise other dot files belonging to other programs are all user
specific.

Installing DragonFlyBSD was very easy, it just works. I am using it
exclusively because of the HAMMER file system, for two reasons:
battery on that notebook is not good any more, and electricity outage
in under-developed country are frequent. When system goes down, HAMMER
file system makes sure that no data is lost. I don't know how exactly,
I just believe it for a while. There is no fsck-ing like on GNU/Linux.

And I use on DragonFlyBSD all the same programs including Emacs in the
same way as on GNU/Linux.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Installing DragonFlyBSD was very easy, it just works. I am
> using it exclusively because of the HAMMER file system, for
> two reasons: battery on that notebook is not good any more,
> and electricity outage in under-developed country are
> frequent. When system goes down, HAMMER file system makes
> sure that no data is lost. I don't know how exactly, I just
> believe it for a while. There is no fsck-ing like on
> GNU/Linux.

If you switch to BSD you should have a reason to do so since
that world is so much smaller.

But as Jean say, you can still be part of the GNU Emacs world
or any other Unix program world you are attracted to ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-20 01:51]:
> Jean Louis wrote:
> 
> > Installing DragonFlyBSD was very easy, it just works. I am
> > using it exclusively because of the HAMMER file system, for
> > two reasons: battery on that notebook is not good any more,
> > and electricity outage in under-developed country are
> > frequent. When system goes down, HAMMER file system makes
> > sure that no data is lost. I don't know how exactly, I just
> > believe it for a while. There is no fsck-ing like on
> > GNU/Linux.
> 
> If you switch to BSD you should have a reason to do so since
> that world is so much smaller.

My computers are several in various locations. Some may use this or
that operating system. While majority of people use one computer, I am
administering several. Family members and staff members use computers
setup by myself. It is network and computer administration in small
environment.

Me I am also using Emacs on Android, under Termux. Then Emacs on
LineageOS under Termux. Then Emacs on Replicant, under Termux. Those
are 3 operating systems. Then I use DragonFlyBSD on laptop lacking
battery, Parabola GNU/Linux-libre, Hyperbola GNU/Linux-libre on some
laptops and Haiku sometimes. I would like to install FreeBSD on some
notebooks to see how it works long term.

What I like is system consistency, like what Debian has, that one can
upgrade the system over and over again without reboot, and all things
work. Uptime like 536 days or 966 days is what I have now on some
computers with Debian.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> What I like is system consistency, like what Debian has,
> that one can upgrade the system over and over again without
> reboot, and all things work. Uptime like 536 days or 966
> days is what I have now on some computers with Debian.

Yeah I've used Debian for a long time, I like it a lot but
don't say necessarily it is better than other distros.

In particular, I think the package manager system and whole
idea installing stuff explicitely from the command line should
be replaced by a declarative system. It would have rollback
features and all, but that's not the most important thing, the
most important thing would be to have the system configurable
and setup with precision and ease in text files like you do
everything else in computing ...

Maybe Stefan and Tomas can tell you if this is happening ...
but I didn't hear anything it is, so I guess not.

It could look like asdf for CL perhaps that I know you're
familiar with [1] - and actually that can be improved even
further, as "depends-on" would be inferred :)

[1] https://dataswamp.org/~incal/common-lisp/general-base/gb.asd

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 08:53]:
> Jean Louis wrote:
> 
> > What I like is system consistency, like what Debian has,
> > that one can upgrade the system over and over again without
> > reboot, and all things work. Uptime like 536 days or 966
> > days is what I have now on some computers with Debian.
> 
> Yeah I've used Debian for a long time, I like it a lot but
> don't say necessarily it is better than other distros.

For me, I look from freedom viewpoint, I cannot recommend Debian as it
will recommend non-free software to fellows. So I exclude non-free and
use those FSF fully free distributions, sometimes self-made
distribution for myself only. It's not that hard to build it yourself.

> In particular, I think the package manager system and whole idea
> installing stuff explicitely from the command line should be
> replaced by a declarative system. It would have rollback features
> and all, but that's not the most important thing, the most important
> thing would be to have the system configurable and setup with
> precision and ease in text files like you do everything else in
> computing ...

I don't like text files. I expect system to be very adjustable through
user friendly menus, not text files.

Yes, I would like something as registry or database with keys and
values, something very firm and error prone. And on GUI I would be
doing it with mouse.

In fact I expect in 21st century that computer knows me enough, so
that I do not need to adjust anything, when I install the system, it
would ask me few questions and I would answer by voice, computer would
set it up. Why I need to configure it in text files in 21st century, I
don't know.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: DragonFlyBSD

[Samuel Banya]

I honestly wish there was a list of sane distros that were easy to install, and had the latest Emacs version available right off the bat in their default command line package manager.

I mention this because I recently tried to compile from source on Puppy Linux, but doing so was such a hassle. Had to resort to using the PPA version on the Ubuntu derivative of it, but haven't used it in a while to be honest.

Been just stuck on Manjaro so far since its one of the only sane ones that are easier to install. Was rolling with Fedora recently but don't like the whole 'LVM' by default --> wish they would give other options for installing the file system on that distro.

Sincerely,

Sam

On Mon, Feb 21, 2022, at 9:03 AM, Jean Louis wrote:
> * Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 08:53]:
> > Jean Louis wrote:
> > 
> > > What I like is system consistency, like what Debian has,
> > > that one can upgrade the system over and over again without
> > > reboot, and all things work. Uptime like 536 days or 966
> > > days is what I have now on some computers with Debian.
> > 
> > Yeah I've used Debian for a long time, I like it a lot but
> > don't say necessarily it is better than other distros.
> 
> For me, I look from freedom viewpoint, I cannot recommend Debian as it
> will recommend non-free software to fellows. So I exclude non-free and
> use those FSF fully free distributions, sometimes self-made
> distribution for myself only. It's not that hard to build it yourself.
> 
> > In particular, I think the package manager system and whole idea
> > installing stuff explicitely from the command line should be
> > replaced by a declarative system. It would have rollback features
> > and all, but that's not the most important thing, the most important
> > thing would be to have the system configurable and setup with
> > precision and ease in text files like you do everything else in
> > computing ...
> 
> I don't like text files. I expect system to be very adjustable through
> user friendly menus, not text files.
> 
> Yes, I would like something as registry or database with keys and
> values, something very firm and error prone. And on GUI I would be
> doing it with mouse.
> 
> In fact I expect in 21st century that computer knows me enough, so
> that I do not need to adjust anything, when I install the system, it
> would ask me few questions and I would answer by voice, computer would
> set it up. Why I need to configure it in text files in 21st century, I
> don't know.
> 
> 
> -- 
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/
> 
> 

Re: DragonFlyBSD

[Jean Louis]

* Samuel Banya <sbanya@fastmail.com> [2022-02-21 18:23]:
> I honestly wish there was a list of sane distros that were easy to
> install, and had the latest Emacs version available right off the
> bat in their default command line package manager.

Every distribution shall have GNU Emacs installed by default. 😇

That alone would make a sane operating system.

In Hyperbola and Parabola GNU/Linux-libre it is there packaged in many
variations, including in Guix.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> I honestly wish there was a list of sane distros that were
>> easy to install, and had the latest Emacs version available
>> right off the bat in their default command line
>> package manager.
>
> Every distribution shall have GNU Emacs installed by default.

But they don't, that's pretty rare actuallly.

> That alone would make a sane operating system.

It's a Russian doll inside a Chinese box ...

> In Hyperbola and Parabola GNU/Linux-libre it is there
> packaged in many variations, including in Guix.

Debian should have a declarative approach as well to system
state and software modularity including dependencies.
In principle (and I have no reason to doubt Guix) much better
than the current system on Debian systems.

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Samuel Banya wrote:

> I honestly wish there was a list of sane distros that were
> easy to install

There are _tons_ of such Linux distros this day and age ...
Debian and Debian forks (e.g. the Ubuntus) yes but many, many
others as well. The norm is that installing Linux is very
easy today. And why ever wouldn't it be ...

> and had the latest Emacs version available right off the bat
> in their default command line package manager.

That OTOH ... at least my distros (Debian, RPi OS, ev3dev)
aren't like that.

So I install it manually, but that's super easy as well.

I use the functions in this zsh file:

#! /bin/zsh
#
# this file:
#   http://user.it.uu.se/~embe8573/conf/.zsh/install-emacs
#   https://dataswamp.org/~incal/conf/.zsh/install-emacs

export emacs_src=https://git.savannah.gnu.org/git/emacs.git
export src_dir=~/src
export emacs_dir=$src_dir/emacs

emacs-reinstall () {
    emacs-src-reset
    emacs-install
}
alias reinstall-emacs=emacs-reinstall

emacs-install () {
    emacs-install-prepare
    emacs-src-update
    emacs-do-install
}
alias install-emacs=emacs-install

emacs-install-prepare () {
    sudo apt-get -qq update
    sudo apt-get install build-essential debian-goodies libgccjit-10-dev
    sudo apt-get build-dep emacs
}

emacs-src-reset () {
    cd $emacs_dir
    git reset --hard
    git clean -xdf
    git config pull.rebase false
    git pull $emacs_src
}

emacs-src-get () {
    cd $src_dir
    git clone $emacs_src
}

emacs-src-update () {
    cd $emacs_dir
    git fetch
}

emacs-do-install () {
    cd $emacs_dir
    autogen.sh
    configure --with-x-toolkit=no --with-native-compilation
    make
    sudo make install
    emacs --version
}

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> What I like is system consistency, like what Debian has,
>>> that one can upgrade the system over and over again
>>> without reboot, and all things work. Uptime like 536 days
>>> or 966 days is what I have now on some computers
>>> with Debian.
>> 
>> Yeah I've used Debian for a long time, I like it a lot but
>> don't say necessarily it is better than other distros.
>
> For me, I look from freedom viewpoint, I cannot recommend
> Debian as it will recommend non-free software to fellows.
> So I exclude non-free and use those FSF fully free
> distributions, sometimes self-made distribution for myself
> only. It's not that hard to build it yourself.

You can do that on Debian by excluding the non-free part from
the sources.list line(s) - never heard of anyone actually
doing that tho ...

>> In particular, I think the package manager system and whole
>> idea installing stuff explicitely from the command line
>> should be replaced by a declarative system. It would have
>> rollback features and all, but that's not the most
>> important thing, the most important thing would be to have
>> the system configurable and setup with precision and ease
>> in text files like you do everything else in computing ...
>
> I don't like text files

?

> I expect system to be very adjustable through user friendly
> menus

??

> And on GUI I would be doing it with mouse

???

> In fact I expect in 21st century that computer knows me
> enough, so that I do not need to adjust anything

????

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Samuel Banya]

The only two distros with sane installers I've used with the latest Emacs right out of the bat that was available have been Manjaro and Fedora.

On Sat, Feb 26, 2022, at 11:45 AM, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Jean Louis wrote:
> 
> >>> What I like is system consistency, like what Debian has,
> >>> that one can upgrade the system over and over again
> >>> without reboot, and all things work. Uptime like 536 days
> >>> or 966 days is what I have now on some computers
> >>> with Debian.
> >> 
> >> Yeah I've used Debian for a long time, I like it a lot but
> >> don't say necessarily it is better than other distros.
> >
> > For me, I look from freedom viewpoint, I cannot recommend
> > Debian as it will recommend non-free software to fellows.
> > So I exclude non-free and use those FSF fully free
> > distributions, sometimes self-made distribution for myself
> > only. It's not that hard to build it yourself.
> 
> You can do that on Debian by excluding the non-free part from
> the sources.list line(s) - never heard of anyone actually
> doing that tho ...
> 
> >> In particular, I think the package manager system and whole
> >> idea installing stuff explicitely from the command line
> >> should be replaced by a declarative system. It would have
> >> rollback features and all, but that's not the most
> >> important thing, the most important thing would be to have
> >> the system configurable and setup with precision and ease
> >> in text files like you do everything else in computing ...
> >
> > I don't like text files
> 
> ?
> 
> > I expect system to be very adjustable through user friendly
> > menus
> 
> ??
> 
> > And on GUI I would be doing it with mouse
> 
> ???
> 
> > In fact I expect in 21st century that computer knows me
> > enough, so that I do not need to adjust anything
> 
> ????
> 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
> 

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Samuel Banya wrote:

> The only two distros with sane installers I've used with the
> latest Emacs right out of the bat that was available have
> been Manjaro and Fedora.

And, installing stuff isn't wrong :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Lele Gaifax]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> I think the package manager system and whole
> idea installing stuff explicitely from the command line should
> be replaced by a declarative system. It would have rollback
> features and all, but that's not the most important thing, the
> most important thing would be to have the system configurable
> and setup with precision and ease in text files like you do
> everything else in computing ...

That could be a description of what Nix permits, and NixOS exploits.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Lele Gaifax wrote:

>> I think the package manager system and whole idea
>> installing stuff explicitely from the command line should
>> be replaced by a declarative system. It would have rollback
>> features and all, but that's not the most important thing,
>> the most important thing would be to have the system
>> configurable and setup with precision and ease in text
>> files like you do everything else in computing ...
>
> That could be a description of what Nix permits, and
> NixOS exploits.

Yeah, you have an example of that?

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Lele Gaifax]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Lele Gaifax wrote:
>
>>> I think the package manager system and whole idea
>>> installing stuff explicitely from the command line should
>>> be replaced by a declarative system. It would have rollback
>>> features and all, but that's not the most important thing,
>>> the most important thing would be to have the system
>>> configurable and setup with precision and ease in text
>>> files like you do everything else in computing ...
>>
>> That could be a description of what Nix permits, and
>> NixOS exploits.
>
> Yeah, you have an example of that?

This is a nice presentation:
https://monk.unboiled.info/pub/talks/2021/dol-nixos/dol-nixos.mp4

bye, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: DragonFlyBSD

[Emanuel Berg via Users list for the GNU Emacs text editor]

Lele Gaifax wrote:

>>> That could be a description of what Nix permits, and
>>> NixOS exploits.
>>
>> Yeah, you have an example of that?
>
> This is a nice presentation:
> https://monk.unboiled.info/pub/talks/2021/dol-nixos/dol-nixos.mp4

Thanks, but say I want what I use now, which is

  Emacs
  feh
  mpv
  openbsd-cwm
  picom
  rtorrent
  tmux
  xpdf
  xterm
  zsh

how do I put that in a configuration text file and issue
a command to boot the system into a state that includes what
I have specified, if that's how it works?

Yeah, that sounds to good to be true, almost ...

It can do that?

-- 
underground experts united
https://dataswamp.org/~incal

Re: DragonFlyBSD

[Lele Gaifax]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Thanks, but say I want what I use now, which is
>
>   Emacs
>   feh
>   mpv
>   openbsd-cwm
>   picom
>   rtorrent
>   tmux
>   xpdf
>   xterm
>   zsh
>
> how do I put that in a configuration text file and issue
> a command to boot the system into a state that includes what
> I have specified, if that's how it works?
>

This is an example of such configuration, that governs my whole laptop,
running NixOS:

  https://gitlab.com/lelix/lenof-nixos-configuration/-/blob/master/packages.nix

It basically configure a system with a set of "global" packages and another
one specific for my own account. Changing that list and issuing a
"nix-rebuild boot" creates a new "generation" of the system, that will be
activated at next reboot, while keeping the previous ones still available,
until an explicit "nix-collect-garbage". 

As a bonus, nix (the-language) is available also on any GNU/Linux system and
even on macOS.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

DEOL: Declarative Emacs On-Line (was: Re: DragonFlyBSD)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Lele Gaifax wrote:

> This is an example of such configuration, that governs my
> whole laptop, running NixOS:
>
>   https://gitlab.com/lelix/lenof-nixos-configuration/-/blob/master/packages.nix
>
> It basically configure a system with a set of "global"
> packages and another one specific for my own account.
> Changing that list and issuing a "nix-rebuild boot" creates
> a new "generation" of the system, that will be activated at
> next reboot, while keeping the previous ones still
> available, until an explicit "nix-collect-garbage".

Thanks, I'll try it! Get back to you ...

Can't belive this is something new! (Relatively speaking.)

Why wasn't it like this since day one?

Mr. Monnier, a theory?

All software is configured with config or rc (run commands)
files, why not the most important software there is (after the
text editor), the OS and the software harbors?

What is the most natural thing and the way one would do it
oneself without thinking is now too good to be true, how did
that happen?

And ... what about the Emacs world?

We want this for [M]ELPA as well!

Take a look at this Makefile, and marvel at its excellency
doing it ... in a way that doesn't make sense!

  https://dataswamp.org/~incal/emacs-init/Makefile
  
It is Easter Island all over again. Instead of moving onto the
next and superior level, perfect stone age to an
absurd degree ...

One system to define the system, another to realize it ...

$&#@%!

https://dataswamp.org/~incal/emacs-init/comic-book-insult.el

-- 
underground experts united
https://dataswamp.org/~incal

Re: DEOL: Declarative Emacs On-Line

[Lele Gaifax]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> And ... what about the Emacs world?
>
> We want this for [M]ELPA as well!

I'm not sure what you mean, but you can easily find examples of managing Emacs
configs from Emacs-the-program down to the single package:

  https://github.com/jwiegley/nix-config/blob/master/overlays/10-emacs.nix

and

  https://github.com/jwiegley/nix-config/blob/master/config/emacs.nix

In that config, John uses Home Manager¹ to track even most of user's dotfiles.

ciao, lele.

¹ https://nix-community.github.io/home-manager/
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: DEOL: Declarative Emacs On-Line

[Emanuel Berg via Users list for the GNU Emacs text editor]

Lele Gaifax wrote:

> I'm not sure what you mean, but you can easily find examples
> of managing Emacs configs from Emacs-the-program down to the
> single package:
>
>   https://github.com/jwiegley/nix-config/blob/master/overlays/10-emacs.nix

Hm, that's a lot of code, isn't this supposed to do this
easier and more viewable? ;)

Maybe you can yank and explain a subset of that code?

Actually, this doesn't look like what I want att all, sorry.

 seq = if esuper.emacs.version != "26.3"                                      
 then mkDerivation rec {                                                      
 name = "seq-stub";                                                           
 version = "stub";                                                            
 src = ./.;                                                                   
 phases = [ "installPhase" ];                                                 
 installPhase = ''                                                            
 mkdir $out                                                                   
 touch $out/.empty                                                            
 '';                                                                          

that looks like a mix of automatic and manual processing, and
a mix of declarative and imperative styles as well.
("Imperative" is the CS word for stacking commands.)

To be honest the posted Makefile actually looks much better
IMO. [1]

Here, have a look, couldn't it look more like this?

  https://dataswamp.org/~incal/common-lisp/general-base/gb.asd

And again, that could be simplified even further since
dependencies could be derived :)

>   https://github.com/jwiegley/nix-config/blob/master/config/emacs.nix

That's more like it, only in the Emacs world we like to
evaluate things. Couldn't it be left to Emacs to have
a declarative build system of its own?

But anyway that's certainly interesting anyway, so then how do
I use it?

You already saw what I use,

  crontab-mode-20210715.133
  gnuplot-mode-20171013.1616
  google-translate-20210406.1138
  lua-mode-20210809.1320
  markdown-mode-20211022.55
  scad-mode-20200830.301
  seq-2.23
  slime-20220210.1512
  sml-mode-6.10
  w3m-20211122.335

> In that config, John uses Home Manager to track even most
> of user's dotfiles.
>
>   https://nix-community.github.io/home-manager/

Not following, what does that do?

Instead of loading them from .emacs? Or `require' them
in Elisp?

Indeed I've spent ages doing that as well [2] - now it is very
easy to find an error even from zero information about it,
since one can do binary search by commenting out files or
group of files ... (instead of source lines) [well, actually
that is how it is done still LOL]

[1] https://dataswamp.org/~incal/emacs-init/Makefile
[2] https://dataswamp.org/~incal/conf/.emacs

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Samuel Banya wrote:

> Was always curious to maybe switch to a BSD but haven't
> found one that had a decent installer.

Watch out for the BSD whose purpose is to run Linux!

OpenBSD has a friendly community. The focus on security is
their code of honor. So if you are into that, if you feel
Linux isn't secure enough and can't be easily configured to
meet your standards, sure, try OpenBSD.

The other BSDs I don't know what focus they have, really ...

-- 
underground experts united
https://dataswamp.org/~incal

Purposes of BSD-like systems

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-20 01:47]:
> Samuel Banya wrote:
> 
> > Was always curious to maybe switch to a BSD but haven't
> > found one that had a decent installer.
> 
> Watch out for the BSD whose purpose is to run Linux!
> 
> OpenBSD has a friendly community. The focus on security is
> their code of honor. So if you are into that, if you feel
> Linux isn't secure enough and can't be easily configured to
> meet your standards, sure, try OpenBSD.

Friendly? Just try mentioning GPL.

> The other BSDs I don't know what focus they have, really ...

NetBSD -- to be most compatible over all platforms, OpenBSD to be most
secure, FreeBSD to be the free Unix, DragonFlyBSD for huge computing
if I remember well. And so on, each has a purpose slightly different.

And we all benefit from it. We use much of OpenBSD work in GNU/Linux
systems.

Most promising so far will be Hyperbola/BSD system, that will become
GPL3+ BSD based system.

Insights into Why Hyperbola GNU/Linux is Turning into Hyperbola BSD - It's FOSS
https://itsfoss.com/hyperbola-linux-bsd/


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Purposes of BSD-like systems

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> NetBSD -- to be most compatible over all platforms, OpenBSD to be most
> secure, FreeBSD to be the free Unix, DragonFlyBSD for huge computing
> if I remember well. And so on, each has a purpose slightly different.
>
> And we all benefit from it. We use much of OpenBSD work in GNU/Linux
> systems.
>
> Most promising so far will be Hyperbola/BSD system, that will become
> GPL3+ BSD based system.
>
> Insights into Why Hyperbola GNU/Linux is Turning into Hyperbola BSD -
> It's FOSS https://itsfoss.com/hyperbola-linux-bsd/

This discussion seems to be a prime candidate for moving to
emacs-tangents.

Re: Purposes of BSD-like systems

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> NetBSD -- to be most compatible over all platforms

Yeah, the most ported. Read this tho:

  https://www.csoonline.com/article/3250653/is-the-bsd-os-dying-some-security-researchers-think-so.html

> OpenBSD to be most secure

That's what they tell me ...

> FreeBSD to be the free Unix

This is the one whose purpose is to run Linux :)

> DragonFlyBSD for huge computing if I remember well.

I read:

  It is basically not used for personal computers. It was
  specifically designed for server, workstation, NAS and
  embedded systems [1]

> And we all benefit from it. We use much of OpenBSD work in
> GNU/Linux systems.

Okay, an example?

[1] https://www.geeksforgeeks.org/difference-between-linux-and-dragonfly-bsd/

-- 
underground experts united
https://dataswamp.org/~incal

Re: Purposes of BSD-like systems

[andrew]

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

On 22/02/21 05:41AM, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> > And we all benefit from it. We use much of OpenBSD work in
> > GNU/Linux systems.
> 
> Okay, an example?

OpenSSH
LibreSSL (Fork of OpenSSL, includes: libcrypto, libssl, libtls nc)
rpki-client
doas (simpler and as I think better than sudo)
OpenSMTPD
etc

------------------------------------------------------------------------
Defend software freedom (https://fsf.org)
End software patents (https://endsoftwarepatents.org)
Read EULAs (https://www.eff.org/wp/dangerous-terms-users-guide-eulas)

New sites, suggestions welcome:
Free Computing Movement (https://fcm.andrewyu.org)
Host Things Yourself (https://host.andrewyu.org)
Libre Society (https://libre.andrewyu.org)

To any Skynet, FBI, CIA, NSA, etc. agents reading my email: please
consider whether defending the Constitution and our basic rights to
freedom and speech and privacy against all enemies, foreign or domestic,
requires you to follow Snowden's example.  (Adapted from RMS)

Andrew Yu <andrew@andrewyu.org> (https://www.andrewyu.org)

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

Re: Purposes of BSD-like systems

[Emanuel Berg via Users list for the GNU Emacs text editor]

andrew wrote:

>>> And we all benefit from it. We use much of OpenBSD work in
>>> GNU/Linux systems.
>> 
>> Okay, an example?
>
> OpenSSH
> LibreSSL (Fork of OpenSSL, includes: libcrypto, libssl, libtls nc)
> rpki-client
> doas (simpler and as I think better than sudo)
> OpenSMTPD
> etc

Yeah, I just didn't understand what he meant, GNU/Linux
systems is a pretty wide concept ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Purposes of BSD-like systems

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 07:44]:
> > And we all benefit from it. We use much of OpenBSD work in
> > GNU/Linux systems.
> 
> Okay, an example?

OpenSSH is one good example used all over the world. LibreSSL is
another example.

Fallback for Emacs on my side is mg

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Purposes of BSD-like systems

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> And we all benefit from it. We use much of OpenBSD work in
>>> GNU/Linux systems.
>> 
>> Okay, an example?
>
> OpenSSH is one good example used all over the world.
> LibreSSL is another example.

Aha, you mean like that! Then yes!

There's a lot, tmux comes to mind since it is so popular but
I don't know if that's from the OpenBSD branch in particular
of the BSD world or if it's from one of the others,
perhaps ...

Their terminology is different, a package is a "port" and some
software also comes in a "portable" version IIRC. Is that for
non-OpenBSD systems?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Sat, 19 Feb 2022 20:51:16 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > Emacs currentl;y supports building with GTK only on GNU and Unix
> > systems.
> 
> That means on Unix-like systems. It is better expressed that way. GNU
> is Not Unix, true, though it is very much Unix-like, such systems are
> mentioned as Unices if I remember well. 

"GNU and Unix systems" is standard GNU terminology.  We use it in
umpteen places.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-02-19 21:09]:
> > Date: Sat, 19 Feb 2022 20:51:16 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > Emacs currentl;y supports building with GTK only on GNU and Unix
> > > systems.
> > 
> > That means on Unix-like systems. It is better expressed that way. GNU
> > is Not Unix, true, though it is very much Unix-like, such systems are
> > mentioned as Unices if I remember well. 
> 
> "GNU and Unix systems" is standard GNU terminology.  We use it in
> umpteen places.

I did not know that. Though what do you think would this expression be
more clear:

"GNU and other Unix like systems"


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Sat, 19 Feb 2022 22:30:47 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > "GNU and Unix systems" is standard GNU terminology.  We use it in
> > umpteen places.
> 
> I did not know that. Though what do you think would this expression be
> more clear:
> 
> "GNU and other Unix like systems"

No.  We really do maintain that GNU is different from Unix systems.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> No. We really do maintain that GNU is different from
> Unix systems.

Also: Is laundry standardized or should we say you stink-like?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> No. We really do maintain that GNU is different from
> Unix systems.

I'm starting to figure this whole mess out ...

Eli used Windows for so long. This age-long state of
entrapment, no doubt a horrible experience without any end in
sight, made him idealize the alternative, Unix.

However, recognizing his contribution to Emacs, a loosely-knit
group of GNU, Linux and BSD hackers at last managed to crack
the window, brake thru to the other side, and liberate Eli
from his confinement.

Alas, it was too late! At that time, Eli was stuck in that
endless mind loop. To this day he is still relentlessly
searching for that ideal, perfect Unix, the alternative to his
dreadful window - the Unix fantasy, daydream and little peace
of hope that made him endure all those years ...

Can we set him free a second time?

Or will true Unix forever remain - a dream?

-- 
underground experts united
https://dataswamp.org/~incal

Why is GNU not Unix-like system?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-02-19 22:39]:
> > Date: Sat, 19 Feb 2022 22:30:47 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > "GNU and Unix systems" is standard GNU terminology.  We use it in
> > > umpteen places.
> > 
> > I did not know that. Though what do you think would this expression be
> > more clear:
> > 
> > "GNU and other Unix like systems"
> 
> No.  We really do maintain that GNU is different from Unix systems.

Of course it is different.

Though it was made with purpose to be Unix-compatible system, see:
https://www.gnu.org/gnu/manifesto.html

Please tell me what makes GNU not to be Unix-like system. I am curious
as I was always under impression it is Unix-like system.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Why is GNU not Unix-like system?

[Eli Zaretskii]

> Date: Sun, 20 Feb 2022 15:21:50 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2022-02-19 22:39]:
> > > Date: Sat, 19 Feb 2022 22:30:47 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: help-gnu-emacs@gnu.org
> > > 
> > > > "GNU and Unix systems" is standard GNU terminology.  We use it in
> > > > umpteen places.
> > > 
> > > I did not know that. Though what do you think would this expression be
> > > more clear:
> > > 
> > > "GNU and other Unix like systems"
> > 
> > No.  We really do maintain that GNU is different from Unix systems.
> 
> Of course it is different.
> 
> Though it was made with purpose to be Unix-compatible system, see:
> https://www.gnu.org/gnu/manifesto.html
> 
> Please tell me what makes GNU not to be Unix-like system.

I didn't say GNU wasn't "Unix-like".  I just said we routinely use
"GNU and Unix systems", that's all.  You can see that at work in the
Emacs manuals.  I cannot be held responsible for all the claptrap
which followed my naïve remark; I was just trying to tell that GTK
cannot be used on all platforms supported by Emacs.

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-02-19 21:09]:
> > Date: Sat, 19 Feb 2022 20:51:16 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > Emacs currentl;y supports building with GTK only on GNU and Unix
> > > systems.
> > 
> > That means on Unix-like systems. It is better expressed that way. GNU
> > is Not Unix, true, though it is very much Unix-like, such systems are
> > mentioned as Unices if I remember well. 
> 
> "GNU and Unix systems" is standard GNU terminology.  We use it in
> umpteen places.

You see here:
https://www.gnu.org/gnu/manifesto.html

Quote of RMS:

,----
| GNU, which stands for Gnu's Not Unix, is the name for the complete
| Unix-compatible software system which I am writing so that I can give
| it away free to everyone who can use it.
`----

That is why I say, if you wish to refer to Unix systems, that means
only those which are true Unix systems, but does not mean FreeBSD,
NetBSD, OpenBSD, DragonFlyBSD, and others because such are not Unix
systems, they are Unix-like systems, as they are not registered and
officially recognized as Unix.

Also see:

Unix-like - Wikipedia
https://en.wikipedia.org/wiki/Unix-like

That is why I mentioned that "GNU and other Unix like systems" would
be better descriptive, IMHO.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Quote of RMS:
>
>   That is why I say, if you wish to refer to Unix systems,
>   that means only those which are true Unix systems, but
>   does not mean FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, and
>   others because such are not Unix systems, they are
>   Unix-like systems, as they are not registered and
>   officially recognized as Unix.

Oh, so it is just that little thing. Let men the officially
recognize on gmane.emacs.help for all to hear that the BSDs
are Unix!

... wait ... something is up ...

AAAH! I SEE!

SO DID ANYONE OF YOU WORTHLESS BUNCH OF GOOD-FOR-NOTHINGS KEEP
TRACK ON THE GOD DAMN BINARY DIGITS OF THESE SYSTEMS IN
EXECUTION? AND IN PARTICULAR, WHAT UNIX FEATURES CHANGED AND
IN WHAT WAYS FROM US SAYING DIFFERENT THINGS AS TO
THEIR NATURE?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>> That means on Unix-like systems. It is better expressed
>> that way. GNU is Not Unix, true, though it is very much
>> Unix-like, such systems are mentioned as Unices if
>> I remember well.
>
> "GNU and Unix systems" is standard GNU terminology. We use
> it in umpteen places.

Indeed, in these places people know what they are doing and
saying, there they don't think Linux and BSD are Unix ...

But what worries me - can they do laundry?

Or do _all_ of them stink?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> That means on Unix-like systems. It is better expressed that
> way. GNU is Not Unix, true, though it is very much
> Unix-like, such systems are mentioned as Unices if
> I remember well.

But that is a formal distinction:

  A Unix-like (sometimes referred to as UN*X or *nix)
  operating system is one that behaves in a manner similar to
  a Unix system, although not necessarily conforming to or
  being certified to any version of the Single UNIX
  Specification. [1]

But I don't care about that. And for good reason, because in
terms of technology a random Linux distribution found on
DistroWatch.com [2] is as much Unix as anything else.

I played ice hockey for more than a decade. I didn't wear
a helmet a single time. But the IIHF says all players should
wear helmets. That means it wasn't ice hockey, what I took
part in was an "ice hockey-like sport". See? The absence of
a helmet _is_ what "breaks" it!

> I feel fine with DragonFlyBSD and GNU/Linux-libre systems,
> as user I do not see differences, majority of basic command
> line tools are more or less same. I do prefer GNU tools for
> reasons of --help and --version and some consistency.

And because there are tons of more options than on a BSD
system, e.g. OpenBSD. But I like both in principle; I'm
a maximalist but they are not and they made a system in line
with that and their style. Linux is also much bigger so there
is a much bigger culture, support, services, webpages, and so
on. Books and business, cons and pros. Like I said, I'm
a maximalist so the Unix cocktail I do is Linux, Emacs, zsh and
Lisp - not OpenBSD, nano, mrsh, and Yabasic. But that is still
just two styles ... of Unix.

(Now, for the record, I made that up as you realized. You can
use Emacs, zsh and Lisp on OpenBSD as well as again, everyone
understands, helmet or not.)

[1] https://en.wikipedia.org/wiki/Unix-like

[2] https://dataswamp.org/~incal/CLUELESS-ONLINE

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Drew Adams]

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

(Not a reply to any particular msg in this thread.)

https://en.wikipedia.org/wiki/Lumpers_and_splitters


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13530 bytes --]

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> (Not a reply to any particular msg in this thread.)
>
> https://en.wikipedia.org/wiki/Lumpers_and_splitters

So there are lumpers and splitters ...

I'm a lumper!

Let's see ... can we put it down shorter and more to the point
maybe ...

Lumpers recognize things when they see them and have no
problem accepting that reality cannot be approached as an
exact science.

Meanwhile, splitters are neurotic, by-the-book legalists who
rely on human-formulated definitions - imperfect by nature,
tendentious in character ...

Yeah, that's a good definition, right?

...

But wait, didn't I just do the splitter thing?

Reboot, I take that back. On the contrary, we are pretty much
alike! Indeed, "Unix" and "Unix-like" are alike, even!

Try this

  (format "%.1f%%" (* 100 (/ (length "Unix") (length "Unix-like") 1.0)))

It turns out, alike is an understatement! We are 44.4%
_identical_!

PS. For the record, that Elisp doesn't show that :) LOL

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Drew Adams]

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

> > (Not a reply to any particular msg in this thread.)
> >
> >
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Lumpers_and_splitt
> ers__;!!ACWV5N9M2RV99hQ!cscqWjCtmmw_39n80c20LG5gMbaTK-
> lw0S5X3PJGH9Xl2hYSxqhbeGA6QOLJINcP$
> 
> So there are lumpers and splitters ...
> 
> I'm a lumper!
> 
> Let's see ... can we put it down shorter and more to the point
> maybe ...
> 
> Lumpers recognize things when they see them and have no
> problem accepting that reality cannot be approached as an
> exact science.
> 
> Meanwhile, splitters are neurotic, by-the-book legalists who
> rely on human-formulated definitions - imperfect by nature,
> tendentious in character ...
> 
> Yeah, that's a good definition, right?

Good enough for some lumpers, no doubt!
Some splitters might split a hair over it.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14402 bytes --]

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Yuri Khan]

On Sun, 20 Feb 2022 at 07:21, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Drew Adams wrote:
>
> > (Not a reply to any particular msg in this thread.)
> >
> > https://en.wikipedia.org/wiki/Lumpers_and_splitters
>
> So there are lumpers and splitters ...

So splitters categorize people into splitters and lumpers, while lumpers… don’t.

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2022-02-20 09:58]:
> On Sun, 20 Feb 2022 at 07:21, Emanuel Berg via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> >
> > Drew Adams wrote:
> >
> > > (Not a reply to any particular msg in this thread.)
> > >
> > > https://en.wikipedia.org/wiki/Lumpers_and_splitters
> >
> > So there are lumpers and splitters ...
> 
> So splitters categorize people into splitters and lumpers, while lumpers… don’t.

I was quite under impression that article was written by lumpers as
how can one just label people and put in two groups in various
discussions.

I can think of many examples where lumpers may be practically right,
it does not mean they can't see differences. We have it all times in
our discussions here.

Example is that I can't see Emanuel in Unix-like related discussion to
be lumper. From practical user viewpoint those are more or less
systems based on same principles, including GNU. Though they have
different names and features.

Now I think, the more one thinks as a splitter, one cannot designate
lumpers into lumpers.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> I can think of many examples where lumpers may be
> practically right, it does not mean they can't see
> differences.

The method, as quoted from the THE LUMPER MANIFESTO (1852),
is:

  1) See differences and similarities.

  2) Decide what of those are the _important_ ones.

> Now I think, the more one thinks as a splitter, one cannot
> designate lumpers into lumpers.

Hahaha :)

-- 
underground experts united
https://dataswamp.org/~incal

Lumpers & Splitter

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 09:46]:
> Jean Louis wrote:
> 
> > I can think of many examples where lumpers may be
> > practically right, it does not mean they can't see
> > differences.
> 
> The method, as quoted from the THE LUMPER MANIFESTO (1852),
> is:
> 
>   1) See differences and similarities.
> 
>   2) Decide what of those are the _important_ ones.
> 
> > Now I think, the more one thinks as a splitter, one cannot
> > designate lumpers into lumpers.

That is what I meant.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Lumpers & Splitter

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> Jean Louis wrote:
>> 
>> > I can think of many examples where lumpers may be
>> > practically right, it does not mean they can't see
>> > differences.
>> 
>> The method, as quoted from the THE LUMPER MANIFESTO (1852),
>> is:
>> 
>>   1) See differences and similarities.
>> 
>>   2) Decide what of those are the _important_ ones.
>> 
>> > Now I think, the more one thinks as a splitter, one cannot
>> > designate lumpers into lumpers.
>
> That is what I meant.

I can't?

These

   1) See differences and similarities.

   2) Decide what of those are the _important_ ones.

are actually the same!

1) Seeing and deciding what is important, that's concurrent
   processes with a complex bidirectional interface

So that's the new lumper definition!

And the previous one it is the new splitter definition ...

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Drew Adams]

> > >> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Lumpers_and_splitt
> ers__;!!ACWV5N9M2RV99hQ!a53MsURUA7NmlGqjRUi7SQiz4_FswOrXTnEcORbuSJSgR-
> w4LQY3RaTJ8sq6QTyu$
> >
> > So there are lumpers and splitters ...
> 
> So splitters categorize people into splitters and lumpers, while lumpers…
> don’t.

;-)

Lumpers categorize too.  There are no doubt some
extreme lumpers, who:

1. Categorize everything into the same category.
2. Consider everyone else to be a splitter.

But of course, by #1, #2 means that they consider
all splitters to actually be lumpers...

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> Lumpers categorize too.  There are no doubt some
> extreme lumpers, who:
>
> 1. Categorize everything into the same category.
> 2. Consider everyone else to be a splitter.
>
> But of course, by #1, #2 means that they consider all
> splitters to actually be lumpers...

Hahaha, amazing :)

What's the extreme splitter position then?

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Drew Adams]

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

> > Lumpers categorize too.  There are no doubt some
> > extreme lumpers, who:
> > 1. Categorize everything into the same category.
> > 2. Consider everyone else to be a splitter.
> > But of course, by #1, #2 means that they consider
> > all splitters to actually be lumpers...
> 
> Hahaha, amazing :)
> What's the extreme splitter position then?

Every individual/instance is (in) its own
category?

Which makes all categories equivalent -
homogeneous heterogeneity.  Which means
only a single category - everything split
equally - one big lump.

;-)

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14542 bytes --]

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> > Lumpers categorize too.  There are no doubt some
>> > extreme lumpers, who:
>> > 1. Categorize everything into the same category.
>> > 2. Consider everyone else to be a splitter.
>> > But of course, by #1, #2 means that they consider
>> > all splitters to actually be lumpers...
>> 
>> Hahaha, amazing :)
>> What's the extreme splitter position then?
>
> Every individual/instance is (in) its own
> category?
>
> Which makes all categories equivalent -
> homogeneous heterogeneity.  Which means
> only a single category - everything split
> equally - one big lump.

If anything can happen anew,
then everything must continue!

-- 
underground experts united
https://dataswamp.org/~incal

Lumpers & Splitter

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 09:37]:
> Drew Adams wrote:
> 
> > Lumpers categorize too.  There are no doubt some
> > extreme lumpers, who:
> >
> > 1. Categorize everything into the same category.
> > 2. Consider everyone else to be a splitter.
> >
> > But of course, by #1, #2 means that they consider all
> > splitters to actually be lumpers...
> 
> Hahaha, amazing :)
> 
> What's the extreme splitter position then?

You have just answered to one of extreme splitter statements.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Lumpers & Splitter

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> But of course, by #1, #2 means that they consider all
>>> splitters to actually be lumpers...
>> 
>> Hahaha, amazing :)
>> 
>> What's the extreme splitter position then?
>
> You have just answered to one of extreme
> splitter statements.

Haha :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-20 03:22]:
> Drew Adams wrote:
> 
> > (Not a reply to any particular msg in this thread.)
> >
> > https://en.wikipedia.org/wiki/Lumpers_and_splitters
> 
> So there are lumpers and splitters ...
> 
> I'm a lumper!

Lumper wrote the article, now you tend to agree. People can't be put
in two groups. One can only take one specific narrow context, and
judge from a point of view that one side is lumper oder splitter.

If we are to judge you to be lumper... you are far from that. You
would not be on this mailing list if you would generally be a
lumper. Why? You are pedantic in every detail, you correct smallest
nitpicks just like Drew. There is general tendency in Emacs society to
go rather towards "splitters" group. Lumpers don't participate much in
discussions.

> Lumpers recognize things when they see them and have no
> problem accepting that reality cannot be approached as an
> exact science.
> 
> Meanwhile, splitters are neurotic, by-the-book legalists who
> rely on human-formulated definitions - imperfect by nature,
> tendentious in character ...
> 
> Yeah, that's a good definition, right?

It's another lumper made definition. 🙂

I don't see it that way. Intelligence is very related to
distinction. The higher ability to distinguish, probably there is more
intelligence. Lumpers could or may see that distinction is not
necessary in specific subject, it does not mean they cannot
distinguish. But it could be.

> But wait, didn't I just do the splitter thing?

Labeling of people groups generally is not useful. But practically and
in specific context it can be very useful.

Do you see this letter A and A? Are they same? They look same but they
are not same, as they must be saved in quite different locations by
different impulses which are not same. They look same to observer as
that is what observer learned "to be same". Observer is always to some
degree both lumper and splitter.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>>> (Not a reply to any particular msg in this thread.)
>>>
>>> https://en.wikipedia.org/wiki/Lumpers_and_splitters
>> 
>> So there are lumpers and splitters ...
>> 
>> I'm a lumper!
>
> Lumper wrote the article, now you tend to agree.
> People can't be put in two groups. One can only take one
> specific narrow context, and judge from a point of view that
> one side is lumper oder splitter.

But isn't the "lumping" in this context lumping together the
proprietary Unix systems (e.g. SunOS/Solaris), the Linux
distros and the BSDs into Unix?

While the splitting is splitting the Unix into "Unix" and
"Unix-like"?

> If we are to judge you to be lumper... you are far from
> that. You would not be on this mailing list if you would
> generally be a lumper. Why? You are pedantic in every
> detail, you correct smallest nitpicks just like Drew.

That's a method/mindset that is beneficial in computing, you
don't have to think "should I fix this?", you just fix
everything without thinking at all, pretty soon.

I don't know if it can ever go overboard but if so I'll take
it and consider it an occupational hazard ...

> There is general tendency in Emacs society to go rather
> towards "splitters" group. Lumpers don't participate much
> in discussions.

That comment is so splitter. Why don't you join the lumper's
camp and get into the game?

> I don't see it that way. Intelligence is very related to
> distinction. The higher ability to distinguish, probably
> there is more intelligence. Lumpers could or may see that
> distinction is not necessary in specific subject, it does
> not mean they cannot distinguish. But it could be.

What are you kidding, I _understand_ the Unix/Unix-like
distinction very well! I'm intelligent enough to do that LOL.
No, I disagree that is incorrect not to use it, because
I think that distinctions in the world of technology should be
made in terms of technology and reflect technology. What some
business dudes piled together in their fancy documents
shouldn't influence how I, a technology person, refer to
technology. dig(1)?

> Do you see this letter A and A? Are they same? They look
> same but they are not same, as they must be saved in quite
> different locations by different impulses which are not
> same.

Here we see my Lumper instinct, because I think they are
both A.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

>> Intelligence is very related to distinction. The higher
>> ability to distinguish, probably there is more
>> intelligence [...]
>
> What are you kidding, I _understand_ the Unix/Unix-like
> distinction very well! I'm intelligent enough to do that
> LOL. No, I disagree that is incorrect not to use it [...]

And on the other end, if you say "Linux or Unix" the way the
human language and mind works the implication is that Linux
isn't Unix.

So that's just confusing, because it is. Indeed, I'm a
Unix user here on GNU/Linux Debian :)

You mean to say you guys are Unix-like users?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 09:53]:
> >> Intelligence is very related to distinction. The higher
> >> ability to distinguish, probably there is more
> >> intelligence [...]
> >
> > What are you kidding, I _understand_ the Unix/Unix-like
> > distinction very well! I'm intelligent enough to do that
> > LOL. No, I disagree that is incorrect not to use it [...]
> 
> And on the other end, if you say "Linux or Unix" the way the
> human language and mind works the implication is that Linux
> isn't Unix.

> So that's just confusing, because it is. Indeed, I'm a
> Unix user here on GNU/Linux Debian :)
> 
> You mean to say you guys are Unix-like users?

Me I am not Unix user, I am GNU user using Unix-like systems.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> You mean to say you guys are Unix-like users?
>
> Me I am not Unix user, I am GNU user using
> Unix-like systems.

OK!

(Word on the street Jean's a Unix user.) 

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-21 09:29]:
> But isn't the "lumping" in this context lumping together the
> proprietary Unix systems (e.g. SunOS/Solaris), the Linux
> distros and the BSDs into Unix?

I would not say, I have actually understand you and agree with you
that they are "Unix" though I think it is better to say they are
"Unix-like", and I don't mind it.

> While the splitting is splitting the Unix into "Unix" and
> "Unix-like"?

Of course not only that... There are too many differences to explain
here, it's not subject for Emacs.

> > There is general tendency in Emacs society to go rather
> > towards "splitters" group. Lumpers don't participate much
> > in discussions.
> 
> That comment is so splitter. Why don't you join the lumper's
> camp and get into the game?

If in that camp there are nice people to meet, I will join. I don't
mind what they think or write.

> No, I disagree that is incorrect not to use it, because
> I think that distinctions in the world of technology should be
> made in terms of technology and reflect technology.

And me not, I think in terms of definitions and what companies,
governments, trademarks and thus people forcibly consent to.

And I recognize fully that you can call it as you wish, who cares.

I would not tell to somebody "Just take any Unix like GNU" because it
is not true, and I would not recommend Unix as it is not free software
(that I know). So in that sense for people who read this, not for you,
I was mentioning "Unix-like." Who cares for some if they want this or
that. There is artistic freedom too, freedom of expression.

> What some business dudes piled together in their fancy documents
> shouldn't influence how I, a technology person, refer to
> technology. dig(1)?

Then expect to get into discussions.

As me being from Europe I can see many things what African people
don't see, so I enter into discussions all the time, as I am bringing
some new reality onto them.

> > Do you see this letter A and A? Are they same? They look
> > same but they are not same, as they must be saved in quite
> > different locations by different impulses which are not
> > same.
> 
> Here we see my Lumper instinct, because I think they are
> both A.

They may be both similar to A, though they are never same, because you
said that A and A is equal to A, but it is not really, we stop our
observation of what it is at simple meaning, but as they are in
different space they cannot be equal. Not even those pixels are of
perfectly equal size, and their memory electrons are not in same
place, they are quite distinct to each other, in other words, what you
thought of (eq 'A 'A) ⇒ t is not what is reality.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> But isn't the "lumping" in this context lumping together the
>> proprietary Unix systems (e.g. SunOS/Solaris), the Linux
>> distros and the BSDs into Unix?
>
> I would not say, I have actually understand you and agree
> with you that they are "Unix" though I think it is better to
> say they are "Unix-like", and I don't mind it.

But for practical purposes Linux is Unix ...

And as an OS it is also Unix ...

And people refer to it as Unix often even casually, that term
includes all Unix in theory but in practice Linux and
the BSDs ... maybe some other?

So people us it like that already.

It just makes sense to them ;)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> I would not tell to somebody "Just take any Unix like GNU"
> because it is not true, and I would not recommend Unix as it
> is not free software (that I know). So in that sense for
> people who read this, not for you, I was mentioning
> "Unix-like." Who cares for some if they want this or that.
> There is artistic freedom too, freedom of expression.

It is a piece of technology!

Like an engine or something :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> They may be both similar to A, though they are never same,
> because you said that A and A is equal to A, but it is not
> really, we stop our observation of what it is at simple
> meaning, but as they are in different space they cannot be
> equal. Not even those pixels are of perfectly equal size,
> and their memory electrons are not in same place, they are
> quite distinct to each other, in other words, what you
> thought of (eq 'A 'A) ⇒ t is not what is reality.

Hahaha :D

Far out :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2022-02-20 02:51]:
> (Not a reply to any particular msg in this thread.)
> 
> https://en.wikipedia.org/wiki/Lumpers_and_splitters

It should be obvious that article itself was written by lumpers. 😉



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-02-20 01:31]:
> Jean Louis wrote:
> 
> > That means on Unix-like systems. It is better expressed that
> > way. GNU is Not Unix, true, though it is very much
> > Unix-like, such systems are mentioned as Unices if
> > I remember well.
> 
> But that is a formal distinction:
> 
>   A Unix-like (sometimes referred to as UN*X or *nix)
>   operating system is one that behaves in a manner similar to
>   a Unix system, although not necessarily conforming to or
>   being certified to any version of the Single UNIX
>   Specification. [1]
> 
> But I don't care about that. And for good reason, because in
> terms of technology a random Linux distribution found on
> DistroWatch.com [2] is as much Unix as anything else.

You can call it as you wish. Majority of people don't even know that
there is operating system inside, they call it computer and that's
it. They need not care as they belong in the group that does not see
or maybe don't want to see distinctions. Though operating system
makers and authors, they know that A is not B.

> I played ice hockey for more than a decade. I didn't wear
> a helmet a single time. But the IIHF says all players should
> wear helmets. That means it wasn't ice hockey, what I took
> part in was an "ice hockey-like sport". See? The absence of
> a helmet _is_ what "breaks" it!

Exactly, those are rules of the game.

You can play a game by not following rules, it will not be
counted. This is because of the agreements between people.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> You can play a game by not following rules, it will not be
> counted. This is because of the agreements between people.

If not as people, you can tell the to behave like-people.

-- 
underground experts united
https://dataswamp.org/~incal