[PATCH] gnu: Add emacs-zop-to-char.

  • Open
  • quality assurance status badge
Details
3 participants
  • Liliana Marie Prikler
  • Nicolas Goaziou
  • Rostislav Svoboda
Owner
unassigned
Submitted by
Rostislav Svoboda
Severity
normal
R
R
Rostislav Svoboda wrote on 19 Nov 2023 10:54
(address . guix-patches@gnu.org)(name . Rostislav Svoboda)(address . Rostislav.Svoboda@gmail.com)
cfcd10d4245583dcbdef48c72462a8ce0a52fa86.1700387657.git.Rostislav.Svoboda@gmail.com
* gnu/packages/emacs-xyz.scm (emacs-zop-to-char): New variable.

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

Toggle diff (45 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index bad97f436d..c9a4f5674b 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -38739,6 +38739,27 @@ (define-public emacs-totp
variations, including non-standard base32 encodings.")
(license license:gpl3+))))
+(define-public emacs-zop-to-char
+ (let ((commit "00152aa666354b27e56e20565f186b363afa0dce")
+ (revision "0"))
+ (package
+ (name "emacs-zop-to-char")
+ (version (git-version "1.1" revision commit))
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/thierryvolpiatto/zop-to-char")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "1s4adi9hyhxn7ynx195mgg10h817hxdmlzlp09633bj0llr1mjn3"))))
+ (build-system emacs-build-system)
+ (home-page "https://github.com/thierryvolpiatto/zop-to-char")
+ (synopsis "A visual zap-to-char command for Emacs")
+ (description "A visual zap-to-char command for Emacs.")
+ (license license:gpl3+))))
+
;;;
;;; Avoid adding new packages to the end of this file. To reduce the chances
;;; of a merge conflict, place them above by existing packages with similar

base-commit: b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c
prerequisite-patch-id: 9a43774d20eb5c5f07500aa283aa501ce7c1d7a8
prerequisite-patch-id: fe772324962c490d954bf6197d82e3152a3990d0
prerequisite-patch-id: a7f5628906b829261dc2bfbe417a7be1eec850ec
prerequisite-patch-id: 9c0c2e59be28a04f226f98bcab6db415d00901a8
prerequisite-patch-id: 02461a5e19d62f02948d363719a7ece122198416
prerequisite-patch-id: 656a9d241ce1e5d445a535f11983ba493f0147b3
prerequisite-patch-id: 6a4d5facca6224cc9d043e39ffa4bcd6d091bed5
prerequisite-patch-id: b4992d2603e1a819e7bb0f9a354d97458b3f80ad
prerequisite-patch-id: fffccc797bda74d3b25e987538ff5b916e0e976f
--
2.41.0
L
L
Liliana Marie Prikler wrote on 19 Nov 2023 14:41
2df45375c81294c826f647095bf447a8a01dfb6c.camel@gmail.com
Am Sonntag, dem 19.11.2023 um 10:54 +0100 schrieb Rostislav Svoboda:
Toggle quote (36 lines)
> * gnu/packages/emacs-xyz.scm (emacs-zop-to-char): New variable.
>
> Change-Id: I6307a1c72739f627508886acc4130870913f9e71
> ---
>  gnu/packages/emacs-xyz.scm | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index bad97f436d..c9a4f5674b 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -38739,6 +38739,27 @@ (define-public emacs-totp
>  variations, including non-standard base32 encodings.")
>         (license license:gpl3+))))
>  
> +(define-public emacs-zop-to-char
> +  (let ((commit "00152aa666354b27e56e20565f186b363afa0dce")
> +        (revision "0"))
> +    (package
> +      (name "emacs-zop-to-char")
> +      (version (git-version "1.1" revision commit))
> +      (source
> +       (origin
> +         (method git-fetch)
> +         (uri (git-reference
> +               (url
> "https://github.com/thierryvolpiatto/zop-to-char")
> +               (commit commit)))
> +         (file-name (git-file-name name version))
> +         (sha256
> +          (base32
> "1s4adi9hyhxn7ynx195mgg10h817hxdmlzlp09633bj0llr1mjn3"))))
> +      (build-system emacs-build-system)
> +      (home-page "https://github.com/thierryvolpiatto/zop-to-char")
> +      (synopsis "A visual zap-to-char command for Emacs")
> +      (description "A visual zap-to-char command for Emacs.")
Description a sentence.
Toggle quote (2 lines)
> +      (license license:gpl3+))))
> +
Cheers
R
R
Rostislav Svoboda wrote on 19 Nov 2023 14:51
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
CAEtmmezpiRHLpw_L--jrFjfHtv_dVvbxtETBF_nPK6rVj65whg@mail.gmail.com
Toggle quote (3 lines)
> > + (description "A visual zap-to-char command for Emacs.")
> Description a sentence.

