| Message ID | cover.1686327727.git.liliana.prikler@gmail.com |
|---|---|
| Headers | show |
| Series | Start preparing for Emacs 29 | expand |
On 2023-06-09 18:22, Liliana Marie Prikler wrote: > Hi Guix, > > it's already been four weeks since the newest Emacs pre-release. Time > sure flies. With that in mind, I'd like to start work in the Emacs team > focused on > 1. streamlining our Emacs packages > 2. improving emacs-build-system and adapting it to the new features of > Emacs 29 (including the almost forgotten [1]) > 3. improving our Emacs package management (i.e. making it easier to > declare variants of emacs-* packages built with different Emacsen) > > This series gets us started on (1), so we can do (2) and (3) hopefully > soon. > > Cheers > > [1] https://issues.guix.gnu.org/57122 > > Liliana Marie Prikler (2): > gnu: Make emacs-next-tree-sitter the new emacs. > gnu: Construct Emacs packages from bottom up. > > gnu/local.mk | 1 - > gnu/packages/emacs.scm | 467 +++++++----------- > .../patches/emacs-source-date-epoch.patch | 20 - > 3 files changed, 190 insertions(+), 298 deletions(-) > delete mode 100644 gnu/packages/patches/emacs-source-date-epoch.patch > > > base-commit: 44bbfc24e4bcc48d0e3343cd3d83452721af8c36 Hi Liliana, the patch series looks good, thank you for working on this. Do we want to add (define-deprecated/alias) to make the transition to new emacs package names smoother?
Am Samstag, dem 10.06.2023 um 10:46 +0400 schrieb Andrew Tropin: > On 2023-06-09 18:22, Liliana Marie Prikler wrote: > > > Hi Guix, > > > > it's already been four weeks since the newest Emacs pre-release. > > Time > > sure flies. With that in mind, I'd like to start work in the Emacs > > team > > focused on > > 1. streamlining our Emacs packages > > 2. improving emacs-build-system and adapting it to the new features > > of > > Emacs 29 (including the almost forgotten [1]) > > 3. improving our Emacs package management (i.e. making it easier to > > declare variants of emacs-* packages built with different > > Emacsen) > > > > This series gets us started on (1), so we can do (2) and (3) > > hopefully > > soon. > > > > Cheers > > > > [1] https://issues.guix.gnu.org/57122 > > > > Liliana Marie Prikler (2): > > gnu: Make emacs-next-tree-sitter the new emacs. > > gnu: Construct Emacs packages from bottom up. > > > > gnu/local.mk | 1 - > > gnu/packages/emacs.scm | 467 +++++++------- > > ---- > > .../patches/emacs-source-date-epoch.patch | 20 - > > 3 files changed, 190 insertions(+), 298 deletions(-) > > delete mode 100644 gnu/packages/patches/emacs-source-date- > > epoch.patch > > > > > > base-commit: 44bbfc24e4bcc48d0e3343cd3d83452721af8c36 > > Hi Liliana, > > the patch series looks good, thank you for working on this. Do we > want to add (define-deprecated/alias) to make the transition to new > emacs package names smoother? Since it'll be a "world"-rebuilding change, I think a news entry ought to be preferred. Cheers
On 2023-06-10 09:46, Liliana Marie Prikler wrote: > Am Samstag, dem 10.06.2023 um 10:46 +0400 schrieb Andrew Tropin: >> On 2023-06-09 18:22, Liliana Marie Prikler wrote: >> >> > Hi Guix, >> > >> > it's already been four weeks since the newest Emacs pre-release. >> > Time >> > sure flies. With that in mind, I'd like to start work in the Emacs >> > team >> > focused on >> > 1. streamlining our Emacs packages >> > 2. improving emacs-build-system and adapting it to the new features >> > of >> > Emacs 29 (including the almost forgotten [1]) >> > 3. improving our Emacs package management (i.e. making it easier to >> > declare variants of emacs-* packages built with different >> > Emacsen) >> > >> > This series gets us started on (1), so we can do (2) and (3) >> > hopefully >> > soon. >> > >> > Cheers >> > >> > [1] https://issues.guix.gnu.org/57122 >> > >> > Liliana Marie Prikler (2): >> > gnu: Make emacs-next-tree-sitter the new emacs. >> > gnu: Construct Emacs packages from bottom up. >> > >> > gnu/local.mk | 1 - >> > gnu/packages/emacs.scm | 467 +++++++------- >> > ---- >> > .../patches/emacs-source-date-epoch.patch | 20 - >> > 3 files changed, 190 insertions(+), 298 deletions(-) >> > delete mode 100644 gnu/packages/patches/emacs-source-date- >> > epoch.patch >> > >> > >> > base-commit: 44bbfc24e4bcc48d0e3343cd3d83452721af8c36 >> >> Hi Liliana, >> >> the patch series looks good, thank you for working on this. Do we >> want to add (define-deprecated/alias) to make the transition to new >> emacs package names smoother? > Since it'll be a "world"-rebuilding change, I think a news entry ought > to be preferred. I don't think one excludes another. We can provide both news entry and deprecation alias. This way we let people update guix channel version without any changes to their configurations, let them know emacs-next-blabla will dissapear soon and give them time to react and update their configurations accordingly without hurry. I'm ok proceeding without this extra step, but the deprecation workflow seems nicer to me.
Am Samstag, dem 10.06.2023 um 12:20 +0400 schrieb Andrew Tropin: > On 2023-06-10 09:46, Liliana Marie Prikler wrote: > > > Am Samstag, dem 10.06.2023 um 10:46 +0400 schrieb Andrew Tropin: > > > On 2023-06-09 18:22, Liliana Marie Prikler wrote: > > > > > > > Hi Guix, > > > > > > > > it's already been four weeks since the newest Emacs pre- > > > > release. > > > > Time > > > > sure flies. With that in mind, I'd like to start work in the > > > > Emacs > > > > team > > > > focused on > > > > 1. streamlining our Emacs packages > > > > 2. improving emacs-build-system and adapting it to the new > > > > features > > > > of > > > > Emacs 29 (including the almost forgotten [1]) > > > > 3. improving our Emacs package management (i.e. making it > > > > easier to > > > > declare variants of emacs-* packages built with different > > > > Emacsen) > > > > > > > > This series gets us started on (1), so we can do (2) and (3) > > > > hopefully > > > > soon. > > > > > > > > Cheers > > > > > > > > [1] https://issues.guix.gnu.org/57122 > > > > > > > > Liliana Marie Prikler (2): > > > > gnu: Make emacs-next-tree-sitter the new emacs. > > > > gnu: Construct Emacs packages from bottom up. > > > > > > > > gnu/local.mk | 1 - > > > > gnu/packages/emacs.scm | 467 +++++++--- > > > > ---- > > > > ---- > > > > .../patches/emacs-source-date-epoch.patch | 20 - > > > > 3 files changed, 190 insertions(+), 298 deletions(-) > > > > delete mode 100644 gnu/packages/patches/emacs-source-date- > > > > epoch.patch > > > > > > > > > > > > base-commit: 44bbfc24e4bcc48d0e3343cd3d83452721af8c36 > > > > > > Hi Liliana, > > > > > > the patch series looks good, thank you for working on this. Do > > > we want to add (define-deprecated/alias) to make the transition > > > to new emacs package names smoother? > > Since it'll be a "world"-rebuilding change, I think a news entry > > ought to be preferred. > > I don't think one excludes another. We can provide both news entry > and deprecation alias. This way we let people update guix channel > version without any changes to their configurations, let them know > emacs-next-blabla will dissapear soon and give them time to react and > update their configurations accordingly without hurry. > > I'm ok proceeding without this extra step, but the deprecation > workflow seems nicer to me. You're right in that one does not exclude the other, but there are practical limitations. When emacs itself has version 29, emacs-next ought to be 30, imho. Cheers
On 2023-06-10 10:51, Liliana Marie Prikler wrote: > Am Samstag, dem 10.06.2023 um 12:20 +0400 schrieb Andrew Tropin: >> On 2023-06-10 09:46, Liliana Marie Prikler wrote: >> >> > Am Samstag, dem 10.06.2023 um 10:46 +0400 schrieb Andrew Tropin: >> > > On 2023-06-09 18:22, Liliana Marie Prikler wrote: >> > > >> > > > Hi Guix, >> > > > >> > > > it's already been four weeks since the newest Emacs pre- >> > > > release. >> > > > Time >> > > > sure flies. With that in mind, I'd like to start work in the >> > > > Emacs >> > > > team >> > > > focused on >> > > > 1. streamlining our Emacs packages >> > > > 2. improving emacs-build-system and adapting it to the new >> > > > features >> > > > of >> > > > Emacs 29 (including the almost forgotten [1]) >> > > > 3. improving our Emacs package management (i.e. making it >> > > > easier to >> > > > declare variants of emacs-* packages built with different >> > > > Emacsen) >> > > > >> > > > This series gets us started on (1), so we can do (2) and (3) >> > > > hopefully >> > > > soon. >> > > > >> > > > Cheers >> > > > >> > > > [1] https://issues.guix.gnu.org/57122 >> > > > >> > > > Liliana Marie Prikler (2): >> > > > gnu: Make emacs-next-tree-sitter the new emacs. >> > > > gnu: Construct Emacs packages from bottom up. >> > > > >> > > > gnu/local.mk | 1 - >> > > > gnu/packages/emacs.scm | 467 +++++++--- >> > > > ---- >> > > > ---- >> > > > .../patches/emacs-source-date-epoch.patch | 20 - >> > > > 3 files changed, 190 insertions(+), 298 deletions(-) >> > > > delete mode 100644 gnu/packages/patches/emacs-source-date- >> > > > epoch.patch >> > > > >> > > > >> > > > base-commit: 44bbfc24e4bcc48d0e3343cd3d83452721af8c36 >> > > >> > > Hi Liliana, >> > > >> > > the patch series looks good, thank you for working on this. Do >> > > we want to add (define-deprecated/alias) to make the transition >> > > to new emacs package names smoother? >> > Since it'll be a "world"-rebuilding change, I think a news entry >> > ought to be preferred. >> >> I don't think one excludes another. We can provide both news entry >> and deprecation alias. This way we let people update guix channel >> version without any changes to their configurations, let them know >> emacs-next-blabla will dissapear soon and give them time to react and >> update their configurations accordingly without hurry. >> >> I'm ok proceeding without this extra step, but the deprecation >> workflow seems nicer to me. > You're right in that one does not exclude the other, but there are > practical limitations. When emacs itself has version 29, emacs-next > ought to be 30, imho. Sounds reasonable, but I think it would be ok, if after updating emacs, emacs-next will be 29 for a couple of weeks with deprecation warning on top of it. The meaning of -next suffix is a convention, not a technical limitation, so it's fine to violate it for deprecation period. Overall, deprecation is not something crucial here and people know that guix breaks backward compatibility from time to time, so I think it's ok to go without it.
Hello :) 2023-06-11 09:35 andrew@trop.in: > Sounds reasonable, but I think it would be ok, if after updating > emacs, emacs-next will be 29 for a couple of weeks with > deprecation warning on top of it. The meaning of -next suffix is > a convention, not a technical limitation, so it's fine to > violate it for deprecation period. > Overall, deprecation is not something crucial here and people > know that guix breaks backward compatibility from time to time, > so I think it's ok to go without it. I think we don't need to divert deprecation/alias from its intended use. I think NEWS serves its job well enough. When having emacs-next installed and keeping it upgraded, users should be able to expect that the upcoming release of Emacs is installed, without deprecation warnings. After all, the package is not called emacs29 but emacs-next. That being said, I believe it's a good idea to define-deprecated/public-alias emacs-next-pgtk and emacs-next-pgtk-xwidgets.
On 2023-06-11 21:09, Mekeor Melire wrote: > Hello :) > > 2023-06-11 09:35 andrew@trop.in: > >> Sounds reasonable, but I think it would be ok, if after updating >> emacs, emacs-next will be 29 for a couple of weeks with >> deprecation warning on top of it. The meaning of -next suffix is >> a convention, not a technical limitation, so it's fine to >> violate it for deprecation period. > >> Overall, deprecation is not something crucial here and people >> know that guix breaks backward compatibility from time to time, >> so I think it's ok to go without it. > > I think we don't need to divert deprecation/alias from its > intended use. I think NEWS serves its job well enough. > > When having emacs-next installed and keeping it upgraded, users > should be able to expect that the upcoming release of Emacs is > installed, without deprecation warnings. After all, the package is > not called emacs29 but emacs-next. > > That being said, I believe it's a good idea to > define-deprecated/public-alias emacs-next-pgtk and > emacs-next-pgtk-xwidgets. All emacs-next* variables dissapear after this patch is applied and talking about deprecation warning: I don't see much difference between emacs-next and emacs-next-pgtk-xwidgets in this context.
Why don't we build emacs-minimal with the configure-flag --with-native-compilation=aot? If I understand correctly, this would compile all .el-files of emacs-packages to .eln-files by default. If I understand correctly, this currently only happens for emacs-packages that use (arguments (#:emacs emacs)).
Am Dienstag, dem 04.07.2023 um 07:39 +0000 schrieb Mekeor Melire: > Why don't we build emacs-minimal with the configure-flag > --with-native-compilation=aot? If I understand correctly, this > would compile all .el-files of emacs-packages to .eln-files by > default. If I understand correctly, this currently only happens > for emacs-packages that use (arguments (#:emacs emacs)). There's no point in using emacs-minimal for native-comp. It would just blow up our package sizes for no gain (any other emacs won't read the natively compiled elisp stuff due to having a different hash). If you have a use case for natively compiled emacs-minimal (e.g. for editing stuff on a server that should only carry small packages), I think there are better options (possibly emacs-no-x or using a "transformed" package). Cheers
2023-07-08 19:04 liliana.prikler@gmail.com: > Am Dienstag, dem 04.07.2023 um 07:39 +0000 schrieb Mekeor > Melire: > > Why don't we build emacs-minimal with the configure-flag > > --with-native-compilation=aot? If I understand correctly, this > > would compile all .el-files of emacs-packages to .eln-files by > > default. If I understand correctly, this currently only > > happens for emacs-packages that use (arguments (#:emacs > > emacs)). > There's no point in using emacs-minimal for native-comp. It > would just blow up our package sizes for no gain (any other > emacs won't read the natively compiled elisp stuff due to having > a different hash). If you have a use case for natively compiled > emacs-minimal (e.g. for editing stuff on a server that should > only carry small packages), I think there are better options > (possibly emacs-no-x or using a "transformed" package). Sorry. I think my suggestion was wrong and also I should submit it as a separate discussion. I'll send it to guix-devel. Stay tuned.
Am Mittwoch, dem 12.07.2023 um 18:15 +0000 schrieb Mekeor Melire: > 2023-07-08 19:04 liliana.prikler@gmail.com: > > > Am Dienstag, dem 04.07.2023 um 07:39 +0000 schrieb Mekeor > > Melire: > > > > Why don't we build emacs-minimal with the configure-flag > > > --with-native-compilation=aot? If I understand correctly, this > > > would compile all .el-files of emacs-packages to .eln-files by > > > default. If I understand correctly, this currently only > > > happens for emacs-packages that use (arguments (#:emacs > > > emacs)). > > > There's no point in using emacs-minimal for native-comp. It > > would just blow up our package sizes for no gain (any other > > emacs won't read the natively compiled elisp stuff due to having > > a different hash). If you have a use case for natively compiled > > emacs-minimal (e.g. for editing stuff on a server that should > > only carry small packages), I think there are better options > > (possibly emacs-no-x or using a "transformed" package). > > Sorry. I think my suggestion was wrong and also I should submit it as > a separate discussion. I'll send it to guix-devel. Stay tuned. Possibly unrelated, but since we have 29.0.92 on master by now I pushed this series and followed up with a merge. Cheers