Emacs closure at ~900MB?

Emacs closure at ~900MB?

[zimoun]

Dear,

I am building Docker images containing only Emacs and I find them really
big –– and I have a low upload bandwidth.

Well, using Guix 9e7b265, “guix size emacs” says:

--8<---------------cut here---------------start------------->8---
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  16.2%
/gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7            369.2   131.3  15.3%
/gnu/store/wn1m7lwnasvwygbaf8ky413qzbm96mys-emacs-27.1             859.7   106.2  12.4%
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2            132.8    53.2   6.2%
/gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20           723.7    49.0   5.7%
/gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1             110.2    38.1   4.4%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7   4.3%
/gnu/store/w5msvpf5gimpq9whyjimkzz80n2smw3w-ghostscript-with-cups-9.52   212.2    33.9   3.9%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    32.6   3.8%

[...]

total: 859.7 MiB
--8<---------------cut here---------------end--------------->8---

And I am surprised to see the package ’llvm’.  Is it expected?  This
package is dragged by mesa, dragged by gtk+.

--8<---------------cut here---------------start------------->8---
$ guix graph --path emacs llvm
emacs@27.1
gtk+@3.24.20
mesa@20.0.7
llvm@10.0.0
--8<---------------cut here---------------end--------------->8---

Is it possible to reduce the closure size of Emacs?


All the best,
simon

Re: Emacs closure at ~900MB?

[Pierre Neidhardt]

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

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

Here is a recipe:

--8<---------------cut here---------------start------------->8---
(define-public emacs-lucid
  (package
    (inherit emacs)
    (name "emacs-lucid")
    (synopsis "The Emacs text editor with Lucid support")
    (build-system gnu-build-system)
    (arguments
     (substitute-keyword-arguments (package-arguments emacs)
       ((#:configure-flags flags ''())
        `(cons "--with-x-toolkit=lucid" ,flags))
       ((#:phases phases)
        `(modify-phases ,phases
           (delete 'restore-emacs-pdmp)
           (delete 'strip-double-wrap)))))
    (inputs
     `(("libxaw" ,libxaw)
       ,@(alist-delete "gtk+" (package-inputs emacs))))))
--8<---------------cut here---------------end--------------->8---

Ideally, we would reduce the LLVM and Mesa closure sizes as I started
doing some weeks ago.

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

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

Re: Emacs closure at ~900MB?

[zimoun]

On Tue, 22 Sep 2020 at 13:31, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Here is a recipe:

Thank you for the recipe.


> Ideally, we would reduce the LLVM and Mesa closure sizes as I started
> doing some weeks ago.

Why does one of the GNU flagship software depend on LLVM?  And not
only on GNU toolchain?

Cheers,
simon

Re: Emacs closure at ~900MB?

[Pierre Neidhardt]

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

I don't think Mesa is GNU, is it?
Modern Mesa can only be built with LLVM as far as I get it.

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

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

Re: Emacs closure at ~900MB?

[Efraim Flashner]

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

On Tue, Sep 22, 2020 at 01:45:56PM +0200, Pierre Neidhardt wrote:
> I don't think Mesa is GNU, is it?
> Modern Mesa can only be built with LLVM as far as I get it.
> 

There is some sort of graphical pipe-lining done in mesa using llvm.
(The tests for this are known to fail on non-Intel architectures).
That's why mesa pulls in llvm.



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

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

[Giovanni Biscuolo]

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

Hello Pierre,

Pierre Neidhardt <mail@ambrevar.xyz> 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

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

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

[zimoun]

Hi,

On Thu, 24 Sep 2020 at 19:29, Giovanni Biscuolo <g@xelera.eu> 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 <https://issues.guix.gnu.org/43578>. :-)
If I understand correctly #43578 (not yet really tested).


Cheers,
simon

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

[Giovanni Biscuolo]

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

Hi zimounn

zimoun <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Thu, 24 Sep 2020 at 19:29, Giovanni Biscuolo <g@xelera.eu> 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 <https://issues.guix.gnu.org/43578>. :-)
> 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

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

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

[Pierre Neidhardt]

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

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/

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

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

[zimoun]

On Fri, 25 Sep 2020 at 10:28, Giovanni Biscuolo <g@xelera.eu> 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: <https://issues.guix.gnu.org/43578#8>


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

[Giovanni Biscuolo]

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

zimoun <zimon.toutoune@gmail.com> 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 <g@xelera.eu> 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

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

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

[zimoun]

On Tue, 29 Sep 2020 at 10:42, Giovanni Biscuolo <g@xelera.eu> 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]

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

Hello Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> On Tue, 29 Sep 2020 at 10:42, Giovanni Biscuolo <g@xelera.eu> 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

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

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

[Mark H Weaver]

Hi,

Giovanni Biscuolo <g@xelera.eu> 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?)

[Pierre Neidhardt]

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

Mark H Weaver <mhw@netris.org> 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?

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

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

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

[Mark H Weaver]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Mark H Weaver <mhw@netris.org> 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
<https://github.com/ch11ng/exwm/wiki#prerequisites> 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?)

[Pierre Neidhardt]

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

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/

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

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

[Pierre Neidhardt]

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

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

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")
     (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)))))
--8<---------------cut here---------------end--------------->8---

Thoughts?

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

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

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

[Bonface M. K.]

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

Pierre Neidhardt <mail@ambrevar.xyz> 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

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

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

[Pierre Neidhardt]

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

"Bonface M. K." <bonfacemunyoki@gmail.com> 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/

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

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

[Bonface M. K.]

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

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> "Bonface M. K." <bonfacemunyoki@gmail.com> 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

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

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

[zimoun]

Hi Pierre,

On Sun, 27 Sep 2020 at 12:54, Pierre Neidhardt <mail@ambrevar.xyz> 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?)

[Pierre Neidhardt]

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

zimoun <zimon.toutoune@gmail.com> 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.

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

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

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

[zimoun]

On Mon, 28 Sep 2020 at 11:25, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>
> zimoun <zimon.toutoune@gmail.com> 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?)

[Pierre Neidhardt]

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

See #43674.

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

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

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 <mail@ambrevar.xyz> 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]

Hi Bengt,

On Mon, 28 Sep 2020 at 21:16, Bengt Richter <bokr@bokr.com> 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?)

[zimoun]

Hi Mark,

On Sat, 26 Sep 2020 at 18:34, Mark H Weaver <mhw@netris.org> 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]

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

zimoun <zimon.toutoune@gmail.com> 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.  Is it
> possible to build Emacs with Gtk compiled without LLVM?

Not as far as I know, but it's worth investigating.

I believe it's possible to build GTK against a reduced Mesa and a
reduced LLVM.  See the discussions I started a few months ago on Mesa
and LLVM: we could save between 100 MiB and 300 MiB if I recall
correctly.

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

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

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

[Mark H Weaver]

zimoun <zimon.toutoune@gmail.com> 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?)

[Pierre Neidhardt]

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

Mark H Weaver <mhw@netris.org> 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/

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

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

[Giovanni Biscuolo]

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

Hello Mark,

thank you for your interest. 

Mark H Weaver <mhw@netris.org> 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

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