???
"Description a sentence" is not a meaningful English sentence.

Cheers
L
L
Liliana Marie Prikler wrote on 19 Nov 2023 17:27
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
6407fb50dbcea9653a69fcb74ab811da1411c686.camel@gmail.com
Am Sonntag, dem 19.11.2023 um 14:51 +0100 schrieb Rostislav Svoboda:
Toggle quote (5 lines)
> > > +      (description "A visual zap-to-char command for Emacs.")
> > Description a sentence.
>
> ???
> "Description a sentence" is not a meaningful English sentence.
Excuse my brevity. It should have been "The description of a package
should at least be a meaningful English sentence."

Cheer
L
L
Liliana Marie Prikler wrote on 19 Nov 2023 17:28
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
05ba8dafe2788d7e6643d694ce2f7201488be7e4.camel@gmail.com
Am Sonntag, dem 19.11.2023 um 17:27 +0100 schrieb Liliana Marie
Prikler:
Toggle quote (10 lines)
> Am Sonntag, dem 19.11.2023 um 14:51 +0100 schrieb Rostislav Svoboda:
> > > > +      (description "A visual zap-to-char command for Emacs.")
> > > Description a sentence.
> >
> > ???
> > "Description a sentence" is not a meaningful English sentence.
> Excuse my brevity.  It should have been "The description of a package
> should at least be a meaningful English sentence."
>
> Cheer
Missing 's'
N
N
Nicolas Goaziou wrote on 19 Nov 2023 19:38
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
875y1xmvvv.fsf@nicolasgoaziou.fr
Hello,

Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

Toggle quote (2 lines)
> * gnu/packages/emacs-xyz.scm (emacs-zop-to-char): New variable.

Thank you.

