Re: Creating an Emacs Home Configuration Service

[Zain Jabbar]

Aloha Guix Development Team,

Thank you for this email. Your advice was directed very kindly and is
very helpful. I have tried to revise the code based on your email. I
also checked the setting for plaintext mode in GMail; I hope this
makes the email easier to read.

First, I define a configuration (without serialization currently).

#+BEGIN_SRC scheme
(define file-likes? (list-of file-like?))

(define-configuration/no-serialization emacs-configuration
  (emacs-packages
   (file-likes (list (specification->package "emacs-next"))) "Files")
  (early-init
   (list '()) "Early-Init")
  (init
   (list '()) "Init"))
#+END_SRC

Then, I define an =emacs-configuration-service= that takes in a
configuration. This service will add packages in the =emacs-packages=
to the profile, and append the S-Expressions in =early-init= and
=init= to $XDG_CONFIG_HOME/emacs/early-init.el and
$XDG_CONFIG_HOME/emacs/init.el respectively. The service has
definition,

#+BEGIN_SRC scheme
(define-public emacs-configuration-service
  (service-type (name (symbol-append 'emacs-configuration))
(extensions
(list (service-extension
home-profile-service-type
(lambda (config) (emacs-configuration-emacs-packages config)))
   (service-extension
home-xdg-configuration-files-service-type
(lambda (config)
  (list
   `("emacs/init.el" ,(scheme-file "init.el"
  (emacs-configuration-init config)
  #:splice? #:t))
   `("emacs/early-init.el" ,(scheme-file "early-init.el"
  (emacs-configuration-early-init config)
  #:splice? #:t)))
(default-value (emacs-configuration))
(description "Configures Emacs init.el")))
#+END_SRC

This version of the service is one big service that only takes in one
configuration file. So in order to configure bits and pieces of Emacs,
for example evil-mode and vertico we can append emacs-configurations
into one big configuration. I do this as follows.

#+BEGIN_SRC scheme
(define evil-configuration
  (emacs-configuration
   (emacs-packages (list (specification->package "emacs-evil")))
   (init '((evil-mode 1)

(define vertico-configuration
  (emacs-configuration
   (emacs-packages (list (specification->package "emacs-vertico")))
   (init '((vertico-mode 1)

(define-public total-emacs-configuration
  (fold (lambda (config-1 config-2) (emacs-configuration
 (init (append (emacs-configuration-init config-1)
   (emacs-configuration-init config-2)))
 (early-init (append (emacs-configuration-early-init config-1)
(emacs-configuration-early-init config-2)))
 (emacs-packages (append (emacs-configuration-emacs-packages config-1)
 (emacs-configuration-emacs-packages config-2)
(emacs-configuration)
(list evil-configuration vertico-configuration)))
#+END_SRC

We can actually go crazy with this idea. The next source block is a
generalization of the last one. Rather than declaring the list of
configurations, we have Guile figure out all of the bound
=emacs-configurations= in the current module and append them that way.

#+BEGIN_SRC scheme
(define-public total-emacs-configuration
  (fold (lambda (config-1 config-2) (emacs-configuration
 (init (append (emacs-configuration-init config-1)
   (emacs-configuration-init config-2)))
 (early-init (append (emacs-configuration-early-init config-1)
(emacs-configuration-early-init config-2)))
 (emacs-packages (append (emacs-configuration-emacs-packages config-1)
 (emacs-configuration-emacs-packages config-2)
(emacs-configuration)

(filter emacs-configuration?
(map variable-ref
 (filter variable-bound?
 (hash-map->list (lambda (x y) y) (struct-ref (current-module) 0)))
#+END_SRC

What further improvements could I add to this system? The end goal
(hopefully) is to help add another home service to Guix. I was
inspired by David Wilson's call to action during his Guix Home talk at
the 10 year anniversary event.



On Mon, Oct 17, 2022 at 12:09 PM  wrote:
>
> October 17, 2022 2:38 AM, "Zain Jabbar"  wrote:
>
> > Aloha Guix Development Team,
> >
> > Running =guix home search emacs= returns nothing. I also could not find an 
> > email using =C-u M-x
> > debbugs-gnu= about an Emacs configuration service.
> >
> > This is my first email to this mailing address. Please give me pointers on 
> > formatting and further
> > improvements.
>
> I think you sent an html email.  Generally you want to send plain text 
> emails.  :)
>
> > I have attempted to make an =emacs-home-service-type= so that it is 
> > possible to configure Emacs
> > using Guix home. This code is extremely preliminary hence I don't even 
> > think it is worth sending as
> > a patch. Also I have never worked on a multi person Git project before and 
> > do not know how to solve
> > the keyring error I get when using guix pull. I will outline what my code 
> > does and what features I
> > would like to add.
> >
> > #+BEGIN_SRC scheme
> > (define* (emacs-configuration-service name #:key (init '()) (early-init 
> > '()) (emacs-packages '()))
> > (service-type (name (symbol-append 'emacs- name 

Re: Add earlyoom service to %desktop-services?

[jbranso]

October 17, 2022 7:24 AM, "Pkill9"  wrote:

> I think that the earlyoom service is a necessity for a Guix system
> desktop.
> 
> For those who don't know what it does, EarlyOOM (early out-of-memory)
> is a daemon that kills applications when the amount of memory available
> falls below a certain percentage of the maximum, by default 10%. There
> is already an OOM killer in the kernel, but it's too lax and
> applications that consume too much memory can cause the system to
> freeze.
> 
> I've used this for a while and many times it has kicked in and works
> well for my laptop. I think adding it to the default desktop services
> will give Guix System on desktop greater stability, which would
> encourage adoption of Guix System on the desktop
> 
> What do you, reader, think?

+1

Applications to kill: icecat, chromium, firefox, chromium, blender,
 etc.

I would recommend that we do include "firefox" and "chromium" as
applications that we would kill.  I use nongnu for firefox, and 
I bet there are others that use stock chromium or things like it.

Just me 2 cents.

Joshua

Re: Creating an Emacs Home Configuration Service

[jbranso]

October 17, 2022 2:38 AM, "Zain Jabbar"  wrote:

> Aloha Guix Development Team,
> 
> Running =guix home search emacs= returns nothing. I also could not find an 
> email using =C-u M-x
> debbugs-gnu= about an Emacs configuration service.
> 
> This is my first email to this mailing address. Please give me pointers on 
> formatting and further
> improvements.

I think you sent an html email.  Generally you want to send plain text emails.  
:)
 
> I have attempted to make an =emacs-home-service-type= so that it is possible 
> to configure Emacs
> using Guix home. This code is extremely preliminary hence I don't even think 
> it is worth sending as
> a patch. Also I have never worked on a multi person Git project before and do 
> not know how to solve
> the keyring error I get when using guix pull. I will outline what my code 
> does and what features I
> would like to add.
> 
> #+BEGIN_SRC scheme
> (define* (emacs-configuration-service name #:key (init '()) (early-init '()) 
> (emacs-packages '()))
> (service-type (name (symbol-append 'emacs- name '-configuration))
> (extensions
> (list (service-extension
> home-profile-service-type
> (lambda (config) emacs-packages))
> (service-extension
> home-files-service-type
> (lambda (config)
> (list
> `(,(string-append
> ".config/emacs/services/" (symbol->string name) ".el")
> ,(scheme-file (string-append (symbol->string name) ".el")
> init #:splice? #t))
> `(,(string-append
> ".config/emacs/early-services/" (symbol->string name) ".el")
> ,(scheme-file (string-append "early-" (symbol->string name) ".el")
> early-init #:splice? #t)))
> (default-value #f)
> (description "Configures Emacs init.el")))
> 
> (define-public emacs-init-service-type
> (service-type (name 'home-emacs)
> (extensions
> (list (service-extension
> home-profile-service-type
> (lambda (config) (list emacs-next)))
> (service-extension
> home-files-service-type
> (lambda (config)
> (list
> `(".config/emacs/early-init.el"
> ,(scheme-file
> "early-init.el"
> '((mapc
> 'load (file-expand-wildcards
> "~/.config/emacs/early-services/*.el")))
> #:splice? #t))
> `(".config/emacs/init.el"
> ,(scheme-file
> "init.el"
> '((mapc
> 'load (file-expand-wildcards
> "~/.config/emacs/services/*.el")))
> #:splice? #t)))
> (default-value #f)
> (description "Configures Emacs init.el")))
> #+END_SRC
> 
> I define a general configuration service generator which takes in four things:
> 1. The =name= of the service
> 2. The configuration to be ran in =init.el=
> 3. The configuration to be ran in =early-init.el=
> 4. The packages in Guix to be added to the =home-profile=.
> 
> After giving the =name=, =packages=, and =config.el= files we get a new 
> service type that we can
> add to our home declaration. This service will then add a file in
> =~/.config/emacs/services/emacs-{NAME}-configuration.el=. I then have another 
> service that places
> an =init.el= which loads everything in the service directory.
> 
> If we want to install and configure =evil-mode= using this =home-service= we 
> may define the
> following somewhere.
> 
> #+BEGIN_SRC scheme
> (define-public emacs-evil-service-type
> (emacs-configuration-service
> 'evil #:emacs-packages (list emacs-evil)
> #:init '((evil-mode 1
> #+END_SRC
> 
> Within our =home-environment= we may add the service using:
> 
> #+BEGIN_SRC scheme
> (home-environment
> ;; ...Things in the home-environment...
> (services
> (list
> ;; ...Other Services...
> (service emacs-evil-service-type
> #+END_SRC
> 
> There are some missing features I want to add.
> 
> 1. Have the =home-emacs-*-service-type= service-types add to the =init.el= 
> directly rather than
> within a folder to be loaded. I couldn't add two files with the same name to 
> the store. So I have
> emacs-evil.el in the store to be placed separately later rather than 
> appending to the existing
> init.el file.
> 
> 2. Have Emacs update whenever the =home-environment= is updated. Meaning, if 
> I did not add
> =(service emacs-evil-service-type)= in my =home-environment= then obviously 
> =M-x evil-mode= should
> not work. But after adding the service then I want =M-x evil-mode= to work 
> without having to
> restart Emacs. I do not understand the Emacs loading system on Guix well 
> enough to know why it does
> not work. Skipping all of the =home-service= stuff, running =guix install 
> emacs-evil-mode= then
> =(guix-emacs-autoload-packages)= does not let emacs know that =evil-mode= is 
> installed. I would
> need to close Emacs and start Emacs again for Emacs to know about =evil-mode= 
> being installed.
> 
> 3. Use configurations somehow. I have completely neglected this feature in my 
> system. I do not know
> what would be useful there.

I believe that you are referring to using scheme records to configure the emacs 
service.  :)

I would recommend using (define-configuration ...) procedure.

(There is a define-record-type* as well, but I think the consensus is that 
define-configuration* is a little easier to 

Re: bug#58417: Installer script no longer works with `yes` utility

[Maxim Cournoyer]

Hi,

zimoun  writes:

> Hi Maxim,
>
> On dim., 16 oct. 2022 at 21:22, Maxim Cournoyer  
> wrote:
>
>> If I understood Tobias, they were not suggesting to make the
>> non-interactive installation use case harder/impossible, just to change
>> it from 'yes | ./install.sh' to 'yes "" | ./install.sh', which would
>> give us the freedom to choose a default value of either yes or no for
>> each question.
>
> Thanks for explaining.
>
> IIUC, is the point to have 'default | ./install.sh'?

What do you mean by 'default | ./install.sh' ?  I think Tobias' point
was to have the ability for a newline (RET) to mean either YES or NO,
compared to the current case where it always mean YES.  "yes ''" does
this: enter nothing then RET, repeatedly.

-- 
Thanks,
Maxim

Re: Guix Goals: One Hackable Developer Tool To Rule Them All

[Liliana Marie Prikler]

Am Sonntag, dem 16.10.2022 um 15:03 -0500 schrieb jgart:
> On Sun, 16 Oct 2022 20:50:47 +0200 Liliana Marie Prikler
>  wrote:
> 
> > makes your goal a somewhat stupid one if you don't actually specify
> > what it has to do on a per-project basis.
> 
> hi lilyp,
> 
> That's a bit harsh to say that my idea is "stupid" even in light of
> your qualifier.
> 
> If you read the previous thread you can see some of my proposals on a
> per language basis.
For context, the "goal" here refers to the individual goal, e.g.
"format", as specified in the initial post.  If it only ever covers the
most common case per programming language, that is a very stupid tool
indeed.

> There's absolutely no requirement for me to work out the whole
> solution just yet on this email thread or to offer per project
> details. I'm not at the stage of proposing per-project ideas. I'm
> just casually brainstorming with those colleagues who want to. If
> that's too stressful to do then anyone is free to opt out of the
> conversation. There's no need to call it "stupid". Instead, ask me to
> expound on it in a friendly way instead if something is not clear or
> not yet stated.
I am insisting on this notion of per-projectness, because it is key to
you understanding that you are indeed trying to construct a build
system.¹  Perhaps a very crude one, but a build system still.  Your
logical foundation are the following statements:

1. Every project written in L uses T for a specific task.
2. P is written in L.
3. Therefore P uses T for that task.

By constructing a per-task mapping of L ~> T, you can offer a unified
solution.

The truth, however, is more complicated.

1. Every sufficiently mature programming language L has at least one
task such that at least two tools T, T', T != T' are used in different
projects to achieve it.
2. There exist projects that are not limited to a single programming
language.

You can of course try to be smarter than that and try to figure out
which tools to invoke based on the existence and contents of certain
magic files, but note that at this point you're doing significantly
more work than in the declarative approach you rejected.

> > I don't think it'd be that.  Note that you have the full power of
> > Guix/Guile at your disposal, so you can encapsulate much of it in
> > channels.  Is it a good idea to do so?  Hell, no.    
> 
> If Guix channels don't give users enough
> freedom/hackability/extensibility
> to do what they want then maybe that's something that should be
> looked into. I would consider it a bug, and a limitation of the
> system. There should be enough trust in our community to allow users
> to hack channels the way they want and to contribute back to GNU Guix
> proper if they so choose.  Restrictions shouldn't be built into the
> system to prevent users from doing x, y, z with regards to extending
> it.  There should only be trust regarding extensibility. That's what
> made Guix stand out to me from the start. If that is not the case
> going forward then I will lose hope in Guix and would rather invest
> my time chasing that dream elsewhere. The extensibility thesis that
> Guix subscribes to (atleast to my understanding) involves trust in
> its users instead of giving them a limiting DSL and telling them what
> they are and are not allowed to do with it.
> 
> I came to GNU Guix because of this freedom of extensibility and these
> ideals that I perceived in channels and in the system as a whole.
> Contributing back to upstream not a limiting feature that is
> "designed in" to Guix in order to enforce it. I don't want to be
> limited that way. This trust has to exist if it wants to cooperate
> with the Schemer spirit.
I believe you're attacking a straw man here.  I'm not telling you that
you can't run with scissors, only that it'd be unwise if you did.

> > Refusing to use the tools your colleagues are using to instead hack
> > on your own is not a recipe for success.
> 
> I'm currently using my colleagues tools extensively. Not sure what
> you mean here...
This is calling back to the main motivation outlined in the initial
post; rather than invoking the linters, formatters, etc., you simply
wrap them in Guix.  It is almost always preferable to provide a
solution that works even for those who don't use Guix – for example a
"make indent" rule, etc.

Cheers

¹ Also note that pants, which seems to be a source of your inspiration,
describes itself as a build system.  Compare the already mentioned GWL
for a build system already based on Guix, albeit focused on scientific
workflows, and potato-make for a simplistic Guile-based build system.

Re: Add earlyoom service to %desktop-services?

[Csepp]

Pkill9  writes:

> I think that the earlyoom service is a necessity for a Guix system
> desktop.
>
> For those who don't know what it does, EarlyOOM (early out-of-memory)
> is a daemon that kills applications when the amount of memory available
> falls below a certain percentage of the maximum, by default 10%. There
> is already an OOM killer in the kernel, but it's too lax and
> applications that consume too much memory can cause the system to
> freeze.
>
> I've used this for a while and many times it has kicked in and works
> well for my laptop. I think adding it to the default desktop services
> will give Guix System on desktop greater stability, which would
> encourage adoption of Guix System on the desktop
>
> What do you, reader, think?

Good idea, iff it works on i686.  Last time I checked it wasn't
building, or rather the docs weren't.  That's why I can't use it on my
netbook, which needs it the most.

Add earlyoom service to %desktop-services?

[Pkill9]

I think that the earlyoom service is a necessity for a Guix system
desktop.

For those who don't know what it does, EarlyOOM (early out-of-memory)
is a daemon that kills applications when the amount of memory available
falls below a certain percentage of the maximum, by default 10%. There
is already an OOM killer in the kernel, but it's too lax and
applications that consume too much memory can cause the system to
freeze.

I've used this for a while and many times it has kicked in and works
well for my laptop. I think adding it to the default desktop services
will give Guix System on desktop greater stability, which would
encourage adoption of Guix System on the desktop

What do you, reader, think?

Re: bug#58417: Installer script no longer works with `yes` utility

[zimoun]

Hi Maxim,

On dim., 16 oct. 2022 at 21:22, Maxim Cournoyer  
wrote:

> If I understood Tobias, they were not suggesting to make the
> non-interactive installation use case harder/impossible, just to change
> it from 'yes | ./install.sh' to 'yes "" | ./install.sh', which would
> give us the freedom to choose a default value of either yes or no for
> each question.

Thanks for explaining.

IIUC, is the point to have 'default | ./install.sh'?


Cheers,
simon

Creating an Emacs Home Configuration Service

[Zain Jabbar]

Aloha Guix Development Team,

Running =guix home search emacs= returns nothing. I also could not find an
email using =C-u M-x debbugs-gnu= about an Emacs configuration service.

This is my first email to this mailing address. Please give me pointers on
formatting and further improvements.

I have attempted to make an =emacs-home-service-type= so that it is
possible to configure Emacs using Guix home. This code is extremely
preliminary hence I don't even think it is worth sending as a patch. Also I
have never worked on a multi person Git project before and do not know how
to solve the keyring error I get when using guix pull. I will outline what
my code does and what features I would like to add.

#+BEGIN_SRC scheme
(define* (emacs-configuration-service name #:key (init '()) (early-init
'()) (emacs-packages '()))
  (service-type (name (symbol-append 'emacs- name '-configuration))
(extensions
(list (service-extension
home-profile-service-type
(lambda (config) emacs-packages))
  (service-extension
home-files-service-type
(lambda (config)
 (list
  `(,(string-append
  ".config/emacs/services/" (symbol->string name) ".el")
,(scheme-file (string-append (symbol->string name) ".el")
  init #:splice? #t))
  `(,(string-append
  ".config/emacs/early-services/" (symbol->string name) ".el")
,(scheme-file (string-append "early-" (symbol->string name) ".el")
  early-init #:splice? #t)))
(default-value #f)
(description "Configures Emacs init.el")))


(define-public emacs-init-service-type
  (service-type (name 'home-emacs)
(extensions
(list (service-extension
home-profile-service-type
(lambda (config) (list emacs-next)))
  (service-extension
home-files-service-type
(lambda (config)
 (list
  `(".config/emacs/early-init.el"
,(scheme-file
  "early-init.el"
  '((mapc
 'load (file-expand-wildcards
"~/.config/emacs/early-services/*.el")))
  #:splice? #t))
  `(".config/emacs/init.el"
,(scheme-file
  "init.el"
  '((mapc
 'load (file-expand-wildcards
"~/.config/emacs/services/*.el")))
  #:splice? #t)))
(default-value #f)
(description "Configures Emacs init.el")))
#+END_SRC

I define a general configuration service generator which takes in four
things:
1. The =name= of the service
2. The configuration to be ran in =init.el=
3. The configuration to be ran in =early-init.el=
4. The packages in Guix to be added to the =home-profile=.

After giving the =name=, =packages=, and =config.el= files we get a new
service type that we can add to our home declaration. This service will
then add a file in
=~/.config/emacs/services/emacs-{NAME}-configuration.el=. I then have
another service that places an =init.el= which loads everything in the
service directory.

If we want to install and configure =evil-mode= using this =home-service=
we may define the following somewhere.

#+BEGIN_SRC scheme
(define-public emacs-evil-service-type
  (emacs-configuration-service
   'evil #:emacs-packages (list emacs-evil)
   #:init '((evil-mode 1
#+END_SRC

Within our =home-environment= we may add the service using:

#+BEGIN_SRC scheme
(home-environment
 ;; ...Things in the home-environment...
 (services
  (list
   ;; ...Other Services...
   (service emacs-evil-service-type
#+END_SRC

There are some missing features I want to add.

1. Have the =home-emacs-*-service-type= service-types add to the =init.el=
directly rather than within a folder to be loaded. I couldn't add two files
with the same name to the store. So I have emacs-evil.el in the store to be
placed separately later rather than appending to the existing init.el file.

2. Have Emacs update whenever the =home-environment= is updated. Meaning,
if I did not add =(service emacs-evil-service-type)= in my
=home-environment= then obviously =M-x evil-mode= should not work. But
after adding the service then I want =M-x evil-mode= to work without having
to restart Emacs. I do not understand the Emacs loading system on Guix well
enough to know why it does not work. Skipping all of the =home-service=
stuff, running =guix install emacs-evil-mode= then
=(guix-emacs-autoload-packages)= does not let emacs know that =evil-mode=
is installed. I would need to close Emacs and start Emacs again for Emacs
to know about =evil-mode= being installed.

3. Use configurations somehow. I have completely neglected this feature in
my system. I do not know what would be useful there.

-- 
Thank you,
Zain Jabbar