Hi Dario, dario writes: > Thanks for your feedback. > >>> --- >>> gnu/packages/emacs-xyz.scm | 71 ++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 71 insertions(+) >>> >>> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm >>> index 6b9027df8a..c6df469895 100644 >>> --- a/gnu/packages/emacs-xyz.scm >>> +++ b/gnu/packages/emacs-xyz.scm >>> @@ -8601,6 +8601,77 @@ It should enable you to implement low-level X11 applications.") >>> built on top of XELB.") >>> (license license:gpl3+))) >>> >>> +(define-public emacs-exwm-next >> >> I think you don't need to copy the whole package definition. Instead, >> you could `inherit' from the original definition and only adjust the >> name, description, inputs and maybe arguments. >> >> For instance >> >> --8<---------------cut here---------------start------------->8--- >> (define-public emacs-exwm-next >> (package >> (inherit emacs) >> (name "emacs-exwm-next") >> (inputs ...) >> (synopsys ...))) >> --8<---------------cut here---------------end--------------->8--- >> >> See `substitute-keyword-arguments' in the fftwf package for a convenient >> way to modify just one argument. >> >>> + (package >>> + (name "emacs-exwm-next") >>> + (version "0.23") >>> + (synopsis "Emacs X window manager") > > Nice - I was not aware of that. The following definition seems to work > (see also the patch at the end of this mail) >> --8<---------------cut here---------------start------------->8--- > (define-public emacs-exwm-next > (package > (inherit emacs-exwm) > (name "emacs-exwm-next") > (synopsis "Emacs X window manager using the next version of emacs") > (inputs > (cons > `("emacs-next" ,emacs-next) > (delete `("emacs" ,emacs) > (package-inputs emacs-exwm)))))) Maybe a bit better: (inputs `(("emacs" ,emacs-next) ,@(alist-delete "emacs" (package-inputs emacs-exwm)))))) >> --8<---------------cut here---------------end------------->8--- > >>> + (arguments >>> + `(#:emacs ,emacs >> >> Shouldn't this be `emacs-next` as well? > I have to admit that I do not understand that part. If I change it to > emacs-next, the build fails with the error >> --8<---------------cut here---------------start------------->8--- > phase `install' succeeded after 0.0 seconds > starting phase `make-autoloads' > Wrong type argument: stringp, nil > command "/gnu/store/1z520fgx6fiq426yf2174kal2q63a9q7-emacs-next-27.0.50-0.36abf68/bin/emacs" "--quick" "--batch" "--eval=(let ((backup-inhibited t) (generated-autoload-file \"/gnu/store/nnjcqc448yj79dxaj11fnq7s9a8zpc1z-emacs-exwm-next-test-0.23/share/emacs/site-lisp/exwm-next-test-autoloads.el\")) (update-directory-autoloads \"/gnu/store/nnjcqc448yj79dxaj11fnq7s9a8zpc1z-emacs-exwm-next-test-0.23/share/emacs/site-lisp\"))" failed with status 255 >> --8<---------------cut here---------------end------------->8--- > It is a bit difficult for me to understand what is going on here, > because, like I said, I do not really understand this part of the > package definition in the first place - sorry. However, without > modifying the arguments, everything seems to work. The `#:emacs` field tells the build system which Emacs package to use to build this package. There may be something that not compatible between our current build system and emacs-next. I've CC'ed Maxim and Leo, they might know more than me. > The following patch seems to work (do I need to send it on its own? I am > new to this type of workflow.) Attaching to this email is fine. Better is to use `git send-email` like so: --8<---------------cut here---------------start------------->8--- git send-email --to=39804@debbugs.gnu.org --in-reply-to= 0001-your.patch --8<---------------cut here---------------end--------------->8--- with being the message ID of the email you are replying to. You can get this message ID in various ways: one way that always works is to look up the "message-id" header of the raw email. Also when you generate the patch with git, set the subject prefix to [PATCH v2] for the second iteration, PATCH v3 for the third, etc. Thanks! -- Pierre Neidhardt https://ambrevar.xyz/