Subject: Re: [PATCH] gnu: Add emacs-bqn-mode

From: Lee Thompson <[email-masked]>
Date: Sun, 23 Mar 2025 13:09:58 +0000

Hi,

Thanks for the reply and feedback.  I'll get on with tidying up my
patch, but I think there may have been a misunderstanding:

> - emacs-eros 0.1.0 seems necessary as propagated input (we have
>   0.0.1-2.dd89102 in the repos)
So I decided to work at packaging the '2024-09-10' tag from the upstream
project instead of the latest commit on the trunk or develop branch.
It looks like the commit adding 'Package-Requires: ... (eros "0.1.0")'
came just after the one tagged '2024-09-10', so I didn't think it was
necessary to add it as a propagated input.

As a sidenote I did successfully package it with an updated emacs-eros
before I realised I was on 'trunk' and not a release/tag, so if you
really want I could send in a revised patch with bqn-mode on the latest
commit with an updated eros

> - why do you need to (require 'subr-x) ? this is not a decision of
>   package maintainers ?
Without explicitly requiring it I was unable to run `bqn-comint-bring'
in the mode to open an interpreter.  I eventually tracked this down to
Emacs being totally confused about the macro `thread-last' within
`bqn-comint-bring', which is defined in `subr-x.el' but isn't
autoloaded.  This does give me an idea to open a PR upstream, but that
wouldn't solve it for the 2024-09-10 tag of course.

For a comparable situation have a look at `emacs-tree-inspector', where
something similar is performed.  I thought calling Emacs batch mode to
edit was neater.  I think I should have put in a short comment
explaining, my apologies.

After some searching around it looks to be something to do with the way
Guix's build system byte-compiles the Emacs files —I'm not really sure
to be totally honest.

> - `guix lint emacs-bqn-mode' uses release "2024-09-10" as version, not
>   0.1.0, maybe it is better to use it so that `guix refresh' will warn
>   about future updates
Okay I see what you mean about this, until now I'd been running
`./pre-inst-env guix lint emacs-bqn-mode' within a Guix shell container
which of course hits some issues.  Running it in a plain shell mentions
upgrading to 2024-09-10.

I'd followed some other examples in `emacs-xyz.scm' where it looked like
the tagged name didn't match with the `Version: ' line within the main
Emacs Lisp source.  See 'emacs-everywhere' for an example.  What I
hadn't thought about was that in this case there's a tag to work with
for version.

Before I send in a revised patch, do you mean something like this would
work:
> (define-public emacs-bqn-mode
>   (let ((tag "2024-09-10"))
>     (package
>       (name "emacs-bqn-mode")
>       (version tag)
>       (source
>        (origin
>          (method git-fetch)
>          (uri (git-reference
>                (url "https://github.com/museoa/bqn-mode")
>                (commit tag)))
>          (file-name (git-file-name name version))
>          ...
?

Again appreciate the feedback and advice, looking forward to hearing
back from you soon.