* [ELPA] Package cleanup @ 2022-03-29 0:43 Jimmy Aguilar Mena 2022-03-29 16:24 ` [External] : " Drew Adams 2022-03-30 3:12 ` Richard Stallman 0 siblings, 2 replies; 17+ messages in thread From: Jimmy Aguilar Mena @ 2022-03-29 0:43 UTC (permalink / raw) To: emacs-devel Hi: Just a question. Did you finally agreed about the package obsoletion/removal procedure for ELPA? It seems there are some packages there which haven't received any update in a very long time (>5 years). Maybe there is a way to put them is a sort of obsolete/archived/unmaintained state... In order to keep them, but at least not confuse the new users, or wrongly suggest to use them. I have found some packages that doesn't even work or rely on some features that were obsoleted or removed. Best, Ergus. ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [External] : [ELPA] Package cleanup 2022-03-29 0:43 [ELPA] Package cleanup Jimmy Aguilar Mena @ 2022-03-29 16:24 ` Drew Adams 2022-03-29 21:41 ` John Yates 2022-03-30 3:12 ` Richard Stallman 1 sibling, 1 reply; 17+ messages in thread From: Drew Adams @ 2022-03-29 16:24 UTC (permalink / raw) To: Jimmy Aguilar Mena, emacs-devel@gnu.org > It seems there are some packages there which haven't received any > update in a very long time (>5 years). Maybe there is a way to > put them is a sort of obsolete/archived/unmaintained state... > In order to keep them, but at least not confuse the new users, > or wrongly suggest to use them. Some cars need to go to the mechanic every month, which makes sense for them. Some don't. Some people need to go to the doctor often; others don't. Why should Emacs assume that no change to a package means the package is not being maintained (let alone is obsolete)? > I have found some packages that doesn't even work or rely on some > features that were obsoleted or removed. That's something entirely different. Report such specific problems. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-29 16:24 ` [External] : " Drew Adams @ 2022-03-29 21:41 ` John Yates 2022-03-29 22:04 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: John Yates @ 2022-03-29 21:41 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel@gnu.org, Jimmy Aguilar Mena On Tue, Mar 29, 2022 at 12:25 PM Drew Adams <drew.adams@oracle.com> wrote: > > I have found some packages that doesn't even work or rely on some > > features that were obsoleted or removed. > > That's something entirely different. Report such > specific problems. I would like to assume that ELPA is a somewhat curated collection of packages. Perhaps not as rigorously tested and maintained as Emacs itself, but more so than some package on github that has not seen an update in 5 years. If the only virtue of being on ELPA is that I can install via package.el then that seems like rather thin gruel. Perhaps the bar for admission to ELPA is too low. Could we require automated tests that can be run regularly to confirm package health? ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [External] : [ELPA] Package cleanup 2022-03-29 21:41 ` John Yates @ 2022-03-29 22:04 ` Drew Adams 2022-03-29 23:05 ` John Yates 2022-03-30 7:31 ` Michael Albinus 2022-03-30 8:35 ` [External] : " Stefan Monnier 2022-03-31 4:27 ` Richard Stallman 2 siblings, 2 replies; 17+ messages in thread From: Drew Adams @ 2022-03-29 22:04 UTC (permalink / raw) To: John Yates; +Cc: emacs-devel@gnu.org, Jimmy Aguilar Mena > > > I have found some packages that doesn't even work or rely on some > > > features that were obsoleted or removed. > > > > That's something entirely different. Report such > > specific problems. > > I would like to assume that ELPA is a somewhat curated > collection of packages. Perhaps not as rigorously tested > and maintained as Emacs itself, but more so than some > package on github that has not seen an update in 5 years. > > If the only virtue of being on ELPA is that I can install via > package.el then that seems like rather thin gruel. > > Perhaps the bar for admission to ELPA is too low. Could > we require automated tests that can be run regularly to > confirm package health? Your last sentence makes sense. (But on whom should the requirement fall? The curator? The package contributor?) Certainly curation and periodic automated testing would be good to have. Such things could -- just as someone reporting a problem encountered could -- serve to get a package removed or fixed. I would expect that the author of a package would appreciate a report from such curation or testing, and at least in some cases might implement a fix, which presumably would be a better outcome than just removal or deprecation. I'd also expect that Emacs developers might want to know, if some change in the "core" produced unexpected problems in contributed packages. IOW, such test reporting would benefit everyone. But again, whether some package starts to result in problems where it didn't previously doesn't follow from its not having been updated for 5 years. Similarly, it doesn't at all follow that a package that's been updated a lot doesn't have problems, including doesn't introduce new problems from some recent update. Bugs and curating/testing are different from the question of update frequency or recentness. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-29 22:04 ` Drew Adams @ 2022-03-29 23:05 ` John Yates 2022-03-30 1:43 ` Drew Adams 2022-03-31 4:27 ` Richard Stallman 2022-03-30 7:31 ` Michael Albinus 1 sibling, 2 replies; 17+ messages in thread From: John Yates @ 2022-03-29 23:05 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel@gnu.org, Jimmy Aguilar Mena On Tue, Mar 29, 2022 at 6:05 PM Drew Adams <drew.adams@oracle.com> wrote: > But again, whether some package starts to result > in problems where it didn't previously doesn't > follow from its not having been updated for 5 > years. Similarly, it doesn't at all follow that > a package that's been updated a lot doesn't have > problems, including doesn't introduce new problems > from some recent update. > > Bugs and curating/testing are different from the > question of update frequency or recentness. Full agreement. Same holds true for a package on github. Lack of update is merely a vague proxy for abandoned. And, as you point out, abandonment does not imply non-functional. But if there is no mechanism to, at least, identify decay then, over time, the ratio of high quality packages to those of lesser quality drops. Not a great recipe for brand maintenance. ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [External] : [ELPA] Package cleanup 2022-03-29 23:05 ` John Yates @ 2022-03-30 1:43 ` Drew Adams 2022-03-31 4:27 ` Richard Stallman 1 sibling, 0 replies; 17+ messages in thread From: Drew Adams @ 2022-03-30 1:43 UTC (permalink / raw) To: John Yates; +Cc: Jimmy Aguilar Mena, emacs-devel@gnu.org > But if there is no mechanism to, at least, identify decay then, > over time, the ratio of high quality packages to those of lesser > quality drops. Not a great recipe for brand maintenance. 1. FWIW, I disagree that that ratio matters, except possibly for discoverability. And nowadays there are zillions of ways that people find out about this or that package - discovery of the good amidst the bad and the ugly isn't a real problem, IMO. And I don't care about maintenance of the "brand". IMO, Emacs isn't in a competitive race. That's no doubt a minority opinion. I like people to benefit from Emacs, and I evangelize it as much as then next Emaxist. But I don't feel like there's any need to sell anything, and no need to polish the sign or the brand. It shines enough, for those who care to see. 2. Emacs has users. Users report problems. Even without automatic testing, testing gets done. If no one reports a problem with some package then it's a first-order indication of few problems or few users. Neither of those cases is cause for alarm. There are "core" Emacs functions, even libraries, that few users use. Yet they might be useful, and perhaps just lie dormant, undiscovered or underappreciated. Like many people, I appreciate dabbrev. But I also appreciate the little-known functionality of the old standard library completion.el, which is a bit similar. The latter has no doc, other than its quaint Commentary. But who knows? Maybe someday it'll be put to more and better use, and maybe improved. Or maybe its features will serve as food for thought for something better, whether restarted from scratch or directly derivative. 3. It's not like there's some imperative to reduce the size of the ELPA repository, I hope. Broken code that people use will get reported, I expect. And then it'll get fixed - or not. If it remains broken, with no one trying to fix/maintain it, then deprecation or removal might be worth considering. Other than that, I don't see the point of rushing to judgment. But then, I'm more of a hoarder than a Marie Kondo... Let 100 flowers bloom. Really. There'll be plenty of time to pull out any truly poisonous weeds. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-29 23:05 ` John Yates 2022-03-30 1:43 ` Drew Adams @ 2022-03-31 4:27 ` Richard Stallman 1 sibling, 0 replies; 17+ messages in thread From: Richard Stallman @ 2022-03-31 4:27 UTC (permalink / raw) To: John Yates; +Cc: jimmy.aguilar, drew.adams, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > But if there is no mechanism to, at least, identify decay then, > over time, the ratio of high quality packages to those of lesser > quality drops. I can envision features we could add to get more feedback about ELPA packages. If a package has not been changed in N years, we could add some simple code to display a message to each user who installs the package. For instance, it could suggest sending us an emeil saying whether you find the package useful, and whether it works correctly. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ELPA] Package cleanup 2022-03-29 22:04 ` Drew Adams 2022-03-29 23:05 ` John Yates @ 2022-03-30 7:31 ` Michael Albinus 1 sibling, 0 replies; 17+ messages in thread From: Michael Albinus @ 2022-03-30 7:31 UTC (permalink / raw) To: Drew Adams; +Cc: Jimmy Aguilar Mena, emacs-devel@gnu.org, John Yates Drew Adams <drew.adams@oracle.com> writes: Hi, >> I would like to assume that ELPA is a somewhat curated >> collection of packages. Perhaps not as rigorously tested >> and maintained as Emacs itself, but more so than some >> package on github that has not seen an update in 5 years. >> >> If the only virtue of being on ELPA is that I can install via >> package.el then that seems like rather thin gruel. >> >> Perhaps the bar for admission to ELPA is too low. Could >> we require automated tests that can be run regularly to >> confirm package health? > > Your last sentence makes sense. (But on whom > should the requirement fall? The curator? The > package contributor?) It is on my longer TODO list to activate automatic tests for GNU ELPA packages on emba.gnu.org. Yes, only for "GNU" ELPA packages. Unfortunately, these days I'm the only one who works on emba, and there are many other TODO items. So I have no idea if/when this will happen. Best regards, Michael. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-29 21:41 ` John Yates 2022-03-29 22:04 ` Drew Adams @ 2022-03-30 8:35 ` Stefan Monnier 2022-03-30 14:09 ` Jimmy Aguilar Mena 2022-03-31 4:27 ` Richard Stallman 2 siblings, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2022-03-30 8:35 UTC (permalink / raw) To: John Yates; +Cc: Drew Adams, emacs-devel@gnu.org, Jimmy Aguilar Mena > I would like to assume that ELPA is a somewhat curated > collection of packages. Perhaps not as rigorously tested > and maintained as Emacs itself, but more so than some > package on github that has not seen an update in 5 years. That's not really the case, no :-( I do make sure the packages compile, and try occasionally to clean up the worst warnings, and when I make changes in Emacs I try to keep an eye on GNU ELPA packages to update them correspondingly, but I think I'm an exception in this regard. > If the only virtue of being on ELPA is that I can install via > package.el then that seems like rather thin gruel. The other is that there's a plan to include some of those packages into the standard Emacs tarball. > Perhaps the bar for admission to ELPA is too low. The main bar is for the package to be useful, harmless, and to have copyright. I don't see a strong reason to make it much higher. > Could we require automated tests that can be run regularly to confirm > package health? That would be great. But before requiring them, we need to setup a way to run the already existing tests. Any help in this regard would be most welcome. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-30 8:35 ` [External] : " Stefan Monnier @ 2022-03-30 14:09 ` Jimmy Aguilar Mena 2022-03-30 21:23 ` Stefan Monnier 0 siblings, 1 reply; 17+ messages in thread From: Jimmy Aguilar Mena @ 2022-03-30 14:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel@gnu.org, Drew Adams, John Yates On Wed, Mar 30, 2022 at 04:35:56AM -0400, Stefan Monnier wrote: >> I would like to assume that ELPA is a somewhat curated >> collection of packages. Perhaps not as rigorously tested >> and maintained as Emacs itself, but more so than some >> package on github that has not seen an update in 5 years. > >That's not really the case, no :-( >I do make sure the packages compile, and try occasionally to clean up >the worst warnings, and when I make changes in Emacs I try to keep an >eye on GNU ELPA packages to update them correspondingly, but I think I'm >an exception in this regard. > >> If the only virtue of being on ELPA is that I can install via >> package.el then that seems like rather thin gruel. > >The other is that there's a plan to include some of those packages into >the standard Emacs tarball. > >> Perhaps the bar for admission to ELPA is too low. > >The main bar is for the package to be useful, harmless, and to have >copyright. I don't see a strong reason to make it much higher. > >> Could we require automated tests that can be run regularly to confirm >> package health? > >That would be great. But before requiring them, we need to setup a way >to run the already existing tests. Any help in this regard would be >most welcome. > > In this regard. There are some packages which main target is the interaction, produce tarball, help menus etc... basically interactive and dynamic work. We can test the internal functions but not the external interaction and that's insufficient. There is a package (not very active, but still functional BTW) Cask+Ecukes... But the setup is not easy... Do we have something or is there a way/plan to handle such test with internal functionalities? Otherwise it may be pretty complex to demand/implement tests for those packages. > Stefan > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-30 14:09 ` Jimmy Aguilar Mena @ 2022-03-30 21:23 ` Stefan Monnier 0 siblings, 0 replies; 17+ messages in thread From: Stefan Monnier @ 2022-03-30 21:23 UTC (permalink / raw) To: Jimmy Aguilar Mena; +Cc: John Yates, Drew Adams, emacs-devel@gnu.org > There is a package (not very active, but still functional BTW) > Cask+Ecukes... But the setup is not easy... Do we have something or is > there a way/plan to handle such test with internal functionalities? > Otherwise it may be pretty complex to demand/implement tests for those > packages. I think we're still fairly far from those problems, sadly. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [External] : [ELPA] Package cleanup 2022-03-29 21:41 ` John Yates 2022-03-29 22:04 ` Drew Adams 2022-03-30 8:35 ` [External] : " Stefan Monnier @ 2022-03-31 4:27 ` Richard Stallman 2 siblings, 0 replies; 17+ messages in thread From: Richard Stallman @ 2022-03-31 4:27 UTC (permalink / raw) To: John Yates; +Cc: jimmy.aguilar, drew.adams, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > If the only virtue of being on ELPA is that I can install via > package.el then that seems like rather thin gruel. The main virtue of ELPA is that we make sure that the package follows our ethical criteria, so that it is acceptable for us to recommend it to people. A second virtue is that we can move the code into core Emacs. A secondary benefit is that the Emacs developers can fix problems in these packages, when we know of a specific problem. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ELPA] Package cleanup 2022-03-29 0:43 [ELPA] Package cleanup Jimmy Aguilar Mena 2022-03-29 16:24 ` [External] : " Drew Adams @ 2022-03-30 3:12 ` Richard Stallman 2022-03-30 3:44 ` Po Lu 2022-03-30 4:56 ` Jimmy Aguilar Mena 1 sibling, 2 replies; 17+ messages in thread From: Richard Stallman @ 2022-03-30 3:12 UTC (permalink / raw) To: Jimmy Aguilar Mena; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Thanks for investigating the situation with unmaintained packages. What you've found will help us think about what to do. > Just a question. Did you finally agreed about the package > obsoletion/removal procedure for ELPA? I'd like to see a proposal. > It seems there are some packages there which haven't received any update > in a very long time (>5 years). That suggests they might have bugs and need maintenance, but it does not imply they are useless or obsolete. They might be obsolete, or not. There are many questions we'd want to check to decide what to do with each package. > I have found some packages that doesn't even work or rely on some > features that were obsoleted or removed. In those cases, we clearly don't want to leave the package there in its current form. But what change should we make? We could delete it. We could look for people to update it. Either one might be better, depending on more details. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ELPA] Package cleanup 2022-03-30 3:12 ` Richard Stallman @ 2022-03-30 3:44 ` Po Lu 2022-03-30 7:56 ` João Távora 2022-03-30 4:56 ` Jimmy Aguilar Mena 1 sibling, 1 reply; 17+ messages in thread From: Po Lu @ 2022-03-30 3:44 UTC (permalink / raw) To: Richard Stallman; +Cc: Jimmy Aguilar Mena, emacs-devel Richard Stallman <rms@gnu.org> writes: > That suggests they might have bugs and need maintenance, but it does > not imply they are useless or obsolete. They might be obsolete, or > not. Indeed. There are some very useful packages that aren't maintained anymore (i.e. yasnippet, which hasn't seen changes since 2 years, and has no sign of that changing any time soon.) > > I have found some packages that doesn't even work or rely on some > > features that were obsoleted or removed. I would rather we take a different approach: don't change anything that will break packages on ELPA. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ELPA] Package cleanup 2022-03-30 3:44 ` Po Lu @ 2022-03-30 7:56 ` João Távora 0 siblings, 0 replies; 17+ messages in thread From: João Távora @ 2022-03-30 7:56 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel, Richard Stallman, Jimmy Aguilar Mena [-- Attachment #1: Type: text/plain, Size: 786 bytes --] On Wed, Mar 30, 2022, 04:44 Po Lu <luangruo@yahoo.com> wrote: > Richard Stallman <rms@gnu.org> writes: > > > That suggests they might have bugs and need maintenance, but it does > > not imply they are useless or obsolete. They might be obsolete, or > > not. > > Indeed. There are some very useful packages that aren't maintained > anymore (i.e. yasnippet, which hasn't seen changes since 2 years, and > has no sign of that changing any time soon.) > Speaking of which, I'm looking for a maintainer for yasnippet. Noam did an amazing job for many years, but has moved on. If anyone is interested, let me know. A first task would be too sort through the rubble of many unopened issues and see which ones contain valuable/fixable bugs or suggestions. João > [-- Attachment #2: Type: text/html, Size: 1673 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ELPA] Package cleanup 2022-03-30 3:12 ` Richard Stallman 2022-03-30 3:44 ` Po Lu @ 2022-03-30 4:56 ` Jimmy Aguilar Mena 2022-04-01 4:07 ` Richard Stallman 1 sibling, 1 reply; 17+ messages in thread From: Jimmy Aguilar Mena @ 2022-03-30 4:56 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel On Tue, Mar 29, 2022 at 11:12:06PM -0400, Richard Stallman wrote: >[[[ To any NSA and FBI agents reading my email: please consider ]]] >[[[ whether defending the US Constitution against all enemies, ]]] >[[[ foreign or domestic, requires you to follow Snowden's example. ]]] > >Thanks for investigating the situation with unmaintained packages. >What you've found will help us think about what to do. > > > Just a question. Did you finally agreed about the package > > obsoletion/removal procedure for ELPA? > >I'd like to see a proposal. > I have seen some discussions about this topic before. See bellow. > > It seems there are some packages there which haven't received any update > > in a very long time (>5 years). > >That suggests they might have bugs and need maintenance, >but it does not imply they are useless or obsolete. >They might be obsolete, or not. > >There are many questions we'd want to check >to decide what to do with each package. > But if they don't receive any update for years, and the bug reports accumulate (on github too) then it quite possible that either the users and the maintainers are not interested on it anymore. > > I have found some packages that doesn't even work or rely on some > > features that were obsoleted or removed. > >In those cases, we clearly don't want to leave the package there >in its current form. But what change should we make? > >We could delete it. We could look for people to update it. >Either one might be better, depending on more details. > We could archive it in a different repository in case someone desires to adopt, check or fork in the future. Or we could also flag it somehow to say to the package-list that it is orphan, obsolete, unmaintained... That's the approach in the AUR repository for arch Linux and it is useful; because the users get a warning during the updates about abandon, orphan or outdated packages. Then if a package is in that state for too long it may be archived, so it can be accessed, but is not offered in the package list as a good alternative. > >-- >Dr Richard Stallman (https://stallman.org) >Chief GNUisance of the GNU Project (https://gnu.org) >Founder, Free Software Foundation (https://fsf.org) >Internet Hall-of-Famer (https://internethalloffame.org) > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ELPA] Package cleanup 2022-03-30 4:56 ` Jimmy Aguilar Mena @ 2022-04-01 4:07 ` Richard Stallman 0 siblings, 0 replies; 17+ messages in thread From: Richard Stallman @ 2022-04-01 4:07 UTC (permalink / raw) To: Jimmy Aguilar Mena; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > >There are many questions we'd want to check > >to decide what to do with each package. > > > But if they don't receive any update for years, That's the case that was brought up. and the bug reports > accumulate That wasn't mentioned before. It makes a difference. Depending on what those bugs do, we might delete (or obsolete) the package -- but not automatically and rigidly. Another option would be to ask users to tell us what they think of the package. (on github too) How does that make a difference? We don't use Github. We won't ask anyone to make an account there, since doing so requires running their nonfree software. Supposing we find someone to fix bugs in the package, we can't fix them on github. We could change the GNU ELPA version to direct people clearly to report bugs to us, so we can fix them. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-04-01 4:07 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-03-29 0:43 [ELPA] Package cleanup Jimmy Aguilar Mena 2022-03-29 16:24 ` [External] : " Drew Adams 2022-03-29 21:41 ` John Yates 2022-03-29 22:04 ` Drew Adams 2022-03-29 23:05 ` John Yates 2022-03-30 1:43 ` Drew Adams 2022-03-31 4:27 ` Richard Stallman 2022-03-30 7:31 ` Michael Albinus 2022-03-30 8:35 ` [External] : " Stefan Monnier 2022-03-30 14:09 ` Jimmy Aguilar Mena 2022-03-30 21:23 ` Stefan Monnier 2022-03-31 4:27 ` Richard Stallman 2022-03-30 3:12 ` Richard Stallman 2022-03-30 3:44 ` Po Lu 2022-03-30 7:56 ` João Távora 2022-03-30 4:56 ` Jimmy Aguilar Mena 2022-04-01 4:07 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.