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

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


base-commit: 6e50b0c56a8cc767bd3acb26638f78c450bde718
  

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,
  

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
  

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,
  

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
  

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,
  

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
  

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,
  

Hi Nicolas, Rostislav,

This is a difficult situation because of upstream, but I mostly 
agree with Nicolas.  I think the most reasonable path forward is 
to package commit e6e15638e8c45a5e68d0874d5d8c9a46c4f38a54 and 
label it version 1.0.  Since the final commit doesn’t change the 
package functionality, I don’t think it makes sense to package it 
and have a snapshot version.  The situation would be different if 
upstream was better about releases, or the change had a functional 
impact.

An alternate option would be to package the latest commit, but 
match the MELPA snapshot version[1] instead of "1.0".  While I 
dislike that this version doesn’t appear anywhere in the source or 
repo, it’s likely to be the one non-Guix users (or those using 
Guix, but using package.el / straight.el / whatever to manage 
their Emacs packages) will recognize.

Thanks,
  -- Ian

[1]: https://melpa.org/#/vi-tilde-fringe
  

Am Sonntag, dem 09.03.2025 um 11:44 -0700 schrieb Ian Eure:
> Since the final commit doesn’t change the package functionality, I
> don’t think it makes sense to package it and have a snapshot version.
I respectfully disagree; I think we should use git-version whenever the
commit field of a package refers to a raw commit, and if I read your
mail correctly, I do think we should just package the commit you
referenced as 1.0-0-e6e15638 (I may have taken too many or too few
chars of the commit here – ah well).

Cheers
  

> I do think we should just package the commit you referenced as 1.0-0-e6e15638 (I may have taken too many or too few chars of the commit here – ah well).

It's perfectly clear to any human that the latest commit f1597a8d
contains just noise. However, tools like guix import or guix refresh
lack this insight and would therefore indicate the package as outdated
if we use e6e15638. Such an indication would offer no practical
benefit.

Moreover, using the widely adopted MELPA commit (f1597a8d) ensures
consistency with the majority of users' Emacs configurations, whereas
diverging from it by using e6e15638 would introduce unnecessary
friction.

Cheers,
Bost
  

Hello,

Let's continue the general discussion under a different subject:
Commit hashes in the version-string.

> I think we should use git-version whenever the commit field of a package refers to a raw commit

IMO, the git commit hash should always be part of the package version
when the source code is managed by git (which applies to the majority
of the ~30k packages Guix currently offers).

The commit hash is the only reliable piece of information specifying
exactly what code is being packaged. While tagging and versioning
policies usually work well for large, popular projects, smaller
projects - like vi-tilde-fringe - often have inconsistent, unclear, or
absent versioning policies. In the worst case, maintainers may even
move or delete tags after we've packaged the project, causing
unexpected hash mismatches in guix hash.

Including the commit hash directly in the package version addresses
these ambiguities, providing clarity and reliability regardless of
external tagging practices.

I'd appreciate hearing your thoughts on this.

Cheers,
Bost
  

Hi,

Euh, when Reviewing the Work of Others [1], it appears to me a case of
“spending time proportional to the stakes(1)” where (1) reads:

        (1) The tendency to discuss minute details at length is often
        referred to as “bikeshedding”, where much time is spent
        discussing each one’s preference for the color of the shed at
        the expense of progress made on the project to keep bikes dry.

Because the package at hand is 11 years old with just 3 commits and less
than one hundred of Emacs Lisp line of code.  There is more characters
in this message than in the source code itself. ;-)

Concretely, we are speaking about alternative (A) or (B), right?

      (define-public emacs-vi-tilde-fringe
        (let ((commit "f1597a8d54535bb1d84b442577b2024e6f910308")
              (revision "0"))
          (package
            (name "emacs-vi-tilde-fringe")
  (A)       (version (git-version "1.0" revision commit))
  (B)       (version "1.0")
            (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))

And that, concretely, changes nothing because no one expect to have
another version after 11 years of inactivity. :-)

My own preference is about (A) because it appears to me more consistent
with the rest.  Somehow, my understanding is the rule of thumb: use this
’revision’ and ’commit’ when there is no Git-based tag (release).  And
somehow, a kind of advertisement.  At least, as a user that’s how I
consider package with version ending with short commit hash: it’s not an
official Git-based tag.

Nicolas, Ian, any strong objection with option (A)?

Cheers,
simon

1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others