Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Giovanni Biscuolo]

Hello Simon,

zimoun  writes:

> On Tue, 29 Sep 2020 at 10:42, Giovanni Biscuolo  wrote:
>
>> Please consider I'm still on Emacs 26.3 since one package I use does not
>> work with 27.1... and I still have not tested "the bug" in a pure
>> anvironmentt with emacs 27.1 only
>
> Ouch!  Which one is it?

emacs-elfeed-org, bug #43243

I'm considering dismissing elfeed-org, it's useful but not unavoidable :-)

>> I'm affected by that bug every time I do:
>>
>> 1. on machine A: start emacs --daemon
>> 2. on machine B: ssh -Y me@A
>> 3. on machine B: emacsclient -c (in ssh session)
>
> Sorry, I miss where this emacsclient is started?  A or B?

on machine B

> If you start emacsclient on B and try to connect over SSH to the
> server on A, which option do you provide?  (naive question because I
> have always failed to do that :-))

Sorry I don't understand the steps you are trying to reproduce: in the
use case above I'm starting "emacsclient -c" from machine B when
remotely connected via ssh (-Y) to machine A; I'm running emacsclient -c
over ssh

> Personally, I have 2 uses cases:
>
>  i.
> machine A: emacs --daemon
> machine B: ssh -C me@A -t emacsclient -t

"emacsclient -t" (over ssh) always works for me also, no crashes after
disconnection (no X toolkit used in this case)

> and I never do "ssh -CX me@A -t emacsclient -c" because the network is
> usually too slow to export DISPLAY; machines A and B are usually a bit
> far in my cases.

I never tested using "Force pseudo-terminal" (-t) when connecting over
ssh: I should try that!

I usually use X forwarding over VPN over 4G connection: it's a little
bit slow but usable.

> ii.
> machine B: start emacs --daemon
> machine B: emacsclient -c
> machine B: open via TRAMP over ssh on A
>
> And Tramp crashes time to time.

Ouch: it never happens to me, I mean /ssh:.../ TRAMP method always works
like a charm.  Have you tried installing "emacs-tramp" package?  I had
some issue with the built-in emacs TRAMP and realized that emacs-tramp
guix package is more up to date with upstream.

>> AFAIU this bug is still affecting other Emacs users using GTK as X
>> toolkit.
>
> Yeah, for sure.  And as you noted too, it is difficult to know what is
> the exact status of this bug. :-)

Technically is closed but actually it should be "exausted" :-D

[...]

Ciao, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

On Tue, 29 Sep 2020 at 10:42, Giovanni Biscuolo  wrote:

> Please consider I'm still on Emacs 26.3 since one package I use does not
> work with 27.1... and I still have not tested "the bug" in a pure
> anvironmentt with emacs 27.1 only

Ouch!  Which one is it?


> I'm affected by that bug every time I do:
>
> 1. on machine A: start emacs --daemon
> 2. on machine B: ssh -Y me@A
> 3. on machine B: emacsclient -c (in ssh session)

Sorry, I miss where this emacsclient is started?  A or B?
If you start emacsclient on B and try to connect over SSH to the
server on A, which option do you provide?  (naive question because I
have always failed to do that :-))

Personally, I have 2 uses cases:

 i.
machine A: emacs --daemon
machine B: ssh -C me@A -t emacsclient -t

and I never do "ssh -CX me@A -t emacsclient -c" because the network is
usually too slow to export DISPLAY; machines A and B are usually a bit
far in my cases.

ii.
machine B: start emacs --daemon
machine B: emacsclient -c
machine B: open via TRAMP over ssh on A

And Tramp crashes time to time.


> AFAIU this bug is still affecting other Emacs users using GTK as X
> toolkit.

Yeah, for sure.  And as you noted too, it is difficult to know what is
the exact status of this bug. :-)


All the best,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Giovanni Biscuolo]

Hello Mark,

thank you for your interest. 

Mark H Weaver  writes:

[...]

>> IMHO it's useful to have emacs-lucid in official Guix, with subsitutes
>> available for end users (I'm not using emacs in daemon mode over X11
>> over SSH for fear of chrashes).
>
> FYI, our 'emacs-no-x-toolkit' package has a closure size of 390.9 MiB
> and does _not_ have the Gtk bug described above.  That's why I use it.

Yes I know that emacs version, I'm also considering using it (I do not
remember why I decided I needed an X toolkit... I should just try).