Toggle quote (4 lines)
> +(define-public emacs-zop-to-char
> + (let ((commit "00152aa666354b27e56e20565f186b363afa0dce")
> + (revision "0"))

I suggest to use the previous commit, for two reasons :
- it is a tagged commit, so you can set `version' to "1.1" instead of
the ugly (git-version ...) stuff;
- the current commit only adds a donation link to the README.

Toggle quote (2 lines)
> + (synopsis "A visual zap-to-char command for Emacs")

The synopsis shouldn't start with an article, here "A".

You may want to use guix lint to double-check this.

Regards,
--
Nicolas Goaziou
R
R
Rostislav Svoboda wrote on 19 Nov 2023 20:01
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAEtmmewvKRQBGCM3SY-QBpLjVxh5qHnMSAJCQOytfN-f9US00w@mail.gmail.com
Toggle quote (2 lines)
> - the current commit only adds a donation link to the README.

Actually, the 00152aa deleted the donation link. It didn't add it.
Either way, the commit is about "money", and that's a sensitive thing
so it's better to respect its intention.

Cheers
N
N
Nicolas Goaziou wrote on 20 Nov 2023 08:31
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
871qcknank.fsf@nicolasgoaziou.fr
Hello,

Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

Toggle quote (4 lines)
>> - the current commit only adds a donation link to the README.
>
> Actually, the 00152aa deleted the donation link. It didn't add it.

OK.

Toggle quote (3 lines)
> Either way, the commit is about "money", and that's a sensitive thing
> so it's better to respect its intention.

I disagree. Guix usually sticks to actual releases, unless there's
a really good reason not to, such as a major bug in the last release. In
this situation, the last commit is not even a feature, so it's better to
just package the 1.1 release.

Note that if the last change was that important for the author, they
would have made a release out of it. I don't think Guix would offense
anyone by providing real 1.1.

Regards,

--
Nicolas Goaziou
R
R
Rostislav Svoboda wrote on 20 Nov 2023 10:40
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAEtmmexA6Wf5VeEiSKvAAMDSgWu3SjTvqaoA2+LAqjk5ibW0+g@mail.gmail.com
Hello

Toggle quote (2 lines)
> I disagree. Guix usually sticks to actual releases [...] Note that if the last change was that important for the author, they would have made a release out of it.

Sticking to actual releases makes sense for packages that follow a
"release-has-a-version" policy, which is common for big & popular
ones.

But there's a number [see below] of smaller, less popular elisp
packages with infrequent contributions where the author doesn't really
bother with a strict "tagged-releases" policy. Sometimes it's
forgotten over the years, so "rolling-releases" become the norm.

IMO that's the case for our
done on May 1, 2018. That's over five years ago. Waiting for 1.2
doesn't make sense. It's probably not happening anytime soon, not even
soon-ish, even though the 00152aa seems to be important.

Cheers

Few examples:

| url | github stars |
last commit | nr of commits | nr of releases |
Sep 4, 2019 | 23 | 1 |
Sep 4, 2023 | 43 | 1 |
Feb 22, 2021 | 208 | 1 |
Jul 19, 2015 | 3 | 0 |
Mar 22, 2016 | 130 | 0 |
N
N
Nicolas Goaziou wrote on 20 Nov 2023 11:47
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
87wmucln08.fsf@nicolasgoaziou.fr
Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:


Toggle quote (17 lines)
>> I disagree. Guix usually sticks to actual releases [...] Note that if the last change was that important for the author, they would have made a release out of it.
>
> Sticking to actual releases makes sense for packages that follow a
> "release-has-a-version" policy, which is common for big & popular
> ones.
>
> But there's a number [see below] of smaller, less popular elisp
> packages with infrequent contributions where the author doesn't really
> bother with a strict "tagged-releases" policy. Sometimes it's
> forgotten over the years, so "rolling-releases" become the norm.
>
> IMO that's the case for our
> https://github.com/thierryvolpiatto/zop-to-char too. Our 00152aa was
> done on May 1, 2018. That's over five years ago. Waiting for 1.2
> doesn't make sense. It's probably not happening anytime soon, not even
> soon-ish, even though the 00152aa seems to be important.

I already made my point and have nothing to add to that topic.

Regards,
R
R
Rostislav Svoboda wrote on 20 Nov 2023 13:26
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
CAEtmmez0HUo-7CiPSepXQJ6e1WBH7WiwX_k21iS==4_f39CC-w@mail.gmail.com
Hello,

Toggle quote (3 lines)
> > + (description "A visual zap-to-char command for Emacs.")
> "The description of a package should at least be a meaningful English sentence."

The original zap-to-char doesn't provide much. The enhancement - our
zop-to-char doesn't improve the situation either.
The same goes for zap-up-to-char and zop-up-to-char. So asking me to
come up with one is... sigh, anyway here you go.

Toggle quote (3 lines)
> > + (synopsis "A visual zap-to-char command for Emacs")
> The synopsis shouldn't start with an article, here "A".

Fixed. Sorryyyyyyyy.

Toggle quote (2 lines)
> You may want to use guix lint to double-check this.

I did and... hmm looks like it's time to visit the ophthalmologist again.

I reworked the patch and I'm resending it in the attachment.

Cheers
From 96f67003b0e7b6abc193105c38e18bc94818e4c8 Mon Sep 17 00:00:00 2001
Message-ID: <96f67003b0e7b6abc193105c38e18bc94818e4c8.1700482998.git.Rostislav.Svoboda@gmail.com>
From: Rostislav Svoboda <Rostislav.Svoboda@gmail.com>
Date: Sun, 19 Nov 2023 10:50:57 +0100
Subject: [PATCH] gnu: Add emacs-zop-to-char.

* gnu/packages/emacs-xyz.scm (emacs-zop-to-char): New variable.

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

Toggle diff (42 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 2b096fcb24..1b5a977e15 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -38763,6 +38763,31 @@ (define-public emacs-totp
variations, including non-standard base32 encodings.")
(license license:gpl3+))))
+(define-public emacs-zop-to-char
+ (let ((commit "00152aa666354b27e56e20565f186b363afa0dce")
+ (revision "0"))
+ (package
+ (name "emacs-zop-to-char")
+ (version (git-version "1.1" revision commit))
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/thierryvolpiatto/zop-to-char")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "1s4adi9hyhxn7ynx195mgg10h817hxdmlzlp09633bj0llr1mjn3"))))
+ (build-system emacs-build-system)
+ (home-page "https://github.com/thierryvolpiatto/zop-to-char")
+ (synopsis "Visual @code{zap-to-char}-related commands for Emacs")
+ (description
+ "Visually enhanced versions of @code{zap-to-char} and
+@code{zap-to-up-char}. Precise character-level navigation and editing across the
+buffer, facilitating efficient deletion, replacement, and jumping to specific
+locations.")
+ (license license:gpl3+))))
+
;;;
;;; Avoid adding new packages to the end of this file. To reduce the chances
;;; of a merge conflict, place them above by existing packages with similar

base-commit: 71b92466430acb8c91841522dc0eb7d766af4388
prerequisite-patch-id: fffccc797bda74d3b25e987538ff5b916e0e976f
prerequisite-patch-id: 79914a97779bed9904a1d80e56fa0339eccaf329
--
2.41.0
R
R
Rostislav Svoboda wrote on 20 Nov 2023 13:28
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAEtmmezrvc9g6FUP_s9o9vZMwjmEUq7AOjPwdSZC0Oq65pfD2Q@mail.gmail.com
Toggle quote (2 lines)
> I already made my point and have nothing to add to that topic.

So have I, and neither do I.
Cheers
L
L
Liliana Marie Prikler wrote on 20 Nov 2023 20:24
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
9370a8f88da39589e9c0be29a3ab2a39b31a1bca.camel@gmail.com
Am Montag, dem 20.11.2023 um 13:26 +0100 schrieb Rostislav Svoboda:

Toggle quote (24 lines)
> +(define-public emacs-zop-to-char
> + (let ((commit "00152aa666354b27e56e20565f186b363afa0dce")
> + (revision "0"))
> + (package
> + (name "emacs-zop-to-char")
> + (version (git-version "1.1" revision commit))
> + (source
> + (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url
> "https://github.com/thierryvolpiatto/zop-to-char")
> + (commit commit)))
> + (file-name (git-file-name name version))
> + (sha256
> + (base32
> "1s4adi9hyhxn7ynx195mgg10h817hxdmlzlp09633bj0llr1mjn3"))))
> + (build-system emacs-build-system)
> + (home-page "https://github.com/thierryvolpiatto/zop-to-char")
> + (synopsis "Visual @code{zap-to-char}-related commands for
> Emacs")
> + (description
> + "Visually enhanced versions of @code{zap-to-char} and
> +@code{zap-to-up-char}.
Still not sentence.

Toggle quote (4 lines)
> Precise character-level navigation and editing across the
> +buffer, facilitating efficient deletion, replacement, and jumping to
> specific
> +locations.")
Not sentence either.

Cheers
L
L
Liliana Marie Prikler wrote on 20 Nov 2023 20:38
cd947b6574f350e964a3ed8d2c65aa8d065a8f1e.camel@gmail.com
Am Montag, dem 20.11.2023 um 10:40 +0100 schrieb Rostislav Svoboda:
Toggle quote (20 lines)
> Hello
>
> > I disagree. Guix usually sticks to actual releases [...] Note that
> > if the last change was that important for the author, they would
> > have made a release out of it.
>
> Sticking to actual releases makes sense for packages that follow a
> "release-has-a-version" policy, which is common for big & popular
> ones.
>
> But there's a number [see below] of smaller, less popular elisp
> packages with infrequent contributions where the author doesn't
> really bother with a strict "tagged-releases" policy. Sometimes it's
> forgotten over the years, so "rolling-releases" become the norm.
>
> IMO that's the case for our
> https://github.com/thierryvolpiatto/zop-to-char too. Our 00152aa was
> done on May 1, 2018. That's over five years ago. Waiting for 1.2
> doesn't make sense. It's probably not happening anytime soon, not
> even soon-ish, even though the 00152aa seems to be important.
You are right in that it does make sense to not only consider releases,
but Nicolas has already named a reason to do so among several valid
reasons. "It fixes a donation link in the README" is, in my humble
opinion, not that. Now you might want to question whether packaging a
five to seven year old package itself has any technical merit, but I'm
personally quite relaxed w.r.t. that concern.

Cheers
?