| Message ID | CAAc=MEw38x9vtQjdsEKBNpzyVTA5Wguk9OohMjMbehPiCZhCUQ@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#34865] Add emacs-zones. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | Apply failed |
Hello Brian, Could we use emacs-zones from Elpa? See https://elpa.gnu.org/packages/zones.html . ‘guix import elpa emacs-zones’ will produce a decent ‘origin’ record to pull a source. Please, don't forget to add a changelog entry to commit message: * gnu/packages/emacs-xyz.scm (emacs-zones): New variable. If you use Magit you could type ‘add’ to paste a yasnippet from ‘etc/snippets/’ Guix Git repository. Add this directory to ‘yas-snippet-dirs’, see https://www.gnu.org/software/guix/manual/en/html_node/The-Perfect-Setup.html Thanks, Oleg.
Hi Oleg, Oleg Pykhalov <go.wigust@gmail.com> skribis: > Could we use emacs-zones from Elpa? See > https://elpa.gnu.org/packages/zones.html . ‘guix import elpa > emacs-zones’ will produce a decent ‘origin’ record to pull a source. My understanding is that ELPA and MELPA tarballs are not necessarily persistent and immutable, and that we generally prefer referring directly to the upstream repo. Or am I confusing things? Ludo’.
Hi Ludovic, Ludovic Courtès <ludo@gnu.org> writes: […] >> Could we use emacs-zones from Elpa? See >> https://elpa.gnu.org/packages/zones.html . ‘guix import elpa >> emacs-zones’ will produce a decent ‘origin’ record to pull a source. > > My understanding is that ELPA and MELPA tarballs are not necessarily > persistent and immutable, and that we generally prefer referring > directly to the upstream repo. Ouch, I thought ELPA is persistent. That's a significant argument to not use ELPA for our purposes :-( . > Or am I confusing things? We preferred ELPA over GitHub's Git repositories in emacs-xys.scm (emacs.scm in past), didn't we? Oleg.
Hi Oleg, Oleg Pykhalov <go.wigust@gmail.com> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > > […] > >>> Could we use emacs-zones from Elpa? See >>> https://elpa.gnu.org/packages/zones.html . ‘guix import elpa >>> emacs-zones’ will produce a decent ‘origin’ record to pull a source. >> >> My understanding is that ELPA and MELPA tarballs are not necessarily >> persistent and immutable, and that we generally prefer referring >> directly to the upstream repo. > > Ouch, I thought ELPA is persistent. That's a significant argument to > not use ELPA for our purposes :-( . > >> Or am I confusing things? > > We preferred ELPA over GitHub's Git repositories in emacs-xys.scm > (emacs.scm in past), didn't we? Hmmm, not sure, Ricardo, what’s the story? :-) Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi Oleg, > > Oleg Pykhalov <go.wigust@gmail.com> skribis: > >> Ludovic Courtès <ludo@gnu.org> writes: >> >> […] >> >>>> Could we use emacs-zones from Elpa? See >>>> https://elpa.gnu.org/packages/zones.html . ‘guix import elpa >>>> emacs-zones’ will produce a decent ‘origin’ record to pull a source. >>> >>> My understanding is that ELPA and MELPA tarballs are not necessarily >>> persistent and immutable, and that we generally prefer referring >>> directly to the upstream repo. >> >> Ouch, I thought ELPA is persistent. That's a significant argument to >> not use ELPA for our purposes :-( . I only know that MELPA isn’t immutable. I assumed that ELPA is fine. >> We preferred ELPA over GitHub's Git repositories in emacs-xys.scm >> (emacs.scm in past), didn't we? > > Hmmm, not sure, Ricardo, what’s the story? :-) I don’t think we did. I can’t think of even one case where we switched from git-fetch from GitHub to url-fetch from ELPA. git-fetch is the preferred way when there are no stable tarballs. -- Ricardo
Hello, Ricardo Wurmus <rekado@elephly.net> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >>>>> Could we use emacs-zones from Elpa? See >>>>> https://elpa.gnu.org/packages/zones.html . ‘guix import elpa >>>>> emacs-zones’ will produce a decent ‘origin’ record to pull a source. >>>> >>>> My understanding is that ELPA and MELPA tarballs are not necessarily >>>> persistent and immutable, and that we generally prefer referring >>>> directly to the upstream repo. >>> >>> Ouch, I thought ELPA is persistent. That's a significant argument to >>> not use ELPA for our purposes :-( . > > I only know that MELPA isn’t immutable. I assumed that ELPA is fine. [...] > git-fetch is the preferred way when there are no stable tarballs. So, Oleg, I think you can go either way, but fetching over Git is probably safer. Can you apply the patch? Thanks, Ludo’.
Hello, Ludovic Courtès <ludo@gnu.org> writes: […] >>>>>> Could we use emacs-zones from Elpa? See >>>>>> https://elpa.gnu.org/packages/zones.html . ‘guix import elpa >>>>>> emacs-zones’ will produce a decent ‘origin’ record to pull a source. >>>>> >>>>> My understanding is that ELPA and MELPA tarballs are not necessarily >>>>> persistent and immutable, and that we generally prefer referring >>>>> directly to the upstream repo. >>>> >>>> Ouch, I thought ELPA is persistent. That's a significant argument to >>>> not use ELPA for our purposes :-( . >> >> I only know that MELPA isn’t immutable. I assumed that ELPA is fine. > > [...] > >> git-fetch is the preferred way when there are no stable tarballs. > > So, Oleg, I think you can go either way, but fetching over Git is > probably safer. > > Can you apply the patch? OK, pushed as c881ed8698517a2c2007c2fdc3a7aeec52ff109c with a source fetching over Git. Thanks, Oleg.
From 1d32be2a74fe747a6b52d6aae580e79969e960ff Mon Sep 17 00:00:00 2001 From: Brian Leung <bkleung89@gmail.com> Date: Fri, 15 Mar 2019 01:20:28 +0100 Subject: [PATCH] gnu: Add emacs-zones. --- gnu/packages/emacs-xyz.scm | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm index 9fdb00efb9..51a647608f 100644 --- a/gnu/packages/emacs-xyz.scm +++ b/gnu/packages/emacs-xyz.scm @@ -5710,6 +5710,32 @@ interface and multiple, selectable \"styles\", whose use is fully customizable by the user.") (license license:gpl2+))) +(define-public emacs-zones + (let ((commit "353fc38a6544eb59887bee045e373406f1d038a5") + (revision "1")) + (package + (name "emacs-zones") + (version (git-version "0" revision commit)) + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/emacsmirror/zones.git") + (commit commit))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "0gwnw2giii2a14nlh62xp45f47cw6ikqphhzpmcw6c7mn9x5z2ar")))) + (build-system emacs-build-system) + (home-page "https://www.emacswiki.org/emacs/Zones") + (synopsis "Define and act on multiple zones of buffer text") + (description "Library @file{zones.el} lets you easily define and +subsequently act on multiple zones of buffer text. You can think of this as +enlarging the notion of region. In effect, it can remove the requirement of +target text being a contiguous sequence of characters. A set of buffer zones +is, in effect, a (typically) noncontiguous set of text.") + (license license:gpl3+)))) + (define-public emacs-mu4e-alert (package (name "emacs-mu4e-alert") -- 2.21.0