diff mbox series

[bug#77185] gnu: Add emacs-bqn-mode

Message ID 20250322162557.9873-2-lee.p.thomp@gmail.com
State New
Headers
Series [bug#77185] gnu: Add emacs-bqn-mode |

Commit Message

Lee Thompson March 22, 2025, 4:25 p.m. UTC 
  * gnu/packages/emacs-xyz.scm (emacs-bqn-mode): New variable

Change-Id: Ibe9a32c4f8414dbc5d3bb350aa684a8f3e15c567
---
 gnu/packages/emacs-xyz.scm | 40 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

Comments

Lee Thompson March 22, 2025, 4:36 p.m. UTC | #1 
Hey all reviewing this,

I've only just realised I've forgotten to add my name to the copyright
list at the top of the file (assuming what I've read is correct I can
just bundle it with my patch to add the package right?).

I only read in the manual about adding this in after I sent my last
patch for emacs-parinfer-rust-mode, and I've been kicking myself since
for missing it.  Should I send in a revised patch or is it trivial
enough for a maintainer to take care of before merging the existing
patch in?
Cayetano Santos March 23, 2025, 10:50 a.m. UTC | #2 
Thanks for the patch ! You may send an updated version, including the
copyright.

A few comments:

- emacs-eros 0.1.0 seems necessary as propagated input (we have
  0.0.1-2.dd89102 in the repos)
- you may drop the .git in url
- why do you need to (require 'subr-x) ? this is not a decision of
  package maintainers ?
- `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
Lee Thompson March 23, 2025, 1:09 p.m. UTC | #3 
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.
Cayetano Santos March 23, 2025, 4:41 p.m. UTC | #4 
>dim. 23 mars 2025 at 13:09, Lee Thompson <lee.p.thomp@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.
Lee Thompson March 23, 2025, 6:04 p.m. UTC | #5 
I think I've adjusted according to everything you've mentioned.  A v2
patch should arrive shortly, I'll get the eros patch tidied up and sent
over also.

Thanks for all the help!
diff mbox series

Patch

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index f7459c3c32..30d439172f 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -487,6 +487,46 @@  (define-public emacs-bookmark-plus
 reading the extensive documentation about BookmarkPlus on the Emacs Wiki.")
     (license license:gpl3+)))
 
+(define-public emacs-bqn-mode
+  ;; Latest tagged version
+  (let ((commit "2024-09-10")
+        (revision "0"))
+    (package
+      (name "emacs-bqn-mode")
+      (version (git-version "0.1.0" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               (url "https://github.com/museoa/bqn-mode.git")
+               (commit commit)))
+         (file-name (git-file-name name version))
+         (sha256
+          (base32 "0a4whlx8065c15nfyqy8176mwysnc13z4q7mmdfnf6skdnvi2pk6"))))
+      (build-system emacs-build-system)
+      (arguments
+       (list
+        #:phases
+        #~(modify-phases %standard-phases
+            (add-after 'unpack 'require-subr-x
+              (lambda _
+                (emacs-batch-edit-file "bqn-mode.el"
+                                       '(progn (goto-char (point-min))
+                                               (re-search-forward
+                                                "(require 'pulse)")
+                                               (forward-line)
+                                               (insert "(require 'subr-x)\n")
+                                               (basic-save-buffer))))))))
+      (propagated-inputs (list emacs-compat))
+      (synopsis "Emacs major mode for the BQN programming language")
+      (description
+       "This package provides a major mode for editing and executing BQN code.
+It can be used to interactively evaluate BQN code in buffer or can be used to
+launch BQN REPL sessions.  For evaluating BQN code or spawning interpreters an
+executable implementation is required such as @code{cbqn} or @code{dbqn}.")
+      (home-page "https://github.com/museoa/bqn-mode")
+      (license license:gpl3))))
+
 (define-public emacs-cfrs
   (package
     (name "emacs-cfrs")