| Message ID | cfcd10d4245583dcbdef48c72462a8ce0a52fa86.1700387657.git.Rostislav.Svoboda@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#67272] gnu: Add emacs-zop-to-char. | expand |
Am Sonntag, dem 19.11.2023 um 10:54 +0100 schrieb Rostislav Svoboda: > * 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. > + (license license:gpl3+)))) > + Cheers
> > + (description "A visual zap-to-char command for Emacs.") > Description a sentence. ??? "Description a sentence" is not a meaningful English sentence. Cheers
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
Am Sonntag, dem 19.11.2023 um 17:27 +0100 schrieb Liliana Marie Prikler: > 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'
Hello, Rostislav Svoboda <rostislav.svoboda@gmail.com> writes: > * gnu/packages/emacs-xyz.scm (emacs-zop-to-char): New variable. Thank you. > +(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. > + (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,
> - 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
Hello, Rostislav Svoboda <rostislav.svoboda@gmail.com> writes: >> - the current commit only adds a donation link to the README. > > Actually, the 00152aa deleted the donation link. It didn't add it. OK. > 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,
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.
Cheers
Few examples:
| url | github stars |
last commit | nr of commits | nr of releases |
| https://github.com/007kevin/pdf-view-restore | 34 |
Sep 4, 2019 | 23 | 1 |
| https://github.com/DamienCassou/json-navigator | 129 |
Sep 4, 2023 | 43 | 1 |
| https://github.com/FelipeLema/emacs-counsel-gtags | 22 |
Feb 22, 2021 | 208 | 1 |
| https://github.com/Kungi/helm-cider-history | 2 |
Jul 19, 2015 | 3 | 0 |
| https://github.com/ZehCnaS34/zonokai-emacs | 11 |
Mar 22, 2016 | 130 | 0 |
Rostislav Svoboda <rostislav.svoboda@gmail.com> writes: >> 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,
> I already made my point and have nothing to add to that topic.
So have I, and neither do I.
Cheers
Am Montag, dem 20.11.2023 um 10:40 +0100 schrieb Rostislav Svoboda: > 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
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