> Are there additional benefits to 'emacs-lucid' that are not already
> addressed by 'emacs-no-x-toolkit'?

emacs-lucid would have an X toolkit that does not crash the daemon when
remotely connecting, some people like to have that (an X tookit I mean)
even if usually it's not strictly needed.

> I'm not necessarily opposed to adding another Emacs variant, but I
> don't yet understand the motivation.

Help some users avoid experiencing "the bug", but I understand that
probably the use base for emacs-lucid is tiny.

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Giovanni Biscuolo]

zimoun  writes:

Please consider I'm still on Emacs 26.3 since one package I use does not
work with 27.1... and I still have not tested "the bug" in a pure
anvironmentt with emacs 27.1 only

> On Fri, 25 Sep 2020 at 10:28, Giovanni Biscuolo  wrote:

[...]

>> AFAIU having a public emacs-lucid in Guix master is a better solution
>> for users, but I may be missing something! :-D
>
> You mean better because the GTK bug?  Well, I am extensively using Emacs
> and I do not remember hitting this bug.  Maybe I do not use Emacs
> enough. ;-)

Yes I mean that precise bug, the one that triggers a warning every time
we start emacs with GTK.  Actually that bug has been closed upstream, so
I don't really understand if it will be ever solved.

I'm affected by that bug every time I do:

1. on machine A: start emacs --daemon
2. on machine B: ssh -Y me@A
3. on machine B: emacsclient -c (in ssh session)
4. on machine B: C-x C-c (exit emacsclient)
5. on machine B: (the ssh session is "frozen" in S+ status)
6. on machine B: C-c C-c (stop the remote ssh session)
7. on machine A: (emacs daemon crashed) 

AFAIU this bug is still affecting other Emacs users using GTK as X
toolkit.

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Pierre Neidhardt]

Mark H Weaver  writes:

> LLVM is an optional input for Mesa which enables the Gallium 'llvmpipe'
> driver, a fast software rasterizer that uses LLVM to do runtime code
> generation.
>
>   https://docs.mesa3d.org/gallium/drivers/llvmpipe.html
>
> Among other things, this allows use of the GNOME Shell on systems
> without hardware support for 3D graphics.
>
> GTK depends on Mesa.
>
> ...
>
> Alternatively, for those who do not wish to maintain their own private
> branch, here's a hybrid approach that might be workable: add a local
> variant of 'mesa' with 'llvm' removed from 'inputs' (and "-Dllvm=true"
> removed from the configure flags), then add a local variant of 'gtk+'
> that uses your local 'mesa', and finally add a local variant of 'emacs'
> that uses your local 'gtk+'.  I guess those last two steps could be
> replaced by deep package rewrites, although I've never used that
> functionality since I prefer the more flexible "private git branch"
> approach to customizing Guix to my preferences.

If I understand correctly, we could have a gtk-minimal that depends on
mesa-minimal which is built without LLVM.  If llvmpipe is only useful
for GNOME Shell and the like, it's very likely that Emacs and many other
packages don't need GTK-on-LLVM.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Mark H Weaver]

zimoun  writes:

> However, I am still confused that the GNU Emacs package with default
> options (--with-modules, --with-cairo, --disable-build-details)
> depends on LLVM via GTK+ and Mesa; and not on only GNU tools.

LLVM is an optional input for Mesa which enables the Gallium 'llvmpipe'
driver, a fast software rasterizer that uses LLVM to do runtime code
generation.

  https://docs.mesa3d.org/gallium/drivers/llvmpipe.html

Among other things, this allows use of the GNOME Shell on systems
without hardware support for 3D graphics.

GTK depends on Mesa.

> Is it possible to build Emacs with Gtk compiled without LLVM?

When LLVM was first added to Mesa's inputs in Guix, I reverted that
commit on my private branch for a year or two, to avoid building LLVM.
This saved me disk space and compile time, since I don't use substitutes
and therefore build everything from source anyway.  For those who use
substitutes, this change would be more costly.  I eventually gave up on
this since I now need LLVM for IceCat anyway.

Alternatively, for those who do not wish to maintain their own private
branch, here's a hybrid approach that might be workable: add a local
variant of 'mesa' with 'llvm' removed from 'inputs' (and "-Dllvm=true"
removed from the configure flags), then add a local variant of 'gtk+'
that uses your local 'mesa', and finally add a local variant of 'emacs'
that uses your local 'gtk+'.  I guess those last two steps could be
replaced by deep package rewrites, although I've never used that
functionality since I prefer the more flexible "private git branch"
approach to customizing Guix to my preferences.

  Mark

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi Bengt,

