GNU bug report logs -
#74137
[PATCH] gnu: Add emacs-vi-tilde-fringe.
Previous Next
To reply to this bug, email your comments to 74137 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
andrew <at> trop.in, cox.katherine.e+guix <at> gmail.com, liliana.prikler <at> gmail.com, guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Thu, 31 Oct 2024 14:01:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
andrew <at> trop.in, cox.katherine.e+guix <at> gmail.com, liliana.prikler <at> gmail.com, guix-patches <at> gnu.org
.
(Thu, 31 Oct 2024 14:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
* 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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 14:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74137 <at> debbugs.gnu.org (full text, mbox):
Hello,
Rostislav Svoboda <rostislav.svoboda <at> 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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 14:44:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 74137 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com>
Date: Mon Dec 29 21:55:25 2014 -0500
Add MELPA badge
commit e6e15638e8c45a5e68d0874d5d8c9a46c4f38a54
Author: syl20bnr <sylvain.benner <at> gmail.com>
Date: Mon Oct 27 22:40:57 2014 -0400
vi-tilde-fringe.el
commit ef3b2c1ff9d5737b873bb49370e869d54e5e70d7
Author: Sylvain Benner <sylvain.benner <at> gmail.com>
Date: Mon Oct 27 21:36:28 2014 -0400
Initial commit
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 15:04:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 74137 <at> debbugs.gnu.org (full text, mbox):
Rostislav Svoboda <rostislav.svoboda <at> 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 <at> 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 <at> 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,
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 15:54:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 74137 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 16:06:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 74137 <at> debbugs.gnu.org (full text, mbox):
Rostislav Svoboda <rostislav.svoboda <at> 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,
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 20:26:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 74137 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Fri, 01 Nov 2024 22:22:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 74137 <at> debbugs.gnu.org (full text, mbox):
Hello,
Rostislav Svoboda <rostislav.svoboda <at> 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,
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Sun, 09 Mar 2025 18:45:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 74137 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Sun, 09 Mar 2025 19:42:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 74137 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Mon, 10 Mar 2025 11:17:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 74137 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Mon, 10 Mar 2025 11:33:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 74137 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org
:
bug#74137
; Package
guix-patches
.
(Mon, 10 Mar 2025 19:48:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 74137 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 99 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.