Re: emacs packages and elpa

>dim. 31 déc. 2023 at 13:07, Nicolas Goaziou wrote: > Hello, > > Cayetano Santos writes: > >> We distribute emacs packages from gnu/elpa by downloading .tar files >> from there: I’m thinking about emacs-ggtags. >> >> My first concern is, what em

emacs packages and elpa

Hello Guix, We distribute emacs packages from gnu/elpa by downloading .tar files from there: I’m thinking about emacs-ggtags. My first concern is, what emacs-ggtags 0.9.0 corresponds to exactly ? There is no 0.9.0 tag in upstream github reposotory, and, if I understand it correctly, e

[emacs]: snapshots against latest versions

Hi Guix, Following a recent patch to an snapshot of an emacs package (emacs-mastodon), where latest stable (tagged) release dates back from a long time, the question of whether to send patches for non stable (tagged) versions is pertinent or not. Of course, the answer is clear: we onl

Re: Emacs next variants

>ven. 10 mars 2023 at 22:44, Andrew Tropin wrote: > [[PGP Signed Part:Undecided]] > On 2023-03-10 19:24, Cayetano Santos wrote: > >>>ven. 10 mars 2023 at 19:14, Simon Tournier wrote: >> >>> Hi, >>> >>> On Fri, 10 Mar 2023 at 17:59, Joh

Re: Emacs next variants

>ven. 10 mars 2023 at 19:14, Simon Tournier wrote: > Hi, > > On Fri, 10 Mar 2023 at 17:59, John Kehayias > wrote: > >> During this discussion some changes were made to this inheritance structure >> in >> >>

Re: Emacs next variants

>ven. 10 mars 2023 at 13:07, Simon Tournier wrote: > Note that emacs-next-tree-sitter is not from the 29 branch (emacs-next) > but from the 30 branch. Therefore, it would mean emacs-next-pgtk also > be an Emacs 30 version. I do not use them so I have not opinion. > > And why not split the cha

Emacs next variants

Hi guix, As for today, the inheritance of emacs, master branch, variants is as follows (emacs-next-tree-sitter (emacs-next-gtk (emacs-next (emacs Having tree-sitter is really useful, but optional, and doesn’t produce any harm to users. They may opt to use it, or not. This is

Re: emacs packaging: do we need to pull existing dependencies ?

>> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, >> which is not specified in the package definition, meaning we always >> pull the latest available. Do we have to, provided that emacs >> releases with org? Maybe there is already a clear rule about this >> topic, but to me thi

emacs packaging: do we need to pull existing dependencies ?

Hello Guix, I’m referring here to the way we handle propagated-inputs in package definitions, when dependencies are already present in the latest stable emacs we provide (28.2 as for today.) Think for example on all org-packages which depend on (and whose package definition declare as

Emacs packaging: do we need to pull existing dependencies ?

Hello Guix, I’m referring here to the way we handle propagated-inputs in package definitions, when dependencies are already present in the latest stable emacs we provide (28.2 as for today). Think for example on all org-packages which depend on (and whose package definition declare as

Emacs packaging: do we need to pull existing dependencies ?

Hello Guix, I’m referring here to the way we handle propagated-inputs in package definitions, when dependencies are already present in the latest stable emacs we provide (28.2 as for today.) Think for example on all org-packages which depend on (and whose package definition declare as