On Mon, 28 Sep 2020 at 21:16, Bengt Richter  wrote:

> I am wondering if there is a pure-wayland-client version of emacs, as 
> discussed here[1]

About Wayland, I do not know.

> A debian emacs-nox appears to exist [2]

Do you mean the Guix package 'emacs-no-x'?


> Perhaps such an emacs package could have a smaller closure,
> by depending as simply as possible on wayland (sans Xwayland)?

Thank you for the idea.  I do not know much about Wayland.  I will give a look.

Cheers,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Bengt Richter]

Hi Simon,

On +2020-09-28 10:56:55 +0200, zimoun wrote:
> Hi Pierre,
> 
> On Sun, 27 Sep 2020 at 12:54, Pierre Neidhardt  wrote:
> 
> > Just tested, EXWM works with emacs-no-x-toolkit!
> 
> Cool!
> 
> 
> > So I suggest we add the following packages:
> >
> > --8<---cut here---start->8---
> > (define-public emacs-no-x-toolkit-xelb
> >(package
> >  (inherit emacs-xelb)
> >  (name "emacs-no-x-toolkit-xelb")
> 
> [...]
> 
> > (define-public emacs-no-x-toolkit-exwm
> >(package
> >  (inherit emacs-exwm)
> >  (name "emacs-no-x-toolkit-exwm")
> 
> It appears to me more logical to name it: emacs-xelb-no-x-toolkit;
> appending the variation last.
> 
> 
> All the best,
> simon
>

I am wondering if there is a pure-wayland-client version of emacs, as discussed 
here[1]
A debian emacs-nox appears to exist [2]

On my system, apt show emacs-nox tells me
--8<---cut here---start->8---
Description: GNU Emacs editor (without GUI support)
 GNU Emacs is the extensible self-documenting text editor.  This
 package contains a version of Emacs compiled without support for X,
 and provides only a text terminal interface.
--8<---cut here---end--->8---

IIUC, wayland gets input events like keystrokes from the kernel and sends them 
by
registered call-backs to the programs that thus registered interest.

But I wonder how this connects with emacs and its use of pts/ptmx, readline, 
etc ...
Is there a legacy layer of vt encoding/decoding that could be eliminated by a 
more
direct use of wayland protocol?

Perhaps such an emacs package could have a smaller closure,
by depending as simply as possible on wayland (sans Xwayland)?

If the low level stuff were wrapped nicely in some guile extension modules,
I suspect other uses than emacs would be found.

[1] 
https://emacs.stackexchange.com/questions/48561/is-there-an-x11-free-build-of-emacs-that-can-run-on-wayland-not-going-through-x
[2] https://packages.debian.org/sid/emacs-nox
-- 
Regards,
Bengt Richter

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

On Mon, 28 Sep 2020 at 11:25, Pierre Neidhardt  wrote:
>
> zimoun  writes:
>
> > It appears to me more logical to name it: emacs-xelb-no-x-toolkit;
> > appending the variation last.
>
> Depends how you look at it ;)  But I don't have a strong opinion.

Me neither.  Just it seems more consistent:
 1. with how "guix search" works (see 'relevance')
and 2. with the description which says "`emacs-xelb' is a pure Emacs
Lisp [...]".

Cheers,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Bonface M. K.]

Pierre Neidhardt  writes:

> "Bonface M. K."  writes:
>
>> Wouldn't that be redundant? If you wanted to use
>> EXWM, we already have EXWM provided on MELPA, so
>> you could just set that up. That's IMHO though.
>
> Maybe there is a misunderstanding.  We provide EXWM as a Guix package
> for those who don't want to use Emacs' own package manager.  Without an
> emacs-no-x-toolkit-exwm package, Guix+EXWM users would be forced to drag
> GTK->Mesa->LLVM just to start Emacs.
>

Ooof! I never thought about it /that/ way. Thanks
for clarifying.

> Besides, MELPA can't be used to build Guix systems, images and the like.

Yeah sure. In that case, it makes alot of sense to
have emacs-no-x-toolkit-exwm packaged.

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi Pierre,

On Sun, 27 Sep 2020 at 12:54, Pierre Neidhardt  wrote:

> Just tested, EXWM works with emacs-no-x-toolkit!

Cool!


> So I suggest we add the following packages:
>
> --8<---cut here---start->8---
> (define-public emacs-no-x-toolkit-xelb
>(package
>  (inherit emacs-xelb)
>  (name "emacs-no-x-toolkit-xelb")

[...]

> (define-public emacs-no-x-toolkit-exwm
>(package
>  (inherit emacs-exwm)
>  (name "emacs-no-x-toolkit-exwm")

It appears to me more logical to name it: emacs-xelb-no-x-toolkit;
appending the variation last.


All the best,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi Mark,

On Sat, 26 Sep 2020 at 18:34, Mark H Weaver  wrote:

> FYI, our 'emacs-no-x-toolkit' package has a closure size of 390.9 MiB
> and does _not_ have the Gtk bug described above.  That's why I use it.

Thank you for the information.  It is worth knowing.  I am currently
giving it a try.

However, I am still confused that the GNU Emacs package with default
options (--with-modules, --with-cairo, --disable-build-details)
depends on LLVM via GTK+ and Mesa; and not on only GNU tools.  Is it
possible to build Emacs with Gtk compiled without LLVM?

All the best,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Pierre Neidhardt]

"Bonface M. K."  writes:

> Wouldn't that be redundant? If you wanted to use
> EXWM, we already have EXWM provided on MELPA, so
> you could just set that up. That's IMHO though.

Maybe there is a misunderstanding.  We provide EXWM as a Guix package
for those who don't want to use Emacs' own package manager.  Without an
emacs-no-x-toolkit-exwm package, Guix+EXWM users would be forced to drag
GTK->Mesa->LLVM just to start Emacs.

Besides, MELPA can't be used to build Guix systems, images and the like.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Bonface M. K.]

Pierre Neidhardt  writes:

> Just tested, EXWM works with emacs-no-x-toolkit!
>

Just tested it too, and it works for me too :)

> So I suggest we add the following packages:
>
> (define-public emacs-no-x-toolkit-xelb
>(package
>  (inherit emacs-xelb)
>  (name "emacs-no-x-toolkit-xelb")
>  (arguments
>   (substitute-keyword-arguments (package-arguments emacs-xelb)
> ((#:emacs emacs) `,emacs-no-x-toolkit)
>
> (define-public emacs-no-x-toolkit-exwm 
>(package
>  (inherit emacs-exwm)
>  (name "emacs-no-x-toolkit-exwm")
>  (synopsis "Emacs X window manager (without X toolkit)")
>  (propagated-inputs
>   `(("emacs-no-x-toolkit-xelb" ,emacs-no-x-toolkit-xelb)))
>  (arguments
>   (substitute-keyword-arguments (package-arguments emacs-exwm)
> ((#:emacs emacs) `,emacs-no-x-toolkit)
>
> Thoughts?

Wouldn't that be redundant? If you wanted to use
EXWM, we already have EXWM provided on MELPA, so
you could just set that up. That's IMHO though.

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Pierre Neidhardt]

I'll test EXWM with emacs-no-x-toolkit.

I think the discussion around emacs-lucid started out of ignorance for
the emacs-no-x-toolkit package.  If the latter happens to be a better
option, I propose that we don't add emacs-lucid but instead advertise
emacs-no-x-toolkit better, say, mention it in the description of the
"emacs" package.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Mark H Weaver]

Pierre Neidhardt  writes:

> Mark H Weaver  writes:
>
>> Are there additional benefits to 'emacs-lucid' that are not already
>> addressed by 'emacs-no-x-toolkit'?  I'm not necessarily opposed to
>> adding another Emacs variant, but I don't yet understand the motivation.
>
> Does EXWM run on emacs-no-x-toolkit?

I don't have time to test it now, but I guess that it does, because
 doesn't mention
anything requirement on which toolkit Emacs is built with.

Anyway, I have no objection to adding 'emacs-lucid' if there's interest.

  Mark

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Mark H Weaver]

Hi,

Giovanni Biscuolo  writes:

> Given the size "issue" of emacs-with-gtk and the emacs warning on the
> long standing Gtk+ bug:
>
> --8<---cut here---start->8---
>
> Warning: due to a long standing Gtk+ bug
> https://gitlab.gnome.org/GNOME/gtk/issues/221
> Emacs might crash when run in daemon mode and the X11 connection is 
> unexpectedly lost.
> Using an Emacs configured with --with-x-toolkit=lucid does not have this 
> problem.
>
> --8<---cut here---end--->8---
>
> IMHO it's useful to have emacs-lucid in official Guix, with subsitutes
> available for end users (I'm not using emacs in daemon mode over X11
> over SSH for fear of chrashes).

FYI, our 'emacs-no-x-toolkit' package has a closure size of 390.9 MiB
and does _not_ have the Gtk bug described above.  That's why I use it.

Are there additional benefits to 'emacs-lucid' that are not already
addressed by 'emacs-no-x-toolkit'?  I'm not necessarily opposed to
adding another Emacs variant, but I don't yet understand the motivation.

  Thanks,
Mark

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

On Fri, 25 Sep 2020 at 10:28, Giovanni Biscuolo  wrote:

> If that's the case could you please add a comment in #41732 that points
> to #43538 explaining that it solves the use cases of #41732, possibly
> with some examples and/or a Coockbook section?

Attempt currently happening… :-)

See: 


> Re the subject: do you think #43578 can help users in getting
> emacs-lucid starting from emacs? Do you have an example please?

I do not know.  However, I am not personally motivated by emacs-lucid.
Maybe I miss something but if I read correctly, this toolkit is old and
so I do not know how it is maintained.  Is the new HarfBuzz included?

Well, #41732 and #43578 change the Emacs VM when compiling Emacs
packages and not the rendering toolkit.  Other said, compiling Emacs
packages with the package emacs or emacs-lucid is exactly the same.  The
difference between emacs and emacs-lucid is the rendering toolkit, not
the VM.  AFAIU.


> AFAIU having a public emacs-lucid in Guix master is a better solution
> for users, but I may be missing something! :-D

You mean better because the GTK bug?  Well, I am extensively using Emacs
and I do not remember hitting this bug.  Maybe I do not use Emacs
enough. ;-)


Cheers,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Pierre Neidhardt]

Feel free to send a patch with my emacs-lucid recipe if you feel that
#43578 is not enough.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Giovanni Biscuolo]

Hi zimounn

zimoun  writes:

> Hi,
>
> On Thu, 24 Sep 2020 at 19:29, Giovanni Biscuolo  wrote:
>
>> P.S.: I also know there's the http://issues.guix.gnu.org/41732#7
>> "Implement a wrapper so users can build the Emacs packages using a
>> version of their choosing" patch around, but it's for a different
>> (expert) use case AFAIU
>
> Now this patch is superseded by . :-)
> If I understand correctly #43578 (not yet really tested).

Thanks for the update!

If that's the case could you please add a comment in #41732 that points
to #43538 explaining that it solves the use cases of #41732, possibly
with some examples and/or a Coockbook section?

Re the subject: do you think #43578 can help users in getting
emacs-lucid starting from emacs? Do you have an example please?

AFAIU having a public emacs-lucid in Guix master is a better solution
for users, but I may be missing something! :-D

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi,

On Thu, 24 Sep 2020 at 19:29, Giovanni Biscuolo  wrote:

> P.S.: I also know there's the http://issues.guix.gnu.org/41732#7
> "Implement a wrapper so users can build the Emacs packages using a
> version of their choosing" patch around, but it's for a different
> (expert) use case AFAIU

Now this patch is superseded by . :-)
If I understand correctly #43578 (not yet really tested).


Cheers,
simon

emacs-lucid (was Re: Emacs closure at ~900MB?)

[Giovanni Biscuolo]

Hello Pierre,

Pierre Neidhardt  writes:

> Indeed, if you build the Lucid version you get a much smaller Emacs.
> We had discussed this some time ago.

I saw that discussion last June but probably I missed something: have
you already sent a patch to request emacs-lucid inclusion in master?

Given the size "issue" of emacs-with-gtk and the emacs warning on the
long standing Gtk+ bug:

--8<---cut here---start->8---

Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is 
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this 
problem.

--8<---cut here---end--->8---

IMHO it's useful to have emacs-lucid in official Guix, with subsitutes
available for end users (I'm not using emacs in daemon mode over X11
over SSH for fear of chrashes).

Thanks a lot for your recipe!

[...]


P.S.: I also know there's the http://issues.guix.gnu.org/41732#7
"Implement a wrapper so users can build the Emacs packages using a
version of their choosing" patch around, but it's for a different
(expert) use case AFAIU

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature