Re: Questions about guix handling emacs packages
Hi Alexey, Alexey Abramov writes: > AFAIK emacs-ts is failing on check. There are couple of PRs in the upstream: > > https://github.com/alphapapa/ts.el/pull/9 > https://github.com/alphapapa/ts.el/pull/8 Strange, it built fine for me with guix commit: ba6d3612550f5d978c4b5b1df122444f8fb29377. Maybe those checks aren't fatal? > Regarding the magit highlighting, emacs 27 has a new face attribute > :extend. You can read about the issue here > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774 > > ,[ C-h i d m emacs s :extend ] > |This is one of the few faces that has the ‘:extend t’ attribute by > | default, which implies that the same face is used to highlight the text > | and space between end of line and the window border. To highlight only > | the text you could set this attribute to ‘nil’. > ` Nice, did not know about the :extend attribute. > Magit fix is on the master already > https://github.com/magit/magit/commit/891ebdca58ef498ff3b94c8ac2921cc6b72c3d25 > > In the meantime you can do something like this: > > --8<---cut here---start->8--- > (dolist (face '(magit-diff-hunk-heading > magit-diff-hunk-heading-highlight > magit-diff-hunk-heading-selection > magit-diff-hunk-region > magit-diff-lines-heading > magit-diff-lines-boundary > magit-diff-conflict-heading > magit-diff-added > magit-diff-removed > magit-diff-our > magit-diff-base > magit-diff-their > magit-diff-context > magit-diff-added-highlight > magit-diff-removed-highlight > magit-diff-our-highlight > magit-diff-base-highlight > magit-diff-their-highlight > magit-diff-context-highlight > magit-diff-whitespace-warning > magit-diffstat-added > magit-diffstat-removed > magit-section-heading > magit-section-heading-selection > magit-section-highlight > magit-section-secondary-heading > magit-diff-file-heading > magit-diff-file-heading-highlight > magit-diff-file-heading-selection)) > (set-face-attribute face nil :extend t)) > --8<---cut here---end--->8--- This seems to be fixed in the version of guix I'm using. I don't have that issue anymore and I'm using emacs 27 and magit from guix. -- s/Fred[re]+i[ck]+/Fredrik/g
Re: Questions about guix handling emacs packages
Hi, Fredrik Salomonsson writes: > Hi Zimoun, > > zimoun writes: > >> Yes and no. :-) >> You can see for example this blog entry [1]. >> >> [1] https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/ > > Thanks for the link. Will give guix pack a try when I'm back at my > machine at work. Right now I'm working from home so I don't need to have > emacs on my work machine. Tramp covers that bit for me. > >>> > Is it fixed now for you? >>> >>> emacs-magit - yes. emacs-ts is still failing. >> >> Could you open a bug report for this? > > I was too slow :). Did a `guix pull` and updated to > 86a03090afa711dfa2f141caee820b66d7942bc3 and it is now fixed. Will > create a bug report for emacs-lua-mode and emacs-ledger-mode as those > two are still broken for me. > > Thanks again for all your help. AFAIK emacs-ts is failing on check. There are couple of PRs in the upstream: https://github.com/alphapapa/ts.el/pull/9 https://github.com/alphapapa/ts.el/pull/8 Regarding the magit highlighting, emacs 27 has a new face attribute :extend. You can read about the issue here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774 ,[ C-h i d m emacs s :extend ] |This is one of the few faces that has the ‘:extend t’ attribute by | default, which implies that the same face is used to highlight the text | and space between end of line and the window border. To highlight only | the text you could set this attribute to ‘nil’. ` Magit fix is on the master already https://github.com/magit/magit/commit/891ebdca58ef498ff3b94c8ac2921cc6b72c3d25 In the meantime you can do something like this: --8<---cut here---start->8--- (dolist (face '(magit-diff-hunk-heading magit-diff-hunk-heading-highlight magit-diff-hunk-heading-selection magit-diff-hunk-region magit-diff-lines-heading magit-diff-lines-boundary magit-diff-conflict-heading magit-diff-added magit-diff-removed magit-diff-our magit-diff-base magit-diff-their magit-diff-context magit-diff-added-highlight magit-diff-removed-highlight magit-diff-our-highlight magit-diff-base-highlight magit-diff-their-highlight magit-diff-context-highlight magit-diff-whitespace-warning magit-diffstat-added magit-diffstat-removed magit-section-heading magit-section-heading-selection magit-section-highlight magit-section-secondary-heading magit-diff-file-heading magit-diff-file-heading-highlight magit-diff-file-heading-selection)) (set-face-attribute face nil :extend t)) --8<---cut here---end--->8--- -- Alexey
Re: Questions about guix handling emacs packages
Hi Maxim, Maxim Cournoyer writes: >> Question regarding the emacs-xyz.scm. I see it is divided into four >> different categories; Emacs hacking, Web browsing, Multimedia and >> Miscellaneous. But what is the order for the package definitions in >> those categories? > > Ha, I had forgotten myself that the emacs-xyz module was organized in > such sections (shame!). In any way, I don't think the order of the > package definitions matter much. I usually use whatever is most logical > (group tightly related packages), otherwise alphabetically. Ok, thanks. Then I'll try and place them where I think they'll fit. Worst case someone will just move them to a better place.
Re: Questions about guix handling emacs packages
Hi Zimoun, zimoun writes: > Yes and no. :-) > You can see for example this blog entry [1]. > > [1] https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/ Thanks for the link. Will give guix pack a try when I'm back at my machine at work. Right now I'm working from home so I don't need to have emacs on my work machine. Tramp covers that bit for me. >> > Is it fixed now for you? >> >> emacs-magit - yes. emacs-ts is still failing. > > Could you open a bug report for this? I was too slow :). Did a `guix pull` and updated to 86a03090afa711dfa2f141caee820b66d7942bc3 and it is now fixed. Will create a bug report for emacs-lua-mode and emacs-ledger-mode as those two are still broken for me. Thanks again for all your help.
Re: Questions about guix handling emacs packages
Dear Fredrik On Mon, 1 Jun 2020 at 19:12, Fredrik Salomonsson wrote: > I'm quite lucky that my work machine is also running the linux kernel. > Although a quite outdated one, it predates user namespaces support. But > yeah, `guix pack` might be a bit overkill. Yes and no. :-) You can see for example this blog entry [1]. [1] https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/ > > Is it fixed now for you? > > emacs-magit - yes. emacs-ts is still failing. Could you open a bug report for this? All the best, simon
Re: Questions about guix handling emacs packages
Hi Fredrik, Fredrik Salomonsson writes: [...] >> I also can recommend to stick to using just Emacs packages from Guix, >> and contributing the missing ones you encounter (as you found out, it's >> relatively simple, and fun! :-)). This way you are sure to use packages >> that were byte compiled for your Emacs version. > > Yeah, that's the path I'm going to take to avoid future headaches. And I > just got my first contribution merged into guix (yay!). I got some > feedback on what I did wrong. Which I'll try and not to repeat in the > coming package definitions I'm planing to make (cargo (the emacs mode), > flymake-shellcheck, glsl-mode and meson-mode). Great! :-) > Question regarding the emacs-xyz.scm. I see it is divided into four > different categories; Emacs hacking, Web browsing, Multimedia and > Miscellaneous. But what is the order for the package definitions in > those categories? Ha, I had forgotten myself that the emacs-xyz module was organized in such sections (shame!). In any way, I don't think the order of the package definitions matter much. I usually use whatever is most logical (group tightly related packages), otherwise alphabetically. Maxim
Re: Questions about guix handling emacs packages
Hi Zimoun, zimoun writes: > I do not know what rofi is but re-sourcing is faster to check is the > new change works than any other. :-) It is just an application launcher, but yes re-sourcing is a bit faster. :) > Nice! Thank you for your contribution. > As you can seen, add Emacs packages is in general fun and rewarding. :-) > Do not hesitate to report your difficulties on mailing lists help-guix > or guix-devel or IRC #guix. Thank you. Indeed it was. I'm still learning the ropes but got some good feedback from my first contribution. So I'll continue adding the rest of the emacs packages that I'm missing. > Yes, "guix pack" is an an option if your work machine run the Linux > kernel. Otherwise, it should be a bazooka to kill a tiny fly. :-) I'm quite lucky that my work machine is also running the linux kernel. Although a quite outdated one, it predates user namespaces support. But yeah, `guix pack` might be a bit overkill. > However, the main advantage to use for producing your Emacs setup is > that it is harder to break it and when it did, you can (almost) always > roll-back. For example, I track (git) the channel that I used: guix > describe -f channels > foo.scm && git commit -a and I use manifests > files tracked too. Therefore, I can easily use the same setup on > another machine running Guix or restore previous setup without keeping > all the generations in the store. Anyway. :-) Nice, that is a pretty nice way of having it reproducible. Which my setup with use-package is not. It is easy to deploy but not to reproduce it and rolling back is non-existent. So guix ticks all the boxes for me :). > Is it fixed now for you? emacs-magit - yes. emacs-ts is still failing.
Re: Questions about guix handling emacs packages
Hi Fredrik, On Sat, 30 May 2020 at 04:13, Fredrik Salomonsson wrote: > True, although I usually launch my programs from rofi and I haven't > figured out how to re-source the environment for that. I do not know what rofi is but re-sourcing is faster to check is the new change works than any other. :-) > > Feel free to give a try and report on help-guix or guix-devel or #guix > > your progress or you are stuck. > > Thanks, I just sent a patch for adding emacs-buffer-move. Figured I > start with one and see how that goes. Then follow with the rest. > > Really digging the git send-email workflow. Nice! Thank you for your contribution. As you can seen, add Emacs packages is in general fun and rewarding. :-) Do not hesitate to report your difficulties on mailing lists help-guix or guix-devel or IRC #guix. > > I am using emacs-lua-mode@20191204-1.1f596a9 and I do not have such > > issue. But I remember something similar and it was coming from > > init.el file; at the time my Emacs packages was loaded with > > 'use-package' and now they are loaded with 'with-eval-after-load'. > > Well, I do not remember exactly, sorry. > > Yeah, my errors are probably due to I'm using emacs-next (27.0.91) and > `use-package`. And I still need the ability for emacs to download all my > packages as I don't have access to guix on my work machine. Although I'm > toying with the idea of using `guix pack' to deploy emacs on my work > machine. Yes, "guix pack" is an an option if your work machine run the Linux kernel. Otherwise, it should be a bazooka to kill a tiny fly. :-) However, the main advantage to use for producing your Emacs setup is that it is harder to break it and when it did, you can (almost) always roll-back. For example, I track (git) the channel that I used: guix describe -f channels > foo.scm && git commit -a and I use manifests files tracked too. Therefore, I can easily use the same setup on another machine running Guix or restore previous setup without keeping all the generations in the store. Anyway. :-) > > Hum? The regression is probably introduced by commit 4ef89d884. > > Oh, did not know about the data service. Thanks for pointing that out. I > did a `guix import elpa -a melpa-stable -r ts` and that built fine. So > maybe just update emacs-ts from 0.1 to 0.2 will fix the issue. > > >> - emacs-magit: > > I am using it and I not see what you are seeing. But I am not using > > an older Guix than b2d35dd9a. > > Probably an issue that I'm using emacs 27 instead of emacs 26. Is it fixed now for you? All the best, simon
Re: Questions about guix handling emacs packages
Hi, Maxim Cournoyer writes: > I'm not sure why that could be, but I merged a newer version of Magit > recently. If you guix pull now and upgrade your packages, you should > get the new one. Just did a pull, upgrade my packages and now magit works as expected. Thanks! > I also can recommend to stick to using just Emacs packages from Guix, > and contributing the missing ones you encounter (as you found out, it's > relatively simple, and fun! :-)). This way you are sure to use packages > that were byte compiled for your Emacs version. Yeah, that's the path I'm going to take to avoid future headaches. And I just got my first contribution merged into guix (yay!). I got some feedback on what I did wrong. Which I'll try and not to repeat in the coming package definitions I'm planing to make (cargo (the emacs mode), flymake-shellcheck, glsl-mode and meson-mode). Question regarding the emacs-xyz.scm. I see it is divided into four different categories; Emacs hacking, Web browsing, Multimedia and Miscellaneous. But what is the order for the package definitions in those categories? -- s/Fred[re]+i[ck]+/Fredrik/g
Re: Questions about guix handling emacs packages
Hello! Fredrik Salomonsson writes: [...] > - emacs-magit: > > This is just a minor thing. But the highlight/diff in the magit buffer > is more of a tight fit, which looks ugly. Where as if I use magit from > melpa the highlight/diff is a straight block. I've attached a screenshot > on how this looks. Left is emacs-magit, right is melpa magit. I'm not sure why that could be, but I merged a newer version of Magit recently. If you guix pull now and upgrade your packages, you should get the new one. I also can recommend to stick to using just Emacs packages from Guix, and contributing the missing ones you encounter (as you found out, it's relatively simple, and fun! :-)). This way you are sure to use packages that were byte compiled for your Emacs version. Maxim
Re: Questions about guix handling emacs packages
Hi, zimoun writes: > Re-source the profile seems enough. :-) True, although I usually launch my programs from rofi and I haven't figured out how to re-source the environment for that. > Feel free to give a try and report on help-guix or guix-devel or #guix > your progress or you are stuck. Thanks, I just sent a patch for adding emacs-buffer-move. Figured I start with one and see how that goes. Then follow with the rest. Really digging the git send-email workflow. > I am using emacs@26.3, for comparison. > And Guix 2c8305d14 which is one month older. > > I am using emacs-lua-mode@20191204-1.1f596a9 and I do not have such > issue. But I remember something similar and it was coming from > init.el file; at the time my Emacs packages was loaded with > 'use-package' and now they are loaded with 'with-eval-after-load'. > Well, I do not remember exactly, sorry. Yeah, my errors are probably due to I'm using emacs-next (27.0.91) and `use-package`. And I still need the ability for emacs to download all my packages as I don't have access to guix on my work machine. Although I'm toying with the idea of using `guix pack' to deploy emacs on my work machine. >> - emacs-org-super-agenda: > > Thank you for the report. As you can see with the Data Service, it > seems that a regression has been introduced. > > https://data.guix.gnu.org/repository/1/branch/master/package/emacs-ts/output-history > https://data.guix.gnu.org/repository/1/branch/master/package/emacs-ts/derivation-history > > The log corresponding is: > > http://ci.guix.gnu.org/log/k45l3rcrr81qwkh6w9l0b1gsn6xbm2jd-emacs-ts-0.1-2.395649a > > and as you have noticed, the test 'ts-update' fails. > > > Hum? The regression is probably introduced by commit 4ef89d884. Oh, did not know about the data service. Thanks for pointing that out. I did a `guix import elpa -a melpa-stable -r ts` and that built fine. So maybe just update emacs-ts from 0.1 to 0.2 will fix the issue. >> - emacs-magit: > I am using it and I not see what you are seeing. But I am not using > an older Guix than b2d35dd9a. Probably an issue that I'm using emacs 27 instead of emacs 26. >> - emacs-ledger-mode: > > I did not try. No worries. Anyways thanks for all the help! -- s/Fred[re]+i[ck]+/Fredrik/g
Re: Questions about guix handling emacs packages
Dear, On Mon, 25 May 2020 at 22:13, Fredrik Salomonsson wrote: > But this was just me being stupid. It works perfectly, I had just forgot > to reboot/relogin _after_ I installed emacs. Re-source the profile seems enough. :-) > Packages I'm missing are: > flymake-shellcheck > cargo > meson-mode > glsl-mode > buffer-move > > And looks like all of them are trivial to package up using "guix import > elpa". Thanks for pointing that out. I'll give that a shot as it seems > like a good way to go through the process of contributing packages to > guix. Yeah! :-) Feel free to give a try and report on help-guix or guix-devel or #guix your progress or you are stuck. > > Please could you report which packages do not work properly for you? I am using emacs@26.3, for comparison. And Guix 2c8305d14 which is one month older. > - emacs-lua-mode: > > Getting this error: > Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’ I am using emacs-lua-mode@20191204-1.1f596a9 and I do not have such issue. But I remember something similar and it was coming from init.el file; at the time my Emacs packages was loaded with 'use-package' and now they are loaded with 'with-eval-after-load'. Well, I do not remember exactly, sorry. > - emacs-org-super-agenda: > > First I missed this was packaged up in guix. But now when I try and > build it, one of its dependencies `emacs-ts` fails to build. One of the > tests are failing. I've attached the log Thank you for the report. As you can see with the Data Service, it seems that a regression has been introduced. https://data.guix.gnu.org/repository/1/branch/master/package/emacs-ts/output-history https://data.guix.gnu.org/repository/1/branch/master/package/emacs-ts/derivation-history The log corresponding is: http://ci.guix.gnu.org/log/k45l3rcrr81qwkh6w9l0b1gsn6xbm2jd-emacs-ts-0.1-2.395649a and as you have noticed, the test 'ts-update' fails. Hum? The regression is probably introduced by commit 4ef89d884. > - emacs-magit: > > This is just a minor thing. But the highlight/diff in the magit buffer > is more of a tight fit, which looks ugly. Where as if I use magit from > melpa the highlight/diff is a straight block. I've attached a screenshot > on how this looks. Left is emacs-magit, right is melpa magit. I am using it and I not see what you are seeing. But I am not using an older Guix than b2d35dd9a. > - emacs-ledger-mode: > > Does not work with flymake. I did not try. All the best, simon
Re: Questions about guix handling emacs packages
Dear, Thank you for your feedback. On Sat, 23 May 2020 at 08:18, Fredrik Salomonsson wrote: > 1) The manual mention that packages installed via guix will be picked up by > emacs from the EMACSLOADPATH which is set when emacs is installed. That was > not the case for me. I needed to manually set: > > export EMACSLOADPATH=$GUIX_PROFILE/share/emacs/site-lisp:$EMACSLOADPATH > > for it to work. I'm running guix on a foreign distro and I'm using > emacs-next. Is one of those the reason for it? How do you load your profile? "guix package --search-paths" or '. "$GUIX_PROFILE/etc/profile"'? In my ~/.bash_profile, there is '. "$GUIX_PROFILE/etc/profile"' and I do not have any issue on a foreign distro. > 2) Not all packages I use in emacs are packaged up in guix (yet). And some > did not work properly for me. So I still need to rely on emacs to install Please could list which packages do you use which ae not (yet) packaged in Guix? And you could give a try with "guix import elpa -r". It should work with MELPA too. Please could you report which packages do not work properly for you? > some of the packages. The issue is, that it doesn't seem that emacs knows > about the packages installed via guix when it comes to installing packages. > Even though it can load them just fine. My personal experience about mixing Emacs packages from Guix and from package.el is really poor; it always breaks on one way or another. Therefore, I switched to all Emacs packages from Guix. All the best, simon
Questions about guix handling emacs packages
Hi, Thought I should try letting guix handle the emacs packages. And overall it worked out great. But encounter some minor issues along the way, so I thought I should ask. 1) The manual mention that packages installed via guix will be picked up by emacs from the EMACSLOADPATH which is set when emacs is installed. That was not the case for me. I needed to manually set: export EMACSLOADPATH=$GUIX_PROFILE/share/emacs/site-lisp:$EMACSLOADPATH for it to work. I'm running guix on a foreign distro and I'm using emacs-next. Is one of those the reason for it? 2) Not all packages I use in emacs are packaged up in guix (yet). And some did not work properly for me. So I still need to rely on emacs to install some of the packages. The issue is, that it doesn't seem that emacs knows about the packages installed via guix when it comes to installing packages. Even though it can load them just fine. For example emacs-dash which I have installed via my manifest but is also one that gets installed by emacs. If I run emacs -Q and then M-x describe-package dash. It gives me Package dash is dependency. Status: Installed in ‘dash-20200426.2244/’ (unsigned). Version: 20200426.2244 Summary: A modern list library for Emacs Required by: ts-20191010.210, org-super-agenda-20200310.1337, magit-20200522.1028, ht-20200217.2331, git-commit-20200516.2016 Keywords: lists Maintainer: Magnar Sveen Author: Magnar Sveen Other versions: 20200426.2244 (melpa), 2.17.0 (melpa-stable), 2.12.0 (gnu). If I remove my elpa directory in my user-emacs-directory where emacs installs the packages. It wont find dash when I do describe-package. But if I run (require 'dash) it will find and load dash. Unsetting EMACSLOADPATH and it will fail to find dash. Is this the expected behavior? From what I can tell from reading the manual [1], external packages must be listed in `package-directory-list` and have the same layout as the one installed in elpa. Which is not the case when installing via guix, as everything is symlinked to $GUIX_PROFILE/share/emacs/site-lisp. I hope this isn't too much off topic and apologize if any of this has been asked before (I couldn't find the answer when searching the mailing list archive). Thanks 1: https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Files.html#Package-Files -- s/Fred[re]+i[ck]+/Fredrik/g (use-package-modules fonts emacs emacs-xyz cmake finance shellutils haskell-apps) (packages->manifest (list font-hack glibc-locales emacs-next emacs-s emacs-dash emacs-company emacs-yasnippet emacs-highlight-symbol emacs-haskell-mode emacs-smartparens emacs-jinja2-mode emacs-rust-mode emacs-go-mode emacs-cmake-mode emacs-geiser emacs-toml-mode emacs-yaml-mode emacs-json-mode emacs-markdown-mode emacs-julia-mode emacs-systemd-mode emacs-lua-mode emacs-ledger-mode emacs-gnuplot emacs-magit emacs-transient emacs-ag emacs-pdf-tools emacs-telega emacs-vterm emacs-libmpdel emacs-mpdel emacs-nginx-mode emacs-org emacs-emms emacs-ivy emacs-wgrep emacs-tramp emacs-sudo-edit emacs-evil emacs-emojify emacs-rainbow-mode emacs-move-text emacs-expand-region emacs-multiple-cursors emacs-string-inflection emacs-nov-el emacs-guix emacs-lsp-mode emacs-eglot emacs-direnv ;; External tools used by emacs direnv shellcheck ))
