Re: EXWM
calcium writes: > I was totally at lost when I started my emacs/exwm session and tried to > `find-file' only to be redirected to an 'ido-find-file` with whom I don't > know how to navigate. > > In the moment, it felt very intrusive for me and I was very afraid to be > unable to control my emacs because I have set all my emacs's keybindings to > non-standard keys ((in a modal way (à la vim) but using my own custom modals) > and without honoring the `C-c' convetion.) and I don't know how to navigate > emacs using the default key bindings. > > Luckly, this time (because packages can evolve to add more default key > bindings), it was just the annoyance of ido that affected me. > > > I was thankfully able to understand what was going on by finding the > Guix-devel archive discussing this issue. > > I think that if we choose to keep things as they are, a simple fix that would > help next users know what is going on without having to find an archived > mailing list : > > a ) being more explicit in messages in both cases like : > (message "no \"~/.exwm\" elisp configuration found to setup exwm. " > "Falling back to executing the default config using > `(exwm-config-default)'") > (message "executing the elisp found at \"~/.exwm\"") > b ) while still keeping the explicit messages, creating the ~/.exwm file when > it doesn't exist populated with guix's choice of default settings (so that > the user can read and tweak his config) > > Because the message thrown by the snippet bellow is not enough at all. > > > (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) > ((not (featurep (quote exwm))) > (require (quote exwm)) > (require (quote exwm-config)) > (exwm-config-default) > (message (concat "exwm configuration not found. " > "Falling back to default configuration..." > I feel you (been there, felt that). I tried, without success, to raise awareness about the issue (perhaps in the archived thread you mention). Sadly, no one agreed or tried to prove me wrong. I wrote a very simple and sane EXWM package definition, and you can find it here: https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs-xyz.scm#L147 I could send it as a patch, but without interest from the developers/maintainers it makes little sense. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
I was totally at lost when I started my emacs/exwm session and tried to `find-file' only to be redirected to an 'ido-find-file` with whom I don't know how to navigate. In the moment, it felt very intrusive for me and I was very afraid to be unable to control my emacs because I have set all my emacs's keybindings to non-standard keys ((in a modal way (à la vim) but using my own custom modals) and without honoring the `C-c' convetion.) and I don't know how to navigate emacs using the default key bindings. Luckly, this time (because packages can evolve to add more default key bindings), it was just the annoyance of ido that affected me. I was thankfully able to understand what was going on by finding the Guix-devel archive discussing this issue. I think that if we choose to keep things as they are, a simple fix that would help next users know what is going on without having to find an archived mailing list : a ) being more explicit in messages in both cases like : (message "no \"~/.exwm\" elisp configuration found to setup exwm. " "Falling back to executing the default config using `(exwm-config-default)'") (message "executing the elisp found at \"~/.exwm\"") b ) while still keeping the explicit messages, creating the ~/.exwm file when it doesn't exist populated with guix's choice of default settings (so that the user can read and tweak his config) Because the message thrown by the snippet bellow is not enough at all. --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) ((not (featurep (quote exwm))) (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8---
Re: EXWM
André A. Gomes writes: > Therefore the claim that Guix forces a default EXWM config on the users > isn't entirely true. Actually, I made a mistake again. Guix seems to force a default EXWM config. Find a proof below. Emacs, as of today, is started by evaluating the following sexp: --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) ((not (featurep (quote exwm))) (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8--- This sexp is the first thing evaluated, taking precedence over the the user's init file. As a result, (not (featurep (quote exwm))) always returns t. Therefore, Guix forces the default EXWM config. In other words, the above sexp is equivalent to: --8<---cut here---start----->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) (t (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8--- As I've been advocating, this seems to qualify as Guix not honouring the user's Emacs init file. I'm surprised no one noticed it before. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
André A. Gomes writes: > Guix forces the execution of (exwm-config-default), unless the user has > a .exwm file. That forces a default config on EXWM users, which is > unpleasant for those (like me) that have been using it for a long time. > Notice that those users have their EXWM configuration where it belongs, > i.e. in their Emacs' init file. There's a subtle and important detail I missed, and I've only noticed it now. This returns --8<---cut here---start->8--- emacs -q --batch --eval '(progn (require (quote exwm)) (print (featurep (quote exwm' --8<---cut here---end--->8--- true, whereas --8<---cut here---start->8--- emacs -q --batch --eval '(print (featurep (quote exwm)))' --8<---cut here---end--->8--- returns nil. But --8<---cut here---start->8--- emacs -q --batch --eval '(print (fboundp (quote exwm-enable)))' --8<---cut here---end--->8--- returns t (as long as emacs-exwm is installed)! Therefore the claim that Guix forces a default EXWM config on the users isn't entirely true. I was led to think that way since, most likely, I didn't add (require 'exwm) in my Emacs init file. In result, EXWM's symbols were actually bound, but, due to the lack of the require statement, it was running with the non-desired default config. I apologise for my lack of attention. I'd say that this also qualifies as evidence that the present "magic" is a double-edge sword. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Ricardo Wurmus writes: > Hi André, > >> I packaged EXWM (the right way) for myself a long time ago. If I'm >> putting effort into this, it's because I think the community is >> missing >> an opportunity to improve. I won't get anything from any of this. >> You, >> on the other hand, seem to be interested in your selfish agenda. > > it’s frustrating to get the feeling to be misunderstood. But please > take a step back before judging others. “selfish agenda” sounds a lot > harsher than is warranted in this context. I apologise for the choice of words. > Some background: Guix implements a philosophy that could be described > as “magic with escape hatches”. We usually offer neat features and > automation by *default*, but we also provide escape hatches for those > who don’t want the magic or have different requirements. I do understand that, and that's why I like Guix. I started a thread before sending a patch, since I antecipated that it would be a sensitive topic. On top of that, I was concerned about backwards compatibility since, at this point, lots of users are perhaps used to the .exwm file. > The expectation to have EXWM start right up after selecting it as a >window manager is justified, in my opinion. Do we offer a sufficient >escape hatch here? No. My point is that the "magic" that Guix provides in this case is a double-edged sword. Guix forces the execution of (exwm-config-default), unless the user has a .exwm file. That forces a default config on EXWM users, which is unpleasant for those (like me) that have been using it for a long time. Notice that those users have their EXWM configuration where it belongs, i.e. in their Emacs' init file. The .exwm file is non-standard, and it's not documented in any EXWM project resource. This would be somehow alleviated if (exwm-enable) would run, instead of (exwm-config-default). But we can do better. I've advocated to the fact that "choosing EXWM as a window manager" is a meaningless statement. The meaningful statement is "choosing Emacs as the window manager". The user's Emacs init file dictates how EXWM is to be initiated and operated. In short, the EXWM bin wrapper should simply start Emacs. The approach I describe is the "standard" and documented way of using and "starting EXWM". See C-h P exwm RET for more info. Thank you. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Hi André, I packaged EXWM (the right way) for myself a long time ago. If I'm putting effort into this, it's because I think the community is missing an opportunity to improve. I won't get anything from any of this. You, on the other hand, seem to be interested in your selfish agenda. it’s frustrating to get the feeling to be misunderstood. But please take a step back before judging others. “selfish agenda” sounds a lot harsher than is warranted in this context. Some background: Guix implements a philosophy that could be described as “magic with escape hatches”. We usually offer neat features and automation by *default*, but we also provide escape hatches for those who don’t want the magic or have different requirements. The expectation to have EXWM start right up after selecting it as a window manager is justified, in my opinion. Do we offer a sufficient escape hatch here? -- Ricardo
Re: EXWM
Arun Isaac writes: > Hi André, > >> Your reply indicates that little or no effort was put into understanding >> my points. And no effort was put to indicate where did my reasoning go >> wrong. > > I, for one, did not understand how your workflow is affected by the way > EXWM is currently packaged in Guix. As far as I understand, Guix's > ~/.exwm separation is optional and you are not forced to create it. I > don't have an ~/.exwm, for example. It's frustrating to keep repeating myself at this point, but let's do it. It is optional, indeed. Now assume that you don't have a .exwm file. Then (exwm-config-default) runs. But that's backwards, since the user might not want that piece of code to run. I have explained this from several points of view, several times. For instance, in one of the replies to Ludovic. > But, it is possible that I may have misunderstood something you > said. Perhaps, making your point more precise by providing a patch or > just a code snippet showing your modified exwm package would help. I did all of that. I sent a link with my own EXWM package definition. And I've illustrated my points with code snippets. https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs-xyz.scm#L150 -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Hi André, > Your reply indicates that little or no effort was put into understanding > my points. And no effort was put to indicate where did my reasoning go > wrong. I, for one, did not understand how your workflow is affected by the way EXWM is currently packaged in Guix. As far as I understand, Guix's ~/.exwm separation is optional and you are not forced to create it. I don't have an ~/.exwm, for example. But, it is possible that I may have misunderstood something you said. Perhaps, making your point more precise by providing a patch or just a code snippet showing your modified exwm package would help. Thanks, Arun signature.asc Description: PGP signature
Re: EXWM
Jan Nieuwenhuizen writes: > André A. Gomes writes: > >> Jan Nieuwenhuizen writes: >> >>> I just tried adding my ~/.exwm into my init.el and running a nested >>> emacs and now I get a GUI dialog: >>> >>> Replace existing window manager? Y/N >>> >>> Not great! Not very suprisingly, the extra unnecessary initialization >>> /does/ hurt here. >> >> Isn't exwm doing precisely what it's supposed to do? Isn't it fair that >> the newly spawned (nested) Emacs has the right to take control over the >> "older" Emacs? > > Of course; that's my point exactly! Emacs cannot know, and thus cannot > help but doing the annoying thing: throwing a dialogue. That is what > this code > > (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) > ((not (featurep (quote exwm))) >(require (quote exwm)) >(require (quote exwm-config)) >(exwm-config-default) >(message (concat "exwm configuration not found. " > "Falling back to default configuration..." > > helps to prevent in a very nice way. Let's please keep it! After all the effort I put into all of my previous messages, it's unfortunate to receive such a reply. I packaged EXWM (the right way) for myself a long time ago. If I'm putting effort into this, it's because I think the community is missing an opportunity to improve. I won't get anything from any of this. You, on the other hand, seem to be interested in your selfish agenda. Your reply indicates that little or no effort was put into understanding my points. And no effort was put to indicate where did my reasoning go wrong. I give up. Let "worse is better" reign. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
André A. Gomes writes: > Jan Nieuwenhuizen writes: > >> I just tried adding my ~/.exwm into my init.el and running a nested >> emacs and now I get a GUI dialog: >> >> Replace existing window manager? Y/N >> >> Not great! Not very suprisingly, the extra unnecessary initialization >> /does/ hurt here. > > Isn't exwm doing precisely what it's supposed to do? Isn't it fair that > the newly spawned (nested) Emacs has the right to take control over the > "older" Emacs? Of course; that's my point exactly! Emacs cannot know, and thus cannot help but doing the annoying thing: throwing a dialogue. That is what this code --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) ((not (featurep (quote exwm))) (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8--- helps to prevent in a very nice way. Let's please keep it! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: EXWM
Jan Nieuwenhuizen writes: > Arun Isaac writes: > > Hello, > >>> My suggestion is simple: remove the added layer of complexity introduced >>> by the .exwm file; don't force a default Exwm config on the user. >> >> I think I agree with you now. I checked, and exwm indeed does not run >> when emacs is opened in the console even though my exwm config is >> defined in my ~/.emacs. > > Interesting. So the extra, unneccesary initialization code does not > hurt there. > > I just tried adding my ~/.exwm into my init.el and running a nested > emacs and now I get a GUI dialog: > > Replace existing window manager? Y/N > > Not great! Not very suprisingly, the extra unnecessary initialization > /does/ hurt here. Isn't exwm doing precisely what it's supposed to do? Isn't it fair that the newly spawned (nested) Emacs has the right to take control over the "older" Emacs? It does so in a very polite way, by asking what should be done. If you disagree with the default behaviour, you can change the value of the variable exwm-replace. >> So, I see no reason to continue having ~/.exwm. If no one else has any >> objections, please do send a patch fixing this. > > I would very much like for this nested emacs issue to be addressed > first. > > I just don't really see the point in mixing two bits of code that are > meant to run in different scenarios, and then disabling one of them. I don't see how it could possibly qualify as an issue, and what those "different scenarios" are. There's one and only one scenario. The user launches emacs. Emacs reads the user's init file, and carries out the instructions. The confusion arises from thinking about Exwm as a "session", with a .desktop file associated with it. But that's a special case of something more general and simple. Exwm is an Emacs extension, requiring a graphical X session. After all, it manages X windows "à la Emacs". If you try to start Exwm from the console, it will handle it. If you start Exwm from DEs or WMs (GNOME, i3, whatever), it will handle it (on Guix, that requires running xhost). Yes, this is a good middle ground for "beginners" that aren't ready to fully convert themselves to the Light. If you start Exwm from Exwm itself, it will handle it as well. The so-called "emacs-exwm" session is nothing but a convenience to handle a common scenario. If Exwm handles X windows, then it makes sense to start a graphical session and IMMEDIATELY start Emacs so that Exwm kicks in. What happens if Exwm doesn't kick in, btw? You get a bunch of X windows floating around, and you won't be able to handle them with ease. Makes sense. What should the "emacs-exwm" session do, then? With some simplifications, nothing but this: --8<---cut here---start->8--- dbus-launch --exit-with-session emacs -mm --debug-init --8<---cut here---end--->8--- Yes, there shouldn't even be any "exwm" logic in it. The user knows better. Let the user's init file be in charge. I did my best to show my point of view, and I won't press on it anymore. The decision is on the community's side. The patch the trivial. Acceptance isn't. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Arun Isaac writes: Hello, >> My suggestion is simple: remove the added layer of complexity introduced >> by the .exwm file; don't force a default Exwm config on the user. > > I think I agree with you now. I checked, and exwm indeed does not run > when emacs is opened in the console even though my exwm config is > defined in my ~/.emacs. Interesting. So the extra, unneccesary initialization code does not hurt there. I just tried adding my ~/.exwm into my init.el and running a nested emacs and now I get a GUI dialog: Replace existing window manager? Y/N Not great! Not very suprisingly, the extra unnecessary initialization /does/ hurt here. > So, I see no reason to continue having ~/.exwm. If no one else has any > objections, please do send a patch fixing this. I would very much like for this nested emacs issue to be addressed first. I just don't really see the point in mixing two bits of code that are meant to run in different scenarios, and then disabling one of them. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: EXWM
Hi André, > My suggestion is simple: remove the added layer of complexity introduced > by the .exwm file; don't force a default Exwm config on the user. I think I agree with you now. I checked, and exwm indeed does not run when emacs is opened in the console even though my exwm config is defined in my ~/.emacs. So, I see no reason to continue having ~/.exwm. If no one else has any objections, please do send a patch fixing this. Regards, Arun signature.asc Description: PGP signature
Re: EXWM
Arun Isaac writes: > Hi André, > >> I remember, back in the day, to what great lengths I went to understand >> what the hell what going on. I had EXWM configured in my Emacs init.el >> file (the sane, standard and documented way of doing it), and I've used >> it before in other distros. > > Just to clarify, I have exwm configured in my ~/.emacs, and it works. I > don't have any ~/.exwm file. The way Guix currently starts exwm does not > require to you have a ~/.exwm. So, Guix does support the standard way of > configuring exwm. Do we agree on this? Absolutely not. Please read my previous message. It seems that what you call "the standard way of configuring Exwm" includes running the default config that Exwm packages, but this should be optional. Please look at C-h P exwm RET. Item number 2 should be handled by the user, but Guix forces it. The only way out of it is to write a .exwm file. But, as I've stated previously, this (besides being a bad idea) is not documented. Users would only find out about it by looking at the package definition, or by looking at how the emacs process was started. Users can use their emacs init files as they wish, but that's a separate issue. My suggestion is simple: remove the added layer of complexity introduced by the .exwm file; don't force a default Exwm config on the user. What do you think? -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Ludovic Courtès writes: > Hello, > > Arun Isaac skribis: > >>>> I was involved in the packaging of exwm when it was first done, and I >>>> hear your frustration. :-) Please do send patches (with me on Cc) >>>> addressing the issue, and we can continue our discussion there. >>> >>> As someone who didn't have a prior EXWM setup in their .emacs, I have >>> been enjoying the separate .exwm config file. >> >> Ah, I see. That may be good reason to not break this separation between >> .emacs and .exwm. > > FWIW, I don’t have .exwm either; instead I have just a few lines of exwm > config straight in ~/.emacs, which shouldn’t prevent it from running in > the console or anything. I'm afraid you're approaching the issue from the wrong angle. Exwm is smart than you think. As of today, there are workarounds (.exwm) that attempt to "solve" non-existent issues. As for the fact the you, Ludovic, don't have a .exwm file and configure Exwm from your emacs init file: are you aware that you're running a default Exwm config? M-x find-library RET exwm-config; and take a look at exwm-config-example. I find this extremely annoying, since it defeats the purpose of having a personal Exwm config. The only way to avoid this is to create an empty .exwm file. Again, sending a patch is trivial (I've been running my own Exwm for a while now), but I need to convince you first :) -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Jan Nieuwenhuizen writes: > I'm wondering, how have you managed to switch off exwm when running a > nested emacs or a console emacs? Exwm handles that by itself. In a console, since it's a non-graphical session, Exwm won't even try to do anything. As for nested emacs, there's a variable called exwm-replace which by default is set to 'ask---meaning that Exwm will ask if it should replace the current window manager. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Hello, Arun Isaac skribis: >>> I was involved in the packaging of exwm when it was first done, and I >>> hear your frustration. :-) Please do send patches (with me on Cc) >>> addressing the issue, and we can continue our discussion there. >> >> As someone who didn't have a prior EXWM setup in their .emacs, I have >> been enjoying the separate .exwm config file. > > Ah, I see. That may be good reason to not break this separation between > .emacs and .exwm. FWIW, I don’t have .exwm either; instead I have just a few lines of exwm config straight in ~/.emacs, which shouldn’t prevent it from running in the console or anything. Ludo’.
Re: EXWM
Hi André, > I remember, back in the day, to what great lengths I went to understand > what the hell what going on. I had EXWM configured in my Emacs init.el > file (the sane, standard and documented way of doing it), and I've used > it before in other distros. Just to clarify, I have exwm configured in my ~/.emacs, and it works. I don't have any ~/.exwm file. The way Guix currently starts exwm does not require to you have a ~/.exwm. So, Guix does support the standard way of configuring exwm. Do we agree on this? Regards, Arun signature.asc Description: PGP signature
Re: EXWM
Hi Janneke, >> I was involved in the packaging of exwm when it was first done, and I >> hear your frustration. :-) Please do send patches (with me on Cc) >> addressing the issue, and we can continue our discussion there. > > As someone who didn't have a prior EXWM setup in their .emacs, I have > been enjoying the separate .exwm config file. Ah, I see. That may be good reason to not break this separation between .emacs and .exwm. > I'm wondering, how have you managed to switch off exwm when running a > nested emacs or a console emacs? I myself have never run a nested emacs or a console emacs session. So, I have never encountered this problem. Cheers! Arun signature.asc Description: PGP signature
Re: EXWM
Arun Isaac writes: Hello, > I was involved in the packaging of exwm when it was first done, and I > hear your frustration. :-) Please do send patches (with me on Cc) > addressing the issue, and we can continue our discussion there. As someone who didn't have a prior EXWM setup in their .emacs, I have been enjoying the separate .exwm config file. I'm wondering, how have you managed to switch off exwm when running a nested emacs or a console emacs? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: EXWM
Hi André, I was involved in the packaging of exwm when it was first done, and I hear your frustration. :-) Please do send patches (with me on Cc) addressing the issue, and we can continue our discussion there. Thank you, Arun signature.asc Description: PGP signature
EXWM
Hi Guix,
I'd like to addres the way EXWM is packged in Guix.
EXWM starts (from the login manager, i.e. after X is running) by means
of a script that starts emacs by evaluating the following s-exp:
--8<---cut here---start->8---
(cond ((file-exists-p "~/.exwm") (load-file "~/.exwm"))
((not (featurep (quote exwm)))
(require (quote exwm))
(require (quote exwm-config))
(exwm-config-default)
(message (concat "exwm configuration not found. "
"Falling back to default configuration..."
--8<---cut here---end--->8---
I can't think of any good reason to doing this, but I can think of many
against. I'll elaborate.
I remember, back in the day, to what great lengths I went to understand
what the hell what going on. I had EXWM configured in my Emacs init.el
file (the sane, standard and documented way of doing it), and I've used
it before in other distros.
I wondered: why isn't it being honored? And why the hell is ido-mode
on, if I did it enabled it? Let's check the EXWM wiki and
documentation. Nothing. Ok, maybe I should check how EXWM is packaged
in Guix. Let's be honest, the "lay user" will never do this.
The present approach assumes that one of the following holds. Either
the user is stupid and he expects some standard EXWM config to "just
work", or he miracously knows he needs to write an extra .exwm file to
serve such a specfic purpose. This doesn't configure EXWM in the most
general case (more on that below), and it's bonkers.
EXWM was thought to be started and used in many scenarios. The most
common one, indeed, is to start it when no other window manager has been
started. But users can also login into a full-blown DE (GNOME, Xfce,
etc) and active EXWM when they wish! In this case, EXWM is able to take
control of things (i.e. replace the running window manager). See how
the .exwm file is short-sighted? This is a non-standard approach, and a
source of duplication and confusion.
Now, there's another problem. One simply doesn't start EXWM from
another DE in Guix! It always fails. Why? Because the user needs to
run the following beforehand (yes, the same bit that also appears in the
exwm binary wrapper):
--8<---cut here---start->8---
/gnu/store/HASH-xhost-1.0.8/bin/xhost +SI:localuser:$USER
--8<---cut here---end--->8---
I'm not sure how to handle this issue. Most users would expect things
to just work. There are lots of issues on github from Guix users
clueless about this. Yes, I can mention this in the EXWM wiki, but
perhaps deeper measures should be taken.
It's trivial to fix part of the problem, and I have packaged EXWM
myself. See the link below.
https://git.sr.ht/~aadcg/aadcg-guix-channel/commit/4a27f9991b0b692694f954cb595a9748a0146d36.
It seemed pointless to send a trivial patch without any further
explation, so feel free to discuss the topic.
Thank you.
--
André A. Gomes
"Free Thought, Free World"
Re: [PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]
Mathieu Othacehe writes: Hi Mathieu, >> It works for me; I found Emacs EXWM missing however. After zenny also >> asked about that this morning, I decided to create a patch. > > Thanks for testing Using it is real easy, pleasant, and fast. One thing that I got wrong a couple of times is to actually select a suggested option while partitioning, I pressed TAB and RET (like in previous screens), then selecting the button that is clearly marked EXIT. Then it tries to continue with a non-partitioned or badly partitioned drive, which then may give an unexpected error. Clearly a user error, not a problem and I also do not have a better suggestion. Also, my mistake was very obvious to me later. > and for the patch! I think it might be necessary to > add "emacs-exwm" to "installation-target-os-for-gui-tests" in (gnu tests > install) module. Good call. I verified that the test fails without it.. > To make sure that it's working fine you can run: > > make check-system TESTS="gui-installed-os gui-installed-os-encrypted > gui-installed-desktop-os-encrypted" --8<---cut here---start->8--- cannot build derivation `/gnu/store/7xnhrap7xsv2x717yn9wrgisxpppxrmy-emacs-27.1.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/kkfdhpc81h0f0sz0mj1ayin0sxy7vkmq-emacs-desktop-environment-0.3.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/3amvkhwa4jv8fghljgkcvlkpg4mpwc8v-emacs-exwm-0.24.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/q4pxd90hb9mah7cs9r1cjyb2pif1ixmz-emacs-xelb-0.18.drv': 1 dependencies couldn't be built --8<---cut here---end--->8--- and veried that it passes when I adding them. > Otherwise, it looks fine. Thanks, pushed to master as 1197b8b20f4fca4ce03bbc5fa75e18d54e3717c0. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]
Hey janneke, > It works for me; I found Emacs EXWM missing however. After zenny also > asked about that this morning, I decided to create a patch. Thanks for testing and for the patch! I think it might be necessary to add "emacs-exwm" to "installation-target-os-for-gui-tests" in (gnu tests install) module. To make sure that it's working fine you can run: --8<---cut here---start->8--- make check-system TESTS="gui-installed-os gui-installed-os-encrypted gui-installed-desktop-os-encrypted" --8<---cut here---end--->8--- Otherwise, it looks fine. Thanks, Mathieu
[PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]
Mathieu Othacehe writes:
Hi,
> The 1.2 release is on its way. So here's the traditional call for
> installer testing. This time, the CI is building latest installer
> images, which should ease testing.
It works for me; I found Emacs EXWM missing however. After zenny also
asked about that this morning, I decided to create a patch.
Greetings,
Janneke
>From 130480c4e76d7133f32a83cb1fa30aa171944383 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sun, 11 Oct 2020 12:45:00 +0200
Subject: [PATCH] installer: Add Emacs EXWM desktop environment.
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Suggested by zenny via IRC.
* gnu/installer/services.scm (%system-services): Add emacs, emacs-exwm,
emacs-desktop-environment.
* etc/release-manifest.scm (%system-packages): Likewise.
* gnu/system/examples/lightweight-desktop.tmpl: Likewise.
* gnu/installer/newt/services.scm (run-desktop-environments-cbt-page): Make
one entry taller.
---
etc/release-manifest.scm | 2 ++
gnu/installer/newt/services.scm | 3 ++-
gnu/installer/services.scm | 6 ++
gnu/system/examples/lightweight-desktop.tmpl | 3 ++-
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/etc/release-manifest.scm b/etc/release-manifest.scm
index caa200c673..7f54fe8768 100644
--- a/etc/release-manifest.scm
+++ b/etc/release-manifest.scm
@@ -1,5 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2020 Ludovic Courtès
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -53,6 +54,7 @@ TARGET."
(append (map specification->package
'("xorg-server" "xfce" "gnome" "mate" "enlightenment"
"openbox" "awesome" "i3-wm" "ratpoison"
+ "emacs" "emacs-exwm" "emacs-desktop-environment"
"xlockmore" "slock" "libreoffice"
"connman" "network-manager" "network-manager-applet"
"openssh" "ntp" "tor"
diff --git a/gnu/installer/newt/services.scm b/gnu/installer/newt/services.scm
index 4f32d9077b..6d431cb4bb 100644
--- a/gnu/installer/newt/services.scm
+++ b/gnu/installer/newt/services.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Mathieu Othacehe
;;; Copyright © 2019 Ludovic Courtès
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -40,7 +41,7 @@ choose the one to use on the log-in screen.")
#:items items
#:selection (map system-service-recommended? items)
#:item->text system-service-name ;no i18n for DE names
- #:checkbox-tree-height 8
+ #:checkbox-tree-height 9
#:exit-button-callback-procedure
(lambda ()
(raise
diff --git a/gnu/installer/services.scm b/gnu/installer/services.scm
index dbac79196d..ec5ea30594 100644
--- a/gnu/installer/services.scm
+++ b/gnu/installer/services.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Mathieu Othacehe
;;; Copyright © 2019 Ludovic Courtès
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -82,6 +83,11 @@
(name "ratpoison")
(packages '((specification->package "ratpoison")
(specification->package "xterm"
+ (desktop-environment
+ (name "Emacs EXWM")
+ (packages '((specification->package "emacs")
+ (specification->package "emacs-exwm")
+ (specification->package "emacs-desktop-environment"
;; Networking.
(system-service
diff --git a/gnu/system/examples/lightweight-desktop.tmpl b/gnu/system/examples/lightweight-desktop.tmpl
index b4037d4f79..8e38095a03 100644
--- a/gnu/system/examples/lightweight-desktop.tmpl
+++ b/gnu/system/examples/lightweight-desktop.tmpl
@@ -4,7 +4,7 @@
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
-(use-package-modules bootloaders certs ratpoison suckless wm xorg)
+(use-package-modules bootloaders certs emacs-xyz ratpoison suckless wm xorg)
(operating-system
(host-name "antelope")
@@ -43,6 +43,7 @@
(packages (append (list
;; window managers
ratpoison i3-wm i3status dmenu
+ emacs-exwm emacs-desktop-environment
;; terminal emulator
xterm
;; for HTTPS access
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re:Re: emacs-exwm-x update error
may be we should show a tip also: suggest do XXX :-) At 2017-07-02 00:10:55, "l...@gnu.org (Ludovic" <=?utf-8?Q?Court=C3=A8s?=)> wrote: >Hello, > >"Feng Shu" <tuma...@163.com> skribis: > >> feng@tumashu:~/project/guix $ ./pre-inst-env guix package -u emacs-exwm-x > >[...] > >> The following package will be upgraded: >>emacs-exwm-x 1.0-2.2099138 → 1.6 >> /gnu/store/b05317amv8xp7kg297rjfqma8f9pp91d-emacs-exwm-x-1.6 >> >> guix package: error: profile contains conflicting entries for emacs-exwm:out >> guix package: error: first entry: emacs-exwm@0.14:out >> /gnu/store/6v3xzl7xpbgkg9fy6rhfbbizps61yysd-emacs-exwm-0.14 >> guix package: error:... propagated from emacs-exwm-x@1.6 >> guix package: error: second entry: emacs-exwm@0.13:out >> /gnu/store/j39k3hiyxskr78k2pbybvgq1nwczdgvq-emacs-exwm-0.13 > >I find the message pretty explicit :-), but I’m happy to improve it if >you have ideas. > >What this means is that the new profile would end up with two different >emacs-exwm, and so it just errors out. > >One solution is to upgrade all things exwm at once: > > guix package -u exwm > >That way, emacs-exwm-x and emacs-exwm will be in sync. > >HTH! > >Ludo’.
Re: emacs-exwm-x update error
Hello, "Feng Shu" <tuma...@163.com> skribis: > feng@tumashu:~/project/guix $ ./pre-inst-env guix package -u emacs-exwm-x [...] > The following package will be upgraded: >emacs-exwm-x 1.0-2.2099138 → 1.6 > /gnu/store/b05317amv8xp7kg297rjfqma8f9pp91d-emacs-exwm-x-1.6 > > guix package: error: profile contains conflicting entries for emacs-exwm:out > guix package: error: first entry: emacs-exwm@0.14:out > /gnu/store/6v3xzl7xpbgkg9fy6rhfbbizps61yysd-emacs-exwm-0.14 > guix package: error:... propagated from emacs-exwm-x@1.6 > guix package: error: second entry: emacs-exwm@0.13:out > /gnu/store/j39k3hiyxskr78k2pbybvgq1nwczdgvq-emacs-exwm-0.13 I find the message pretty explicit :-), but I’m happy to improve it if you have ideas. What this means is that the new profile would end up with two different emacs-exwm, and so it just errors out. One solution is to upgrade all things exwm at once: guix package -u exwm That way, emacs-exwm-x and emacs-exwm will be in sync. HTH! Ludo’.
Re: emacs-exwm-x update error
"Feng Shu" <tuma...@163.com> writes: > feng@tumashu:~/project/guix $ ./pre-inst-env guix package -u emacs-exwm-x > ;;; note: source file /home/feng/project/guix/gnu/packages/emacs.scm > ;;; newer than compiled /home/feng/project/guix/gnu/packages/emacs.go > ;;; note: source file /home/feng/project/guix/gnu/packages/emacs.scm > ;;; newer than compiled > /run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/emacs.go > guix package: warning: Consider running 'guix pull' followed by > 'guix package -u' to get up-to-date packages and security updates. > Did you run make after running git pull? > substitute: updating list of substitutes from > 'https://mirror.hydra.gnu.org'... 100.0% > substitute: updating list of substitutes from > 'https://mirror.hydra.gnu.org'... 100.0% > substitute: updating list of substitutes from > 'https://mirror.hydra.gnu.org'... 100.0% > The following package will be upgraded: >emacs-exwm-x 1.0-2.2099138 → 1.6 > /gnu/store/b05317amv8xp7kg297rjfqma8f9pp91d-emacs-exwm-x-1.6 > > guix package: error: profile contains conflicting entries for emacs-exwm:out > guix package: error: first entry: emacs-exwm@0.14:out > /gnu/store/6v3xzl7xpbgkg9fy6rhfbbizps61yysd-emacs-exwm-0.14 > guix package: error: ... propagated from emacs-exwm-x@1.6 > guix package: error: second entry: emacs-exwm@0.13:out > /gnu/store/j39k3hiyxskr78k2pbybvgq1nwczdgvq-emacs-exwm-0.13 signature.asc Description: PGP signature
emacs-exwm-x update error
feng@tumashu:~/project/guix $ ./pre-inst-env guix package -u emacs-exwm-x ;;; note: source file /home/feng/project/guix/gnu/packages/emacs.scm ;;; newer than compiled /home/feng/project/guix/gnu/packages/emacs.go ;;; note: source file /home/feng/project/guix/gnu/packages/emacs.scm ;;; newer than compiled /run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/emacs.go guix package: warning: Consider running 'guix pull' followed by 'guix package -u' to get up-to-date packages and security updates. substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% The following package will be upgraded: emacs-exwm-x 1.0-2.2099138 → 1.6 /gnu/store/b05317amv8xp7kg297rjfqma8f9pp91d-emacs-exwm-x-1.6 guix package: error: profile contains conflicting entries for emacs-exwm:out guix package: error: first entry: emacs-exwm@0.14:out /gnu/store/6v3xzl7xpbgkg9fy6rhfbbizps61yysd-emacs-exwm-0.14 guix package: error:... propagated from emacs-exwm-x@1.6 guix package: error: second entry: emacs-exwm@0.13:out /gnu/store/j39k3hiyxskr78k2pbybvgq1nwczdgvq-emacs-exwm-0.13 --
