GNU bug report logs - #77185
[PATCH] gnu: Add emacs-bqn-mode

Previous Next

Full log

Message #14 received at 77185 <at> debbugs.gnu.org (full text, mbox):

From: Lee Thompson <lee.p.thomp <at> gmail.com>
To: Cayetano Santos <csantosb <at> inventati.org>
Cc: 77185 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: Add emacs-bqn-mode
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.