diff mbox series

[bug#52439,1/2] gnu: Add emacs-rec-mode.

Message ID BYAPR05MB4023BC5CD23214FFD726A4A2C5729@BYAPR05MB4023.namprd05.prod.outlook.com
State Accepted
Headers show
Series [bug#52439,1/2] gnu: Add emacs-rec-mode. | expand

Commit Message

Morgan Smith Dec. 11, 2021, 7:39 p.m. UTC
From: Morgan Smith <Morgan.J.Smith@outlook.com>

* gnu/packages/emacs-xyz.scm (emacs-rec-mode): New variable.
---
 gnu/packages/emacs-xyz.scm | 40 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

--
2.34.0

Comments

Liliana Marie Prikler Dec. 11, 2021, 10:35 p.m. UTC | #1
Hi,

Am Samstag, den 11.12.2021, 14:39 -0500 schrieb
Morgan.J.Smith@outlook.com:
> From: Morgan Smith <Morgan.J.Smith@outlook.com>
> 
> * gnu/packages/emacs-xyz.scm (emacs-rec-mode): New variable.
> ---
>  gnu/packages/emacs-xyz.scm | 40
> ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index 4fdc5f1bb3..aada2b17ce 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -22004,6 +22004,46 @@ (define-public emacs-org-brain
>  wiki.")
>      (license license:expat)))
>  
> +(define-public emacs-rec-mode
> +  ;; Compilation issues with latest release.  When updating to a
> proper
> +  ;; version, we should change the origin to elpa.
> +  (let ((commit "646962cff4f728cfa56c72ed43de8936713c8bb6")
> +        (revision "0"))
> +    (package
> +      (name "emacs-rec-mode")
> +      (version (git-version "1.8.1" revision commit))
> +      (source (origin
> +                (method git-fetch)
> +                (uri (git-reference
> +                      (url "
> https://git.savannah.gnu.org/git/recutils/rec-mode.git")
> +                      (commit commit)))
> +                (file-name (git-file-name name version))
> +                (sha256
> +                 (base32
> +                  "1f5d5kf4rc84v8208qh0l8f5ac92fjqvrlgz0hhgj764v8w2a
> hpq"))
> +                (modules '((guix build utils)))
> +                (snippet '(begin (delete-file "rec-mode.info")))))
> +      (arguments
> +       '(#:phases
> +         (modify-phases %standard-phases
> +           (add-before 'install 'make-info
> +             (lambda _
> +               (invoke "makeinfo" "--no-split"
> +                       "-o" "rec-mode.info" "rec-mode.texi"))))))
> +      (native-inputs
> +       `(("texinfo" ,texinfo)))
> +      (build-system emacs-build-system)
> +      (home-page "https://www.gnu.org/software/recutils/")
> +      (synopsis "Major mode for viewing/editing rec files")
> +      (description "Rec Mode is a mode for browsing and editing
> recfiles,
> +which are text files containing data structured in fields and
> records.  It is
> +part of the GNU recutils suite.
> +
> +Recfiles are text-based databases which are easy to read and write
> manually
> +using a text editor.  At the same time they feature enough structure
> so they
> +can be read, edited and processed automatically by programs.")
> +      (license license:gpl3+))))
> +
>  (define-public emacs-recent-addresses
>    (let ((commit "afbbfdc43b81e620acf827ca20d297e0c517b6eb")
>          (revision "1"))
Rather than a new package, I think we can very well edit the existing
package in-place, so that we don't need to add a meaningless
deprecation.  For all intents and purposes, this still is emacs-
recutils -- it's still hosted alongside recutils even though it's no
longer bundled with it.

As a second patch, we could move it to emacs-xyz, but personally both
locations feel fine.  WDYT?
Morgan Smith Dec. 12, 2021, 12:09 a.m. UTC | #2
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> Rather than a new package, I think we can very well edit the existing
> package in-place, so that we don't need to add a meaningless
> deprecation.  For all intents and purposes, this still is emacs-
> recutils -- it's still hosted alongside recutils even though it's no
> longer bundled with it.

I have no clue if this is the intention or not but I always find that
the emacs package names are in the format: emacs-FEATURE.  As in I can
just do (load "FEATURE") to load the package and start exploring.  I was
very confused when I first downloaded the package as (load "recutils")
did nothing and I had to do (load "rec-mode").  I realize this
convention isn't written down anywhere but I think maybe it should be
because it's very helpful to me personally.

> As a second patch, we could move it to emacs-xyz, but personally both
> locations feel fine.  WDYT?

The location means very little to me.  If I was just editing the package
instead of replacing it I wouldn't have moved it.
Liliana Marie Prikler Dec. 12, 2021, 12:39 a.m. UTC | #3
Hi,

Am Samstag, den 11.12.2021, 19:09 -0500 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > Rather than a new package, I think we can very well edit the
> > existing package in-place, so that we don't need to add a
> > meaningless deprecation.  For all intents and purposes, this still
> > is emacs-recutils -- it's still hosted alongside recutils even
> > though it's no longer bundled with it.
> 
> I have no clue if this is the intention or not but I always find that
> the emacs package names are in the format: emacs-FEATURE.  As in I
> can just do (load "FEATURE") to load the package and start
> exploring.  I was very confused when I first downloaded the package
> as (load "recutils") did nothing and I had to do (load "rec-
> mode").  I realize this convention isn't written down anywhere but I
> think maybe it should be because it's very helpful to me personally.
For the record, the convention is usually to use the upstream name, but
that's not always reasonable.  In this particular case, I'd argue that
emacs-recutils is equally good as it's still close enough to upstream,
plus the package does not solely contain rec-mode and ob-rec could
equally be seen as entry point.

As for loading FEATURE, that again only works for single-feature
libraries.  In addition, you shouldn't typically rely on (load
"FEATURE") or (require 'FEATURE) outside of other libraries anyway. 
Autoloads exist and Guix handles them.

Cheers
Morgan Smith Dec. 12, 2021, 1:15 a.m. UTC | #4
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> For the record, the convention is usually to use the upstream name, but
> that's not always reasonable.  In this particular case, I'd argue that
> emacs-recutils is equally good as it's still close enough to upstream,
> plus the package does not solely contain rec-mode and ob-rec could
> equally be seen as entry point.

The multiple entry points issue is certainly a valid issue with my idea.

Using the upstream name makes a lot of sense and I suppose my experience
of the main feature being equal to the name is actually a convention
that emacs package maintainers are doing, not guix.

That being said, the official upstream name is 100%, without a doubt,
"rec-mode".

The recutils info page only mentions the emacs mode once and explicitly
names it "rec-mode".

The rec-mode info page (as in `info rec-mode`) does say rec-mode is part
of the "recutils suite" but doesn't seem to ever refer to it as anything
other than rec-mode.

> As for loading FEATURE, that again only works for single-feature
> libraries.  In addition, you shouldn't typically rely on (load
> "FEATURE") or (require 'FEATURE) outside of other libraries anyway. 
> Autoloads exist and Guix handles them.

I agree with you.  Any programmatic thing based on package names is
bound to break.  I was saying that interactive exploration was made
easier because I always had a good guess on what to load based on the
package name.  I do rely on Guix to manage my autoloads but I don't
restart my Emacs just to check out a package.
Liliana Marie Prikler Dec. 13, 2021, 7:39 p.m. UTC | #5
Hi,

Am Samstag, den 11.12.2021, 20:15 -0500 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > For the record, the convention is usually to use the upstream name,
> > *but that's not always reasonable*.  

> > *In this particular case*, I'd argue that emacs-recutils *is
> > equally good*
Emphasis added.

> Using the upstream name makes a lot of sense [...]
> That being said, the official upstream name is 100%, without a doubt,
> "rec-mode".
While yes, the usual convention is to use the upstream name, and that
is rec-mode, there are also packages which break this convention
somewhere.  For instance, there are many packages which drop their
-mode suffix on ELPA or MELPA, in which we use the dropped suffix
convention, most notably emacs-org.

On a somewhat related note, due to a bug report from yours truly, rec-
mode has recently bumped its version.  There is no tag yet and it's not
available through ELPA (though it is already in their git), but the
latest version as of writing is 1.8.2.  If you still insist on the
rename, I suggest doing a series, which
1. bumps the version and changes the origin,
2. moves the package to emacs-xyz (optional), and
3. does the rename,
once we have an official 1.8.2 tarball from somewhere, or otherwise
reference the version-bumping commit. 
In any case, we shouldn't add noise such as re-exporting the package
from a different module.

Cheers
diff mbox series

Patch

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 4fdc5f1bb3..aada2b17ce 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -22004,6 +22004,46 @@  (define-public emacs-org-brain
 wiki.")
     (license license:expat)))
 
+(define-public emacs-rec-mode
+  ;; Compilation issues with latest release.  When updating to a proper
+  ;; version, we should change the origin to elpa.
+  (let ((commit "646962cff4f728cfa56c72ed43de8936713c8bb6")
+        (revision "0"))
+    (package
+      (name "emacs-rec-mode")
+      (version (git-version "1.8.1" revision commit))
+      (source (origin
+                (method git-fetch)
+                (uri (git-reference
+                      (url "https://git.savannah.gnu.org/git/recutils/rec-mode.git")
+                      (commit commit)))
+                (file-name (git-file-name name version))
+                (sha256
+                 (base32
+                  "1f5d5kf4rc84v8208qh0l8f5ac92fjqvrlgz0hhgj764v8w2ahpq"))
+                (modules '((guix build utils)))
+                (snippet '(begin (delete-file "rec-mode.info")))))
+      (arguments
+       '(#:phases
+         (modify-phases %standard-phases
+           (add-before 'install 'make-info
+             (lambda _
+               (invoke "makeinfo" "--no-split"
+                       "-o" "rec-mode.info" "rec-mode.texi"))))))
+      (native-inputs
+       `(("texinfo" ,texinfo)))
+      (build-system emacs-build-system)
+      (home-page "https://www.gnu.org/software/recutils/")
+      (synopsis "Major mode for viewing/editing rec files")
+      (description "Rec Mode is a mode for browsing and editing recfiles,
+which are text files containing data structured in fields and records.  It is
+part of the GNU recutils suite.
+
+Recfiles are text-based databases which are easy to read and write manually
+using a text editor.  At the same time they feature enough structure so they
+can be read, edited and processed automatically by programs.")
+      (license license:gpl3+))))
+
 (define-public emacs-recent-addresses
   (let ((commit "afbbfdc43b81e620acf827ca20d297e0c517b6eb")
         (revision "1"))