[PATCH] gnu: Add emacs-vi-tilde-fringe.

  • Open
  • quality assurance status badge
Details
2 participants
  • Nicolas Goaziou
  • Rostislav Svoboda
Owner
unassigned
Submitted by
Rostislav Svoboda
Severity
normal
R
R
Rostislav Svoboda wrote on 31 Oct 14:59 +0100
(address . guix-patches@gnu.org)(name . Rostislav Svoboda)(address . Rostislav.Svoboda@gmail.com)
23748ec5d9ce9396cfab96cadc3f33134c9eb470.1730383172.git.Rostislav.Svoboda@gmail.com
* gnu/packages/emacs-xyz.scm (emacs-vi-tilde-fringe): New variable.

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

Toggle diff (37 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 488b4cb5d7..b03fd56585 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -7072,6 +7072,28 @@ (define-public emacs-fringe-helper
representation.")
(license license:gpl2+))))
+(define-public emacs-vi-tilde-fringe
+ (let ((commit "f1597a8d54535bb1d84b442577b2024e6f910308")
+ (revision "0"))
+ (package
+ (name "emacs-vi-tilde-fringe")
+ (version (git-version "1.0" revision commit))
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/syl20bnr/vi-tilde-fringe")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "0wdm8k49zl6i6wnh7vjkswdh5m9lix56jv37xvc90inipwgs402z"))))
+ (build-system emacs-build-system)
+ (home-page "https://github.com/syl20bnr/vi-tilde-fringe")
+ (synopsis "Display tildes on empty lines in the Emacs fringe a la Vi")
+ (description
+ "Display tildes on empty lines in the Emacs fringe a la Vi.")
+ (license license:gpl3+))))
+
(define-public emacs-git-gutter
(package
(name "emacs-git-gutter")

base-commit: 6e50b0c56a8cc767bd3acb26638f78c450bde718
--
2.46.0
N
N
Nicolas Goaziou wrote 6 days ago
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
87jzdnkou6.fsf@nicolasgoaziou.fr
Hello,

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

Toggle quote (2 lines)
> * gnu/packages/emacs-xyz.scm (emacs-vi-tilde-fringe): New variable.

Thank you.

Toggle quote (7 lines)
> +(define-public emacs-vi-tilde-fringe
> + (let ((commit "f1597a8d54535bb1d84b442577b2024e6f910308")
> + (revision "0"))
> + (package
> + (name "emacs-vi-tilde-fringe")
> + (version (git-version "1.0" revision commit))

I think you can use (version "1.0") and ignore revision. There are no
functionnal differences between the initial 1.0 release and the commit
you point to.

Toggle quote (15 lines)
> + (source
> + (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/syl20bnr/vi-tilde-fringe")
> + (commit commit)))
> + (file-name (git-file-name name version))
> + (sha256
> + (base32 "0wdm8k49zl6i6wnh7vjkswdh5m9lix56jv37xvc90inipwgs402z"))))
> + (build-system emacs-build-system)
> + (home-page "https://github.com/syl20bnr/vi-tilde-fringe")
> + (synopsis "Display tildes on empty lines in the Emacs fringe a la Vi")
> + (description
> + "Display tildes on empty lines in the Emacs fringe a la Vi.")

The description should consist of complete sentences only.

Could you send an updated patch?

Regards,
--
Nicolas Goaziou
R
R
Rostislav Svoboda wrote 6 days ago
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAEtmmexd4Sa-U1c7_tZOin5XDO+Rs34WCZdev=DpXdA5aSPrEg@mail.gmail.com
Hello Nicolas,

Toggle quote (4 lines)
> I think you can use (version "1.0") and ignore revision. There are no
> functionnal differences between the initial 1.0 release and the commit
> you point to.

???
What do you mean by "the initial 1.0 release"? I see no release tag in the
repository which consists of just 3 commits anyway.

Cheers
Bost

vi-tilde-fringe
...
$ git log
commit f1597a8d54535bb1d84b442577b2024e6f910308 (HEAD -> master,
origin/master, origin/HEAD)
Author: syl20bnr <sylvain.benner@gmail.com>
Date: Mon Dec 29 21:55:25 2014 -0500

Add MELPA badge

commit e6e15638e8c45a5e68d0874d5d8c9a46c4f38a54
Author: syl20bnr <sylvain.benner@gmail.com>
Date: Mon Oct 27 22:40:57 2014 -0400

vi-tilde-fringe.el

commit ef3b2c1ff9d5737b873bb49370e869d54e5e70d7
Author: Sylvain Benner <sylvain.benner@gmail.com>
Date: Mon Oct 27 21:36:28 2014 -0400

Initial commit
Attachment: file
N
N
Nicolas Goaziou wrote 6 days ago
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
87ed3vkndu.fsf@nicolasgoaziou.fr
Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

Toggle quote (3 lines)
> What do you mean by "the initial 1.0 release"? I see no release tag in the
> repository which consists of just 3 commits anyway.

You're pointing to the following commit:

Toggle quote (7 lines)
> commit f1597a8d54535bb1d84b442577b2024e6f910308 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: syl20bnr <sylvain.benner@gmail.com>
> Date: Mon Dec 29 21:55:25 2014 -0500
>
> Add MELPA badge

It has no functional difference with the following, which specifies Vi
Tilde Fringe version to 1.0 through it "Version:" keyword:

Toggle quote (6 lines)
> commit e6e15638e8c45a5e68d0874d5d8c9a46c4f38a54
> Author: syl20bnr <sylvain.benner@gmail.com>
> Date: Mon Oct 27 22:40:57 2014 -0400
>
> vi-tilde-fringe.el

Therefore, I suggest to keep using the commit you refer to (f1597...),
but mark it as version 1.0 instead of an obscure 1.0-1.f1597a8.

HTH,
R
R
Rostislav Svoboda wrote 6 days ago
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAEtmmez8Xsnonn7HYESoWALUKmqLwqAdbwniPcRk9XUdKVG=fQ@mail.gmail.com
Hello,

Toggle quote (3 lines)
> Therefore, I suggest to keep using the commit you refer to (f1597...),
> but mark it as version 1.0 instead of an obscure 1.0-1.f1597a8.

Did you mean 1.0-0.f1597a8?

Many Emacs packages have arbitrary version numbers like 0.1, 1.0,
0.07, 0.3.0, 20241019.2151, etc., or sometimes no version at all.
(Believe me, I’ve seen it all.) The only meaningful and reliable part
is actually just the commit hash, like f1597a8.

So, the 1.0 is already part of the version string, and the 0. is yet
another piece of arbitrary, unreliable information added by us and our
conventions this time.

Cheers
Bost
N
N
Nicolas Goaziou wrote 6 days ago
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
878qu3kkhi.fsf@nicolasgoaziou.fr
Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

Toggle quote (5 lines)
>> Therefore, I suggest to keep using the commit you refer to (f1597...),
>> but mark it as version 1.0 instead of an obscure 1.0-1.f1597a8.
>
> Did you mean 1.0-0.f1597a8?

Yes.

Toggle quote (9 lines)
> Many Emacs packages have arbitrary version numbers like 0.1, 1.0,
> 0.07, 0.3.0, 20241019.2151, etc., or sometimes no version at all.
> (Believe me, I’ve seen it all.) The only meaningful and reliable part
> is actually just the commit hash, like f1597a8.
>
> So, the 1.0 is already part of the version string, and the 0. is yet
> another piece of arbitrary, unreliable information added by us and our
> conventions this time.

We use revision and commits to distinguish versions from plain ones, to
say : "be careful, we didn't package the exact 1.0 release". In this
particular case, the "-0.f1597a8" suffix in the version field would
bring no valuable information: we're packaging the exact 1.0 release.

Of course, you need to refer to the commit hash in the package
definition, since upstream didn't tag its initial release. I'm
advocating for removing that information from the version field only.
We're already doing this for projects that do not tag releases. See,
e.g., `emacs-inspector'.

Regards,
R
R
Rostislav Svoboda wrote 6 days ago
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
CAEtmmexz6ic5S24jjsjGd4S14bqdoMm-RKf3QXfJobSSFLURrw@mail.gmail.com
Hello Nicolas,

Toggle quote (3 lines)
> We use revision and commits to distinguish versions from plain ones, to
> say : "be careful, we didn't package the exact 1.0 release".

This is information no one can reliably depend on, as there's no
mechanism to guarantee what you're suggesting.

Toggle quote (4 lines)
> I'm advocating for removing that information from the version field only.
> We're already doing this for projects that do not tag releases. See, e.g.,
> `emacs-inspector'.

If you want to be *sure* that emacs-inspector includes no
(modify-phases ...), you'll need to check its definition anyway.
There's no point in hiding the commit hash.

On the contrary, the commit hash is quite useful. It immediately and
reliably indicates which commit was used to build a package.

This information is particularly helpful when performing a git bisect,
manually inspecting the /gnu/store, and similar tasks.

Cheers,
Bost
N
N
Nicolas Goaziou wrote 6 days ago
(name . Rostislav Svoboda)(address . rostislav.svoboda@gmail.com)
87zfmik32p.fsf@nicolasgoaziou.fr
Hello,

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

Toggle quote (20 lines)
>> We use revision and commits to distinguish versions from plain ones, to
>> say : "be careful, we didn't package the exact 1.0 release".
>
> This is information no one can reliably depend on, as there's no
> mechanism to guarantee what you're suggesting.
>
>> I'm advocating for removing that information from the version field only.
>> We're already doing this for projects that do not tag releases. See, e.g.,
>> `emacs-inspector'.
>
> If you want to be *sure* that emacs-inspector includes no
> (modify-phases ...), you'll need to check its definition anyway.
> There's no point in hiding the commit hash.
>
> On the contrary, the commit hash is quite useful. It immediately and
> reliably indicates which commit was used to build a package.
>
> This information is particularly helpful when performing a git bisect,
> manually inspecting the /gnu/store, and similar tasks.

AFAICT, this is not what is done in Guix. Usually versions follow
upstream tags, and revisions+commits are the exception, not the rule.

You seem to have a divergent opinion on the subject. That's fair, but
I think we're at a dead end now. Since I don't want to block nor delay
this patch, I'll let others proceed with the review.

Regards,
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 74137@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 74137
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch