* What to do about unmaintained ELPA packages @ 2022-05-29 21:34 Philip Kaludercic 2022-05-29 21:41 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Philip Kaludercic @ 2022-05-29 21:34 UTC (permalink / raw) To: emacs-devel Hi, There are some popular packages on GNU ELPA (and I expect NonGNU ELPA) that are practically unmaintained. One example would be Yasnippet that has been gathering issues and pull requests on GitHub, mostly without any comments whatsoever. For example, see https://github.com/joaotavora/yasnippet/issues. Does anyone know of any other packages of this kind? I'd like to ask, if there some point at which should one should go from regarding packages like these from "de facto unmaintained" to "actually abandoned"? Perhaps if there was no real activity for over a year, despite constant contributions? Would it make sense to call for anyone new to take over maintaining the package? Or depending on how long the package has been unmaintained, how popular the package is, how much effort it would take to apply the changes one could modify the package in elpa.git/nongnu.git and inform the maintainers that if they decide to start working on the package again, that there are downstream changes that they should look at. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-29 21:34 What to do about unmaintained ELPA packages Philip Kaludercic @ 2022-05-29 21:41 ` Stefan Monnier 2022-05-29 21:54 ` Dmitry Gutov 2022-05-30 22:53 ` Richard Stallman 2 siblings, 0 replies; 18+ messages in thread From: Stefan Monnier @ 2022-05-29 21:41 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel Philip Kaludercic [2022-05-29 23:34:14] wrote: > I'd like to ask, if there some point at which should one should go from > regarding packages like these from "de facto unmaintained" to "actually > abandoned"? Perhaps if there was no real activity for over a year, > despite constant contributions? Would it make sense to call for anyone > new to take over maintaining the package? Of course, especially for popular packages. > Or depending on how long the package has been unmaintained, how > popular the package is, how much effort it would take to apply the > changes one could modify the package in elpa.git/nongnu.git and inform > the maintainers that if they decide to start working on the package > again, that there are downstream changes that they should look at. Yes, we can use `:url nil` to indicate that `elpa.git` is considered as "the upstream". Of course, it's better if the current upstream can be modified to point back to us as the upstream so as to try avoiding accidental divergence in the future. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-29 21:34 What to do about unmaintained ELPA packages Philip Kaludercic 2022-05-29 21:41 ` Stefan Monnier @ 2022-05-29 21:54 ` Dmitry Gutov 2022-05-29 23:08 ` Tim Cross 2022-05-30 6:58 ` Philip Kaludercic 2022-05-30 22:53 ` Richard Stallman 2 siblings, 2 replies; 18+ messages in thread From: Dmitry Gutov @ 2022-05-29 21:54 UTC (permalink / raw) To: Philip Kaludercic, emacs-devel On 30.05.2022 00:34, Philip Kaludercic wrote: > There are some popular packages on GNU ELPA (and I expect NonGNU ELPA) > that are practically unmaintained. One example would be Yasnippet that > has been gathering issues and pull requests on GitHub, mostly without > any comments whatsoever. For example, see > https://github.com/joaotavora/yasnippet/issues. Does anyone know of any > other packages of this kind? Talking about yasnippet in particular, it more in the "stable" rather than "bitrotten" category, so I wouldn't worry about it too much. Or definitely not resort to measures like removing the reference to the upstream. > I'd like to ask, if there some point at which should one should go from > regarding packages like these from "de facto unmaintained" to "actually > abandoned"? Perhaps if there was no real activity for over a year, > despite constant contributions? Would it make sense to call for anyone > new to take over maintaining the package? Or depending on how long the > package has been unmaintained, how popular the package is, how much > effort it would take to apply the changes one could modify the package > in elpa.git/nongnu.git and inform the maintainers that if they decide to > start working on the package again, that there are downstream changes > that they should look at. Personally, carrying over the development on ELPA would seem counter-productive. Both due to the reduced potential community of contributors and reporters, and because of the wealth of reports, discussions and docs that reside at the currently dormant upstream. Kinda passive-aggressive, too. I think the best step right now would be to try to contact Noah and ask to share commit access. And if not Noah, then Joao -- he's definitely still around. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-29 21:54 ` Dmitry Gutov @ 2022-05-29 23:08 ` Tim Cross 2022-05-30 11:14 ` Akib Azmain Turja 2022-05-30 6:58 ` Philip Kaludercic 1 sibling, 1 reply; 18+ messages in thread From: Tim Cross @ 2022-05-29 23:08 UTC (permalink / raw) To: emacs-devel Dmitry Gutov <dgutov@yandex.ru> writes: > On 30.05.2022 00:34, Philip Kaludercic wrote: >> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA) >> that are practically unmaintained. One example would be Yasnippet that >> has been gathering issues and pull requests on GitHub, mostly without >> any comments whatsoever. For example, see >> https://github.com/joaotavora/yasnippet/issues. Does anyone know of any >> other packages of this kind? > > Talking about yasnippet in particular, it more in the "stable" rather than > "bitrotten" category, so I wouldn't worry about it too much. > > Or definitely not resort to measures like removing the reference to the > upstream. > >> I'd like to ask, if there some point at which should one should go from >> regarding packages like these from "de facto unmaintained" to "actually >> abandoned"? Perhaps if there was no real activity for over a year, >> despite constant contributions? Would it make sense to call for anyone >> new to take over maintaining the package? Or depending on how long the >> package has been unmaintained, how popular the package is, how much >> effort it would take to apply the changes one could modify the package >> in elpa.git/nongnu.git and inform the maintainers that if they decide to >> start working on the package again, that there are downstream changes >> that they should look at. > > Personally, carrying over the development on ELPA would seem counter-productive. > Both due to the reduced potential community of contributors and reporters, and > because of the wealth of reports, discussions and docs that reside at the > currently dormant upstream. Kinda passive-aggressive, too. > > I think the best step right now would be to try to contact Noah and ask to share > commit access. And if not Noah, then Joao -- he's definitely still around. I would agree. First step is to try contacting the repository owner. I notice in the case of yasnippets, they are active in other projects, so there may be a good reason none of the issues or PRs are getting action in that repo. I'm not sure there is a 'one size fits all' answer here. We probably need to look at each case individually. I do think both ELPA and non-GNU ELPA would likely benefit from some statistic showing number of weekly/monthly downloads and/or possibly some heuristic quality metric i.e. number of open issues, whether the package has a test suite, number of compiler warnings, days since last update etc. While none of these are likely sufficient metrics on their own, perhaps a combination could be useful as an indicator. One unfortunate tendency in the current climate is to consider anything which has not had an update in some time to be abandoned. However, it could simply be it has reached a stable point of maturity where fewer updates are necessary or critical enough. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-29 23:08 ` Tim Cross @ 2022-05-30 11:14 ` Akib Azmain Turja 0 siblings, 0 replies; 18+ messages in thread From: Akib Azmain Turja @ 2022-05-30 11:14 UTC (permalink / raw) To: Tim Cross, emacs-devel [-- Attachment #1: Type: text/plain, Size: 4128 bytes --] Tim Cross <theophilusx@gmail.com> writes: > Dmitry Gutov <dgutov@yandex.ru> writes: > >> On 30.05.2022 00:34, Philip Kaludercic wrote: >>> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA) >>> that are practically unmaintained. One example would be Yasnippet that >>> has been gathering issues and pull requests on GitHub, mostly without >>> any comments whatsoever. For example, see >>> https://github.com/joaotavora/yasnippet/issues. Does anyone know of any >>> other packages of this kind? >> >> Talking about yasnippet in particular, it more in the "stable" rather than >> "bitrotten" category, so I wouldn't worry about it too much. >> >> Or definitely not resort to measures like removing the reference to the >> upstream. >> >>> I'd like to ask, if there some point at which should one should go from >>> regarding packages like these from "de facto unmaintained" to "actually >>> abandoned"? Perhaps if there was no real activity for over a year, >>> despite constant contributions? Would it make sense to call for anyone >>> new to take over maintaining the package? Or depending on how long the >>> package has been unmaintained, how popular the package is, how much >>> effort it would take to apply the changes one could modify the package >>> in elpa.git/nongnu.git and inform the maintainers that if they decide to >>> start working on the package again, that there are downstream changes >>> that they should look at. >> >> Personally, carrying over the development on ELPA would seem counter-productive. >> Both due to the reduced potential community of contributors and reporters, and >> because of the wealth of reports, discussions and docs that reside at the >> currently dormant upstream. Kinda passive-aggressive, too. >> >> I think the best step right now would be to try to contact Noah and ask to share >> commit access. And if not Noah, then Joao -- he's definitely still around. > > > I would agree. First step is to try contacting the repository owner. I > notice in the case of yasnippets, they are active in other projects, so > there may be a good reason none of the issues or PRs are getting action > in that repo. I agree. If the maintainer doesn't respond then we can think about taking any other step. > > I'm not sure there is a 'one size fits all' answer here. We probably > need to look at each case individually. That right, because each case differs and has something unique. > > I do think both ELPA and non-GNU ELPA would likely benefit from some > statistic showing number of weekly/monthly downloads and/or possibly > some heuristic quality metric i.e. number of open issues, whether the > package has a test suite, number of compiler warnings, days since last > update etc. While none of these are likely sufficient metrics on their > own, perhaps a combination could be useful as an indicator. Yeah, these will help users to make a better choice. Although compiler warnings count and time since last update can be easily calculated, how can we check a package has a test suite? And how can we figure out the number of open issues (or whatever)? That would need to use many APIs like GitHub API, GitLab API, Gitea API. I would also suggest showing the license of a package (for NonGNU only, as all ELPA packages are GPL). By the way, is it OK to use Expat (or MIT) license for elisp packages? > > One unfortunate tendency in the current climate is to consider anything > which has not had an update in some time to be abandoned. However, it > could simply be it has reached a stable point of maturity where fewer > updates are necessary or critical enough. > That's exactly me! I start writing package, and when I have implemented everything I want, I just put it aside, until I think it needs attention (either because I or someone else found a bug or because I would like to add another feature). -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-29 21:54 ` Dmitry Gutov 2022-05-29 23:08 ` Tim Cross @ 2022-05-30 6:58 ` Philip Kaludercic 2022-05-30 13:45 ` Lars Ingebrigtsen 2022-05-30 14:46 ` João Távora 1 sibling, 2 replies; 18+ messages in thread From: Philip Kaludercic @ 2022-05-30 6:58 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel, Noam Postavsky, João Távora Dmitry Gutov <dgutov@yandex.ru> writes: > On 30.05.2022 00:34, Philip Kaludercic wrote: >> There are some popular packages on GNU ELPA (and I expect NonGNU ELPA) >> that are practically unmaintained. One example would be Yasnippet that >> has been gathering issues and pull requests on GitHub, mostly without >> any comments whatsoever. For example, see >> https://github.com/joaotavora/yasnippet/issues. Does anyone know of any >> other packages of this kind? > > Talking about yasnippet in particular, it more in the "stable" rather > than "bitrotten" category, so I wouldn't worry about it too much. > > Or definitely not resort to measures like removing the reference to > the upstream. Considering the number of issues that have been gathering in the above mentioned issue tracker, I find it increasingly difficult to say it is "stable". It is far from being "bitrotten", but there is plenty of space between the two. >> I'd like to ask, if there some point at which should one should go from >> regarding packages like these from "de facto unmaintained" to "actually >> abandoned"? Perhaps if there was no real activity for over a year, >> despite constant contributions? Would it make sense to call for anyone >> new to take over maintaining the package? Or depending on how long the >> package has been unmaintained, how popular the package is, how much >> effort it would take to apply the changes one could modify the package >> in elpa.git/nongnu.git and inform the maintainers that if they decide to >> start working on the package again, that there are downstream changes >> that they should look at. > > Personally, carrying over the development on ELPA would seem > counter-productive. Both due to the reduced potential community of > contributors and reporters, and because of the wealth of reports, > discussions and docs that reside at the currently dormant > upstream. Kinda passive-aggressive, too. That would only be one option, perhaps the most drastic because it burdens the ELPA maintainers and contributors the most. An alternative would be to announce a package is regarded as unmaintained and that we are looking for a new maintainer to revive the package by start a fork. My intention with this thread is to formalise some kind of workflow for situations like these, so that people know what they can do if a ELPA package stagnates. > I think the best step right now would be to try to contact Noah and > ask to share commit access. And if not Noah, then Joao -- he's > definitely still around. I have CC'ed them in this message, in case they have anything to say on this specific case. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-30 6:58 ` Philip Kaludercic @ 2022-05-30 13:45 ` Lars Ingebrigtsen 2022-05-30 14:46 ` João Távora 1 sibling, 0 replies; 18+ messages in thread From: Lars Ingebrigtsen @ 2022-05-30 13:45 UTC (permalink / raw) To: Philip Kaludercic Cc: Dmitry Gutov, emacs-devel, Noam Postavsky, João Távora Philip Kaludercic <philipk@posteo.net> writes: > Considering the number of issues that have been gathering in the above > mentioned issue tracker, I find it increasingly difficult to say it is > "stable". Seems like a bit more than 10% of issues opened are still open? That's not a bad track record -- it's about where we are in the Emacs bug tracker. 😰 -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-30 6:58 ` Philip Kaludercic 2022-05-30 13:45 ` Lars Ingebrigtsen @ 2022-05-30 14:46 ` João Távora 2022-05-30 22:51 ` Ergus 2022-05-31 16:42 ` Philip Kaludercic 1 sibling, 2 replies; 18+ messages in thread From: João Távora @ 2022-05-30 14:46 UTC (permalink / raw) To: Philip Kaludercic, Stefan Monnier Cc: Dmitry Gutov, emacs-devel, Noam Postavsky [-- Attachment #1: Type: text/plain, Size: 3599 bytes --] On Mon, May 30, 2022 at 7:58 AM Philip Kaludercic <philipk@posteo.net> wrote: > Dmitry Gutov <dgutov@yandex.ru> writes: > > Considering the number of issues that have been gathering in the above > mentioned issue tracker, I find it increasingly difficult to say it is > "stable". It is far from being "bitrotten", but there is plenty of > space between the two. Yes, I agree with this characterization. Yasnippet's "display engine", though highly tested (automatically and manually) is complex. I recall some bugs when interacting with other packages that make heavy use of indenting tricks and overlays. While these are the minority (as far as I know), Org is one such package and it's pretty prominent. On the other hand, last time browsed the issue tracker, there were very many specialized feature requests that wouldn't (IMO) make sense in the Yasnippet engine. Integrating them would be hard and awkward and it would turn it into something else entirely. So, in that sense, Yasnippet is stable. One interesting area of Yasnippet development is in its 'snippet-engine' branch, in a file called simply snippet.e'. It is the product of an exchange of ideas between me and Stefan Monnier some years ago. It's a bare-bones version of Yasnippet's snippet expansion and navigation engine, more efficient and Lisp-friendly. The goal was to replace Yasnippet's engine in the master branch with it. Alas, motivation fizzled and work stalled. But it was pretty spiffy and almost done. As I recall, snippet definitions were simply Elisp forms, written in a nice DSL which was not particularly obtrusive. snippet.el is more or less yasnippet.el done right. snippet.el could be useful in light of a relatively recent development: LSP. If I've ever actually used Yasnippet recently, it's been through LSP/eglot, completely transparently. When used though LSP, a lot of Yasnippet's legacy, bug-prone, wish-I-was-Textmate, dont-really-know-elisp code isn't being exercised at all. I've personally abandoned the idea of maintaining personal or shared language-specific snippet collections via many little text files. I would guess others have, too. LSP servers simply maintain that collection for you, as they do so many other things, and that's agreeable to me. It's true that LSP still uses the Textmate snippet description language, and snippet.el accepts Lisp forms (as it should). But translating from the former to the latter isn't very hard (in fact someone over at the repo did it some years ago). To summarize, I don't have any particularly strong opinion on what should be done with Yasnippet. In fact, I don't even know what problem Philip is trying to solve! Is it just the general idea of abandonment of the fact that people's issue reports go unanswered? If the latter, then I think archiving the repo would make sense. No more issue reports would come in and one could advertise the Emacs bug tracker. Would that improve things? I do think that it's important to preserve the documentation though, as many people seem to refer to it still. Or maybe transfer it to a more GNU ELPAish location/format. Who knows if the description above motivates someone to pick up 'snippet.el', finalize it, and make a new GNU ELPA package? Or maybe it motivates someone to pick up the maintenance of the existing Yasnippet. So let me and Noam know if you wish me to do something admin with the repository. While Noam is the official maintainer, I think I still retain those rights. João [-- Attachment #2: Type: text/html, Size: 4820 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-30 14:46 ` João Távora @ 2022-05-30 22:51 ` Ergus 2022-05-30 23:04 ` João Távora 2022-05-31 16:42 ` Philip Kaludercic 1 sibling, 1 reply; 18+ messages in thread From: Ergus @ 2022-05-30 22:51 UTC (permalink / raw) To: João Távora Cc: Philip Kaludercic, Stefan Monnier, Dmitry Gutov, emacs-devel, Noam Postavsky On Mon, May 30, 2022 at 03:46:11PM +0100, Jo�o T�vora wrote: >On Mon, May 30, 2022 at 7:58 AM Philip Kaludercic <philipk@posteo.net> >wrote: > >> Dmitry Gutov <dgutov@yandex.ru> writes: >> >> Considering the number of issues that have been gathering in the above >> mentioned issue tracker, I find it increasingly difficult to say it is >> "stable". It is far from being "bitrotten", but there is plenty of >> space between the two. > > >Yes, I agree with this characterization. Yasnippet's "display engine", >though >highly tested (automatically and manually) is complex. I recall some bugs >when interacting with other packages that make heavy use of indenting tricks >and overlays. While these are the minority (as far as I know), Org is one >such package and it's pretty prominent. > >On the other hand, last time browsed the issue tracker, there were very >many >specialized feature requests that wouldn't (IMO) make sense in the Yasnippet >engine. Integrating them would be hard and awkward and it would turn it >into >something else entirely. So, in that sense, Yasnippet is stable. > >One interesting area of Yasnippet development is in its 'snippet-engine' >branch, in a file called simply snippet.e'. It is the product of an >exchange of >ideas between me and Stefan Monnier some years ago. It's a bare-bones >version >of Yasnippet's snippet expansion and navigation engine, more efficient and >Lisp-friendly. The goal was to replace Yasnippet's engine in the master >branch >with it. > >Alas, motivation fizzled and work stalled. But it was pretty spiffy and >almost >done. As I recall, snippet definitions were simply Elisp forms, written in >a >nice DSL which was not particularly obtrusive. snippet.el is more or less >yasnippet.el done right. > >snippet.el could be useful in light of a relatively recent development: >LSP. > >If I've ever actually used Yasnippet recently, it's been through LSP/eglot, >completely transparently. When used though LSP, a lot of Yasnippet's >legacy, >bug-prone, wish-I-was-Textmate, dont-really-know-elisp code isn't being >exercised at all. > >I've personally abandoned the idea of maintaining personal or shared >language-specific snippet collections via many little text files. I would >guess >others have, too. LSP servers simply maintain that collection for you, as >they do so many other things, and that's agreeable to me. > >It's true that LSP still uses the Textmate snippet description language, and >snippet.el accepts Lisp forms (as it should). But translating from the >former >to the latter isn't very hard (in fact someone over at the repo did it some >years >ago). > >To summarize, I don't have any particularly strong opinion on what should >be done >with Yasnippet. In fact, I don't even know what problem Philip is trying to >solve! >Is it just the general idea of abandonment of the fact that people's issue >reports >go unanswered? If the latter, then I think archiving the repo would make >sense. No >more issue reports would come in and one could advertise the Emacs bug >tracker. >Would that improve things? > >I do think that it's important to preserve the documentation though, as >many people >seem to refer to it still. Or maybe transfer it to a more GNU ELPAish >location/format. > >Who knows if the description above motivates someone to pick up >'snippet.el', >finalize it, and make a new GNU ELPA package? Or maybe it motivates someone >to pick up the maintenance of the existing Yasnippet. > >So let me and Noam know if you wish me to do something admin with the >repository. >While Noam is the official maintainer, I think I still retain those rights. > >Jo�o Hi Joao: So far depending too much on lsp has some issues I am not sure they are all already solved in order to make yasnippet substitute its backends: 1) LSP+Tramp works pretty bad; specially with relatively big/medium projects it becaumes extremely slow and gives the error message of reentrant calls... also it depends on having LSP on the remote host. 2) It is difficult to use LSP for quick tests.. suppose it wants to test a simple program... usually I open /tmp/main.c and start writing... with LSP Eglot it needs to know how to compile it to give completions like inserting main(int argc...). flymake depends on a Makefile, LSP of a database... 3) Bear is also problematic as it now adds a lost of extra dependencies, so projects with autotools has a problem to create the build database... 4) When build is out of source (something that is becoming more common in autotools and cmake also prefers) the build and database creation and update requires constant extra effort, something most of the IDE do for the user. 5) Do you have documented how to make eglot integration with yasnippet? Because I can't make it work. If you have ways to go around these issues I will be very grated if you share them, so I could try eglot+yasnippet for daily use. Thanks in advance Ergus. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-30 22:51 ` Ergus @ 2022-05-30 23:04 ` João Távora 0 siblings, 0 replies; 18+ messages in thread From: João Távora @ 2022-05-30 23:04 UTC (permalink / raw) To: Ergus Cc: Philip Kaludercic, Stefan Monnier, Dmitry Gutov, emacs-devel, Noam Postavsky [-- Attachment #1: Type: text/plain, Size: 6644 bytes --] Ergus, I think you're veering a little bit from the issue here, but the goal is not to throw anything away: I was just expounding my vision of a new snippet system with less code, less bugs, and less friction that is driven by LSP servers as more reliable owners and maintainers of snippet collections. For 2. I open one-shot ~/tmp/test.cpp files and type M-x eglot and get decent results all the time. Also bear works nicely for me. But mostly the C++ projects I've been doing lately use Cmake which creates a compile-commands.json file anyway. For number 5, just have yasnippet installed, simple as that: Eglo should pick it up by default. Any other problems, please start a conversation in Eglot's "discussions" panel, or, if you have complete information on how to recreate a given situation problem, create an issue. Anyway, it sounds like you are describing LSP/Eglot shortcomings. Sure, there are a lot of them, but trying to stop it is like trying to stop the tide, at least I feel it is. And it's been working fine for me (actually I've only very recently actually started using it, after having created maintained Eglot for it for 4+ years). João On Mon, May 30, 2022 at 11:51 PM Ergus <spacibba@aol.com> wrote: > On Mon, May 30, 2022 at 03:46:11PM +0100, Jo�o T�vora wrote: > >On Mon, May 30, 2022 at 7:58 AM Philip Kaludercic <philipk@posteo.net> > >wrote: > > > >> Dmitry Gutov <dgutov@yandex.ru> writes: > >> > >> Considering the number of issues that have been gathering in the above > >> mentioned issue tracker, I find it increasingly difficult to say it is > >> "stable". It is far from being "bitrotten", but there is plenty of > >> space between the two. > > > > > >Yes, I agree with this characterization. Yasnippet's "display engine", > >though > >highly tested (automatically and manually) is complex. I recall some bugs > >when interacting with other packages that make heavy use of indenting > tricks > >and overlays. While these are the minority (as far as I know), Org is one > >such package and it's pretty prominent. > > > >On the other hand, last time browsed the issue tracker, there were very > >many > >specialized feature requests that wouldn't (IMO) make sense in the > Yasnippet > >engine. Integrating them would be hard and awkward and it would turn it > >into > >something else entirely. So, in that sense, Yasnippet is stable. > > > >One interesting area of Yasnippet development is in its 'snippet-engine' > >branch, in a file called simply snippet.e'. It is the product of an > >exchange of > >ideas between me and Stefan Monnier some years ago. It's a bare-bones > >version > >of Yasnippet's snippet expansion and navigation engine, more efficient and > >Lisp-friendly. The goal was to replace Yasnippet's engine in the master > >branch > >with it. > > > >Alas, motivation fizzled and work stalled. But it was pretty spiffy and > >almost > >done. As I recall, snippet definitions were simply Elisp forms, written > in > >a > >nice DSL which was not particularly obtrusive. snippet.el is more or less > >yasnippet.el done right. > > > >snippet.el could be useful in light of a relatively recent development: > >LSP. > > > >If I've ever actually used Yasnippet recently, it's been through > LSP/eglot, > >completely transparently. When used though LSP, a lot of Yasnippet's > >legacy, > >bug-prone, wish-I-was-Textmate, dont-really-know-elisp code isn't being > >exercised at all. > > > >I've personally abandoned the idea of maintaining personal or shared > >language-specific snippet collections via many little text files. I would > >guess > >others have, too. LSP servers simply maintain that collection for you, as > >they do so many other things, and that's agreeable to me. > > > >It's true that LSP still uses the Textmate snippet description language, > and > >snippet.el accepts Lisp forms (as it should). But translating from the > >former > >to the latter isn't very hard (in fact someone over at the repo did it > some > >years > >ago). > > > >To summarize, I don't have any particularly strong opinion on what should > >be done > >with Yasnippet. In fact, I don't even know what problem Philip is trying > to > >solve! > >Is it just the general idea of abandonment of the fact that people's issue > >reports > >go unanswered? If the latter, then I think archiving the repo would make > >sense. No > >more issue reports would come in and one could advertise the Emacs bug > >tracker. > >Would that improve things? > > > >I do think that it's important to preserve the documentation though, as > >many people > >seem to refer to it still. Or maybe transfer it to a more GNU ELPAish > >location/format. > > > >Who knows if the description above motivates someone to pick up > >'snippet.el', > >finalize it, and make a new GNU ELPA package? Or maybe it motivates > someone > >to pick up the maintenance of the existing Yasnippet. > > > >So let me and Noam know if you wish me to do something admin with the > >repository. > >While Noam is the official maintainer, I think I still retain those > rights. > > > >Jo�o > > > Hi Joao: > > So far depending too much on lsp has some issues I am not sure they are > all already solved in order to make yasnippet substitute its backends: > > 1) LSP+Tramp works pretty bad; specially with relatively big/medium > projects it becaumes extremely slow and gives the error message of > reentrant calls... also it depends on having LSP on the remote host. > > 2) It is difficult to use LSP for quick tests.. suppose it wants to test > a simple program... usually I open /tmp/main.c and start writing... with > LSP Eglot it needs to know how to compile it to give completions like > inserting main(int argc...). flymake depends on a Makefile, LSP of a > database... > > 3) Bear is also problematic as it now adds a lost of extra dependencies, > so projects with autotools has a problem to create the build > database... > > 4) When build is out of source (something that is becoming more common > in autotools and cmake also prefers) the build and database creation and > update requires constant extra effort, something most of the IDE do for > the user. > > 5) Do you have documented how to make eglot integration with yasnippet? > Because I can't make it work. > > If you have ways to go around these issues I will be very grated if you > share them, so I could try eglot+yasnippet for daily use. > > Thanks in advance Ergus. > -- João Távora [-- Attachment #2: Type: text/html, Size: 8093 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-30 14:46 ` João Távora 2022-05-30 22:51 ` Ergus @ 2022-05-31 16:42 ` Philip Kaludercic 2022-05-31 22:08 ` João Távora 1 sibling, 1 reply; 18+ messages in thread From: Philip Kaludercic @ 2022-05-31 16:42 UTC (permalink / raw) To: João Távora Cc: Stefan Monnier, Dmitry Gutov, emacs-devel, Noam Postavsky João Távora <joaotavora@gmail.com> writes: > To summarize, I don't have any particularly strong opinion on what should > be done > with Yasnippet. In fact, I don't even know what problem Philip is trying to > solve! To be specific, my issue was mentioned here: https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid false-positives when expanding snippets"). In my case, I have managed to circumvent the issue by unbinding the tab key and relying in hippie-expand, but the solution is not elegant and I would have appreciated a discussion on the issue tracker. The point was not to say that yasnippet has been abandoned, just to give an example where the liveliness of development could be questioned. > Is it just the general idea of abandonment of the fact that people's > issue reports go unanswered? If the latter, then I think archiving > the repo would make sense. No more issue reports would come in and > one could advertise the Emacs bug tracker. Would that improve things? I guess, but I think it would be preferable to call for someone to fork the package instead of shifting the burden of maintenance onto the emacs bug tracker. > I do think that it's important to preserve the documentation though, as > many people > seem to refer to it still. Or maybe transfer it to a more GNU ELPAish > location/format. > > Who knows if the description above motivates someone to pick up > 'snippet.el', finalize it, and make a new GNU ELPA package? Or maybe > it motivates someone to pick up the maintenance of the existing > Yasnippet. Due to a sudden increase in free time available to me, I might consider this. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-31 16:42 ` Philip Kaludercic @ 2022-05-31 22:08 ` João Távora 2022-06-01 5:57 ` Bozhidar Batsov 0 siblings, 1 reply; 18+ messages in thread From: João Távora @ 2022-05-31 22:08 UTC (permalink / raw) To: Philip Kaludercic Cc: Stefan Monnier, Dmitry Gutov, emacs-devel, Noam Postavsky [-- Attachment #1: Type: text/plain, Size: 3586 bytes --] On Tue, May 31, 2022, 17:42 Philip Kaludercic <philipk@posteo.net> wrote: To be specific, my issue was mentioned here: > https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid > false-positives when expanding snippets"). In my case, I have managed > to circumvent the issue by unbinding the tab key and relying in > hippie-expand, but the solution is not elegant and I would have > appreciated a discussion on the issue tracker. > Does it really matter where the discussion happens? The problem here is not the place, it's the unavailability of brain-hours to dedicate to your request. The point was not to say that yasnippet has been abandoned, just to give > an example where the liveliness of development could be questioned. > You don't have to sugar-coat it. Yasnippet's bug reports have gone unanswered at least for a year. They don't make it into my inbox, I'm not the maintainer anymore. Noam did a thorough and excellent job while he was maintaining it, he's not available anymore. It's de facto unmaintained, though rather stable in its intended use case. Of course Emacs is gigantic and everyone wants everything, and so it might not be doing what you want. I understand that. In that sense, it'd be nice if yasnippet wasn't' the monolithic package it is, and 'snippet.el' is a step in that direction. Then you could perhaps opt out (or in) to the multi-file, keybinding, abbrev-like functionality of yasnippet.el. Or simply compose 'snippet.el' bare-bones expansion/navigation with whatever other productivity tool where you think snippets make sense. Eglot is one of those tools and it works well with yasnippet today. I'd love to make it depend on simply 'snippet.el'. > Is it just the general idea of abandonment of the fact that people's > > issue reports go unanswered? If the latter, then I think archiving to > > the repo would make sense. No more issue reports would come in and > > one could advertise the Emacs bug tracker. Would that improve things? > > I guess, but I think it would be preferable to call for someone to fork > the package instead of shifting the burden of maintenance onto the emacs > bug tracker. > Again, i don't quite understand how that magically solves the root problem You're free to fork when you want, of course, but that normally happens when you want to take the software in a new irreconcilable new direction. Currently, yasnippet just needs (1) a maintainer that understands the current functionality and "protects" it, fixing bugs, not introducing new ones. New features are probably not a great idea. (2) someone to develop 'snippet.el' into production-ready state and make 'yasnippet.el' depend on it, then may integrate make 'snippet.el' into a new package. The person of (1) and (2) can be the same. > it motivates someone to pick up the maintenance of the existing > > Yasnippet. > > Due to a sudden increase in free time available to me, I might consider > this. > Great, if you're serious about it drop me a line stating more or less what your plan is. I don't know if you've read the code: it's not exactly a work of art (at least my parts aren't) :-) If you'd prefer a more palatable challenge, you could opt to simply develop the somewhat nicer 'snippet.el'. It'd be fine to create your own repo to host and develop it (say in that shiny SourceHut account where we discussed a bug the other day). João PS: in the meantime, it seems that Dmitry suggested what seems like a reasonable way to address your request. [-- Attachment #2: Type: text/html, Size: 5729 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-31 22:08 ` João Távora @ 2022-06-01 5:57 ` Bozhidar Batsov 2022-06-01 22:56 ` Richard Stallman 0 siblings, 1 reply; 18+ messages in thread From: Bozhidar Batsov @ 2022-06-01 5:57 UTC (permalink / raw) To: Emacs Devel [-- Attachment #1: Type: text/plain, Size: 4623 bytes --] Here are my 2 cents of the topic in general - unmaintained packages are not an Emacs-specific issue and they exist in every programming community. I don't really think we need some special policy on handling them, as: - if a package is really valuable new maintainers will always be found - if something is in a really bad state people will just stop using it Spending our limited efforts on policing the ELPA packages and trying to decide if something is "properly maintained" is not going to amount to much IMO. If someone uses a package and thinks it's valuable then it probably is. A package doesn't need to be perfect to be useful. It feels to me there's no real problem to be solved here. If we want to discuss what to do about specific packages (e.g. yasnippet) to improve their state - that's a completely different topic. On Wed, Jun 1, 2022, at 1:08 AM, João Távora wrote: > On Tue, May 31, 2022, 17:42 Philip Kaludercic <philipk@posteo.net> wrote: > >> To be specific, my issue was mentioned here: >> https://github.com/joaotavora/yasnippet/issues/1121 ("Avoid >> false-positives when expanding snippets"). In my case, I have managed >> to circumvent the issue by unbinding the tab key and relying in >> hippie-expand, but the solution is not elegant and I would have >> appreciated a discussion on the issue tracker. > > Does it really matter where the discussion happens? The problem > here is not the place, it's the unavailability of brain-hours to dedicate > to your request. > >> The point was not to say that yasnippet has been abandoned, just to give >> an example where the liveliness of development could be questioned. > > You don't have to sugar-coat it. Yasnippet's bug reports have gone unanswered > at least for a year. They don't make it into my inbox, I'm not the maintainer > anymore. Noam did a thorough and excellent job while he was maintaining it, > he's not available anymore. It's de facto unmaintained, though rather stable > in its intended use case. Of course Emacs is gigantic and everyone wants > everything, and so it might not be doing what you want. I understand that. > > > In that sense, it'd be nice if yasnippet wasn't' the monolithic package it is, > and 'snippet.el' is a step in that direction. Then you could perhaps opt out > (or in) to the multi-file, keybinding, abbrev-like functionality of yasnippet.el. > Or simply compose 'snippet.el' bare-bones expansion/navigation with > whatever other productivity tool where you think snippets make sense. > Eglot is one of those tools and it works well with yasnippet today. I'd love to > make it depend on simply 'snippet.el'. > >> > Is it just the general idea of abandonment of the fact that people's >> > issue reports go unanswered? If the latter, then I think archiving to >> > the repo would make sense. No more issue reports would come in and >> > one could advertise the Emacs bug tracker. Would that improve things? >> >> I guess, but I think it would be preferable to call for someone to fork >> the package instead of shifting the burden of maintenance onto the emacs >> bug tracker. > > Again, i don't quite understand how that magically solves the root problem > You're free to fork when you want, of course, but that normally happens > when you want to take the software in a new irreconcilable new direction. > > Currently, yasnippet just needs (1) a maintainer that understands the > current functionality and "protects" it, fixing bugs, not introducing new ones. > New features are probably not a great idea. (2) someone to develop 'snippet.el' > into production-ready state and make 'yasnippet.el' depend on it, then may > integrate make 'snippet.el' into a new package. The person of (1) and (2) can > be the same. > >> > it motivates someone to pick up the maintenance of the existing >> > Yasnippet. >> >> Due to a sudden increase in free time available to me, I might consider >> this. > > Great, if you're serious about it drop me a line stating more or less what > your plan is. I don't know if you've read the code: it's not exactly a work > of art (at least my parts aren't) :-) If you'd prefer a more palatable challenge, > you could opt to simply develop the somewhat nicer 'snippet.el'. It'd be fine > to create your own repo to host and develop it (say in that shiny SourceHut > account where we discussed a bug the other day). > > João > > PS: in the meantime, it seems that Dmitry suggested what seems like a > reasonable way to address your request. > > [-- Attachment #2: Type: text/html, Size: 7563 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-06-01 5:57 ` Bozhidar Batsov @ 2022-06-01 22:56 ` Richard Stallman 0 siblings, 0 replies; 18+ messages in thread From: Richard Stallman @ 2022-06-01 22:56 UTC (permalink / raw) To: Bozhidar Batsov; +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. ]]] Ummaintained packages can occur in any collection of packages. This may not be a disaster. But if the overall project wants to do a good job, it should try to arrange to get them maintained again. Our choices about how to organize this can get us better results or worse results. Let's make a small effort to get the better results. If you define "real problem" as disaster, well, I agree there isn't a disaster. But there is an opportunity. Let's take it. -- 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] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-29 21:34 What to do about unmaintained ELPA packages Philip Kaludercic 2022-05-29 21:41 ` Stefan Monnier 2022-05-29 21:54 ` Dmitry Gutov @ 2022-05-30 22:53 ` Richard Stallman 2022-05-31 10:31 ` Akib Azmain Turja 2 siblings, 1 reply; 18+ messages in thread From: Richard Stallman @ 2022-05-30 22:53 UTC (permalink / raw) To: Philip Kaludercic; +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. ]]] > I'd like to ask, if there some point at which should one should go from > regarding packages like these from "de facto unmaintained" to "actually > abandoned"? Perhaps if there was no real activity for over a year, > despite constant contributions? Would it make sense to call for anyone > new to take over maintaining the package? There is no need to have a rigid rule about this, but we should have a rough guide to go by. "Serious problems go unfixed for a year" sounds like enough reason to judge that there is a problem in maintaining that package. We don't need a rule about what we do if that happens, but we should take note of such packages and decide what to do. If a package is important enough, we might want to take action sooner than that. We can fix any GNU ELPA package if we see fit. We should try to discuss that with its maintainers first, but if they are nonresponsive, we don't have to wait to satisfy some rule. -- 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] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-30 22:53 ` Richard Stallman @ 2022-05-31 10:31 ` Akib Azmain Turja 2022-05-31 12:33 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Akib Azmain Turja @ 2022-05-31 10:31 UTC (permalink / raw) To: Richard Stallman, Philip Kaludercic; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2418 bytes --] Richard Stallman <rms@gnu.org> writes: > [[[ 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. ]]] > > > I'd like to ask, if there some point at which should one should go from > > regarding packages like these from "de facto unmaintained" to "actually > > abandoned"? Perhaps if there was no real activity for over a year, > > despite constant contributions? Would it make sense to call for anyone > > new to take over maintaining the package? > > There is no need to have a rigid rule about this, but we should have a > rough guide to go by. "Serious problems go unfixed for a year" sounds > like enough reason to judge that there is a problem in maintaining > that package. We don't need a rule about what we do if that happens, > but we should take note of such packages and decide what to do. "Serious problems go unfixed for a year" - I don't think this is always a result of maintainance problem. It may happen that the maintainer is unable to fix it, because either they aren't smart enough or they can't fix it due any other problem (maybe upstream bug, or they don't own the machine needed to reproduce and fix the problem). > > If a package is important enough, we might want to take action sooner > than that. We can fix any GNU ELPA package if we see fit. We should > try to discuss that with its maintainers first, but if they are > nonresponsive, we don't have to wait to satisfy some rule. Yeah, we can fix GNU ELPA packages, since those are part of Emacs. But what about NonGNU ELPA packages? I think we should try to talk with the maintainer, and possibly send a fix if its appropiate to do so. And in case they aren't responding, we should add a notice like UNMAINTAINED in the summany line. We can also to remove the package, but I think its not right to do so, for the user's sake. > > -- > 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) > > > -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-31 10:31 ` Akib Azmain Turja @ 2022-05-31 12:33 ` Stefan Monnier 2022-05-31 13:39 ` Akib Azmain Turja 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2022-05-31 12:33 UTC (permalink / raw) To: Akib Azmain Turja; +Cc: Richard Stallman, Philip Kaludercic, emacs-devel > Yeah, we can fix GNU ELPA packages, since those are part of Emacs. > But what about NonGNU ELPA packages? Actually, for the majority of packages, there is virtually no difference between GNU and NonGNU in this respect: their official development takes place elsewhere but we have our own branch in elpa.git/nongnu.git where we can install any changes we may want. And in both cases, installing changes on our own branch means that the development has diverged ("forked"), which will spell pain in the future if/when upstream's development continues. IOW: we can do it, but there are strong motivations to refrain from doing it. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What to do about unmaintained ELPA packages 2022-05-31 12:33 ` Stefan Monnier @ 2022-05-31 13:39 ` Akib Azmain Turja 0 siblings, 0 replies; 18+ messages in thread From: Akib Azmain Turja @ 2022-05-31 13:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: Richard Stallman, Philip Kaludercic, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Yeah, we can fix GNU ELPA packages, since those are part of Emacs. >> But what about NonGNU ELPA packages? > > Actually, for the majority of packages, there is virtually no difference > between GNU and NonGNU in this respect: their official development takes > place elsewhere but we have our own branch in elpa.git/nongnu.git where > we can install any changes we may want. > > And in both cases, installing changes on our own branch means that the > development has diverged ("forked"), which will spell pain in the future > if/when upstream's development continues. > > IOW: we can do it, but there are strong motivations to refrain from > doing it. > > > Stefan > Then we can, as I suggested in a previous message, add UNMAINTAINED to the summary line of the package. Thus users will know that its no longer maintained. And as soon as we get an update, we can remove it. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-06-01 22:56 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-05-29 21:34 What to do about unmaintained ELPA packages Philip Kaludercic 2022-05-29 21:41 ` Stefan Monnier 2022-05-29 21:54 ` Dmitry Gutov 2022-05-29 23:08 ` Tim Cross 2022-05-30 11:14 ` Akib Azmain Turja 2022-05-30 6:58 ` Philip Kaludercic 2022-05-30 13:45 ` Lars Ingebrigtsen 2022-05-30 14:46 ` João Távora 2022-05-30 22:51 ` Ergus 2022-05-30 23:04 ` João Távora 2022-05-31 16:42 ` Philip Kaludercic 2022-05-31 22:08 ` João Távora 2022-06-01 5:57 ` Bozhidar Batsov 2022-06-01 22:56 ` Richard Stallman 2022-05-30 22:53 ` Richard Stallman 2022-05-31 10:31 ` Akib Azmain Turja 2022-05-31 12:33 ` Stefan Monnier 2022-05-31 13:39 ` Akib Azmain Turja
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).