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

Previous Next

Full log

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

From: Cayetano Santos <csantosb <at> inventati.org>
To: Lee Thompson <lee.p.thomp <at> gmail.com>
Cc: 77185 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: Add emacs-bqn-mode
Date: Sun, 23 Mar 2025 17:41:56 +0100

[Message part 1 (text/plain, inline)]

>dim. 23 mars 2025 at 13:09, Lee Thompson <lee.p.thomp <at> gmail.com> wrote:

>> - 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.

You’re right, no need of eros by now.

> 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

Better send a dedicated patch with it, now that you have it. It will be
useful for next update.

>> - 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.

Indeed, a little comment will help to understand future contributors,
they’ll need to remove this line once fixed upstream.

>> - `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.

Rather use ‘guix shell -CPW’, as stated in the manual, then "./pre ..."

> 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))
>>          ...

In this case, package seems to use a date tag for releases, so yes, this
is the way I’d proceed.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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