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

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

[Rostislav Svoboda]

* 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(+)

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

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

[Nicolas Goaziou via Guix-patches via]

Hello,

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

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

Thank you.

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

> +      (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

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

[Rostislav Svoboda]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Hello Nicolas,

> 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

$ git clone https://github.com/syl20bnr/vi-tilde-fringe && cd
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 #2: Type: text/html, Size: 1658 bytes --]

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

[Nicolas Goaziou via Guix-patches via]

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

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

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

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

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

[Rostislav Svoboda]

Hello,

> 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

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

[Nicolas Goaziou via Guix-patches via]

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

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

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

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

[Rostislav Svoboda]

Hello Nicolas,

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

Cheers,
Bost

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

[Nicolas Goaziou via Guix-patches via]

Hello,

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

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