1. 26
  1.  

  2. 8

    I see some constant trend to compare stuff in Emacs with external packages (e.g. Magit vs vc, Flycheck vs Flymake, Projectile vs project.el), which I find slightly bizarre given the trend in Emacs to move as many built-in packages as possible to GNU ELPA,

    Flymake and project.el are both ELPA packages, actually. vc has been around for three decades and it predates package.el.

    • drop the contributor agreement

    The FSF legal counsel has declared that they cannot enforce the GPL unless the copyright belongs entirely to the FSF. This is why the contributor agreement is needed, and anyway, it’s just one email to the FSF, sign a paper, email a scan of the paper (you can get away with using your smartphone).

    • discuss ideas in an (modern) issue tracker, instead of on a mailing list

    What’s wrong with mailing lists? Issue trackers like Github are quite bad for discussion, which is why you always need something like Gitter or IRC to provide a discussion forum. A mailing list can be used for both development (patches) and discussion.

    • apply less political activism and more pragmatism in the conversation around new ideas/features

    Being free software and adhering to the free software principles is an important aspect of Emacs. It is a good idea to consider the impact of ideas on user freedoms. It’s not done whimsically, freedom is important.

    1. 4

      What’s wrong with mailing lists?

      I think my main problem with mailing lists is the lack of tracability in the history. It’s not a logical consequence of mailing lists (you can certainly do it), but it doesn’t seem to happen.

      I spend a fair amount of time digging through GCC’s history and when I find a patch touching code that matters to what I’m looking at, the commit message is not enlightening. Why was the change made? Is this associated with a bug? What was the design discussion around it? (But ooo - Changelog was updated! “Ditto!”) Rarely are those anwered and even rarer is an identifer or link to a bug report or a mailing list discussion. I have to go digging through mailing list posts (with a really substandard search mechanism) to find some background. Even then, there might not be any.

      Say what you want about issue trackers, but having every commit associated with some background knowledge is really, really useful in the long run.

      1. 2

        Oh, issue trackers are absolutely essential. You definitely need one, a mailing list isn’t enough. The kind of discussion I was talking about and the way in which mailing lists make most sense is in informal, meta discussion. Places like github don’t have anything for that and its issue tracker is not good as a forum.

        1. 2

          Places like github don’t have anything for that

          They do, its called discussions.

          https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/about-team-discussions

          But I agree that the flat comment hierarchy is not ideal for discussions that tend to branch out.

      2. 3

        Flymake and project.el are both ELPA packages, actually. vc has been around for three decades and it predates package.el.

        I’m not sure if you’re trying to contradict me here, because you’re just repeating what I said. I’m well aware they are not ELPA packages, even if this wasn’t always the case. That’s part of the trend to I mentioned that you actually quoted.

        The FSF legal counsel has declared that they cannot enforce the GPL unless the copyright belongs entirely to the FSF. This is why the contributor agreement is needed, and anyway, it’s just one email to the FSF, sign a paper, email a scan of the paper (you can get away with using your smartphone).

        Well, I’m not a legal expert but I do wonder what does mean for every other GPL project that doesn’t have an explicit copyright assignment agreement. I did sign the agreement a long time ago and I recall I waited so long for the confirmation that by the end I didn’t remember I had done it. Very few people are going to waste so much time to contribute to a project, unless they are really invested it in. At the very least the FSF that switch to instant digital signatures or something like that.

        What’s wrong with mailing lists? Issue trackers like Github are quite bad for discussion, which is why you always need something like Gitter or IRC to provide a discussion forum. A mailing list can be used for both development (patches) and discussion.

        Mailing lists provide no structure and people who branch out different threads from the main one create a total mess. You don’t need a chat to have a conversation - you can just use an issue’s comments (as one example). A lot of huge projects are doing this and it works fine for them. I’m not saying “drop email completely”, I’m saying “don’t use them for things they are not optimal for”.

        Being free software and adhering to the free software principles is an important aspect of Emacs. It is a good idea to consider the impact of ideas on user freedoms. It’s not done whimsically, freedom is important.

        True. But in the end of the day you also have to remember that you’re building software that is meant to solve certain real-world problems. Your political agenda will mean nothing if it drives an excellent piece of software into the ground. I used to be a big believer in RMS and FSF 20 years ago, but seeing how his leadership style and hardline vision affected negatively a lot of GNU projects, I’m not 100% that this is not the way to go. Great software needs users, it needs mindshare and it needs traction. It cannot exist on top of a political agenda alone.

        1. 3

          I’m not sure if you’re trying to contradict me here, because you’re just repeating what I said. I’m well aware they are not ELPA packages, even if this wasn’t always the case. That’s part of the trend to I mentioned that you actually quoted.

          You mean they are ELPA packages? I see now what you meant, but given the previous sentence I was under the assumption that you didn’t think they were ELPA packages.

          At the very least the FSF that switch to instant digital signatures or something like that.

          I think you can get away by just using PDF digital signatures. No need to print anything.

          Mailing lists provide no structure and people who branch out different threads from the main one create a total mess. You don’t need a chat to have a conversation - you can just use an issue’s comments (as one example). A lot of huge projects are doing this and it works fine for them. I’m not saying “drop email completely”, I’m saying “don’t use them for things they are not optimal for”.

          Well, that depends on your email client. Email supports threading just fine. A nice alternative is to use NNTP (news) via Gmane, because then you can just fetch the entire thread of a single message. You can do this in Emacs right now, hit M-x gnus RET B nntp RET news.gmane.io and pick emacs.devel from the list.

          You can also use sourcehut’s lists which provide an excellent web user interface for mailing lists, with support for threads, and replying on the web. It’s still just email underneath.

          True. But in the end of the day you also have to remember that you’re building software that is meant to solve certain real-world problems. Your political agenda will mean nothing if it drives an excellent piece of software into the ground. I used to be a big believer in RMS and FSF 20 years ago, but seeing how his leadership style and hardline vision affected negatively a lot of GNU projects, I’m not 100% that this is not the way to go. Great software needs users, it needs mindshare and it needs traction. It cannot exist on top of a political agenda alone.

          I would argue that GNU Emacs has survived close to 40 years (and Emacs itself close to 50 years) because it is free software. In the grand scheme of things adding support for LSP or native JSONRPC—although right now they are very welcome additions—will be yet another changelog entry and a historical footnote.

          Free software matters — a large chunk of the world relies on GNU technology (GCC, coreutils, autotools, etc.) to do their computing. They did not survive on technical merit alone, they survived because they were free software first, and good software second.

          I predict in 10 years things like Atom or Sublime Text will have fallen into obscurity, but Emacs, Vim, other free software will live on, and prosper.

          1. 2

            I’m sure that Emacs will be around for a very long time, but it’s already a niche editor (unlike vim) and with the way the project is stewarded that’s not going to change any time soon. There’s a big difference between surviving and thriving and my preference for Emacs would be the latter. As noted here VS Code is winning the hearts of most developers these days, and Emacs has been stuck at 5% for ages. That’s not going to get any better unless something fundamentally changes. Microsoft might have been an evil enterprise in the past, but today they are stewarding their open-source projects better than the FSF hands down. It’s really not all about money and resources - it’s about having the right mindset and the right attitude.

            1. 2

              I generally agree, though vscode is not my favorite thing.

              I’m reminded more of things like RMS wanting to not pull lldb support into gud because (I’m paraphrasing only slightly) “llvm was trying to undermine the gpl”. The FSF can do whatever it wants, and I generally am ok with things, but the past 20 years haven’t impressed me much with their ability to reflect upon their processes and attempt to bring more into the fold.

              I predict that GPL and even the FSF will take a back seat to more MIT/BSD/related licensed things due to their having more implicit freedom and less overall ideology drama to direct users of the code (programmers). Think like embedding llvm+clang into lldb kinda stuff. Things that gcc/gpl/fsf literally won’t allow for technically due to ideals. Imagine emacs with a builtin compiler for c/c++/rust/etc….

              Prosper? I can’t see it happening given the current mentality of the FSF. Its too extremist in its ideals. They may even be “right” for whatever definition of right that is. But it seems to me to be a case of winning the battle but losing the war with their current path.

              It used to be GPL/GNU software wasn’t good software “second”, it used to connote an air of quality on its own. Now however…. it just seems like being read into some ecclesial cult with some of the rituals involved.

              1. 1

                Emacs is not a popular editor by any means, but the goal of Emacs as the flagship editor of the GNU project is to be the best free software editor. That is its first goal, everything else is secondary. Once you understand Emacs is not going to sacrifice the respect of user freedoms in pursuit of popularity or technical superiority it makes sense how the project is governed. When it comes to good features Emacs does not usually reject them if they do not conflict with its free software ideals, e.g. see the recent development of native compilation of Elisp, native JSON-RPC etc.

                Emacs has been forked in the past in pursuit of technical or practical superiority, see XEmacs, SXEmacs, etc. Those projects are no longer alive.

                To me Emacs should stay in its pursuit of being free software first. I don’t think it’s particularly beneficial for Emacs to try to be the most popular editor if it means letting go of its founding principles: respecting user freedom.

        2. 6

          Strongly disagree that moving Emacs development to a proprietary site rather than a mailing list would be an improvement. I also think that it would be a mistake to get rid of copyright assignment — this is an important defense against copyright lawsuits, and preserves the GNU Project’s freedom of movement.

          The only thing I really disagree with the FSF’s stewardship of the project on has been the decisions to make things technically less elegant in hopes of preventing proprietary usage of the tools. This is, I think, never the right answer. Yes, software should be free: it should also be elegant. We can’t force software hoarders to free their software, but we do control ourselves, and we should always write elegant solutions and produce quality software. If others use it for bad ends, well, that is their bad choice.

          1. 8

            Strongly disagree that moving Emacs development to a proprietary site rather than a mailing list would be an improvement.

            Letting people contribute to discussions not on a mailing list does not require proprietary software.

            1. 6

              The problem is not owning your own stuff. If Github decides it just plain doesn’t like you anymore, you’re done. You can go on Twitter and appeal and do everything else, but if Github gets it in its little Microsoft-owned corporate head that you are, somehow, not good, you’re gone and there’s nothing anyone can do. I think Emacs is worth a bit more than that.

              1. 6

                This doesn’t respond to what the previous comment said. One can host their own forge, and something like Sourcehut would allow people used to mailing lists to continue with little to no changes to their workflow.

                1. 1

                  AFAIK that was being considered at some point, but Sourcehut is sadly still in it’s alpha-stage (thought it’s stable enough for me).

            2. 7

              Strongly disagree that moving Emacs development to a proprietary site rather than a mailing list would be an improvement. I also think that it would be a mistake to get rid of copyright assignment — this is an important defense against copyright lawsuits, and preserves the GNU Project’s freedom of movement.

              I guess you assumed I meant “move the development to GitHub”, which I wouldn’t mind, but I was thinking more something like “use an instance of GitLab”, which is free software. There are many other similar options.

            3. 3

              I’m actually looking forward Non-GNU Elpa, and hope it obsoletes MELPA. Having more packages installable, without having to find out about MELPA, find out how to use it and set it up seems like a plus. Really the only thing MELPA will be useful after that is to host packages that promote propitiatory software, which is just what RMS takes issue with.

              1. 6

                The Emacs developers could have just as easily enabled MELPA/MELPA Stable by default if they wanted to, so I think they’re not exactly constructive in their approach to the issue. I also assume they’ll force people to use their (inferior/legacy) development toolchain for Non-GNU Elpa, which will likely be off-putting for many package authors. As a package developer I’d rather focus on doing some meaningful work for the end users, rather than deal with rules and regulations of little value. Obviously, that’s a matter of perspective - I love the MELPA approach of doing things and I dislike how Emacs is being stewarded (although things have been slowly improving there over the past decade).

                1. 3

                  Even if the GNU project would disregard their commitment to avoid propitiatory software, I still think MELPA shouldn’t be used. Regular MELPA publishes whatever the last commit was in the repository being used. That would required a more advanced approach with Git branches, but nothing along those lines is enforced. MELPA stable at the same time is disregarded, and often forgotten, leading to broken packages and packages that cannot even be installed because they have non-stable dependencies.

                  I also assume they’ll force people to use their (inferior/legacy) development toolchain for Non-GNU Elpa, which will likely be off-putting for many package authors.

                  What do you mean? Mailing lists? It’s always a trade-off. Maybe you won’t have a fancy web interface like GitHub (thought Guix issue tracker comes close), but then again, you won’t have to use GitHub.

                  1. 3

                    I also assume they’ll force people to use their (inferior/legacy) development toolchain for Non-GNU Elpa, which will likely be off-putting for many package authors.

                    What’s so bad about it? You email emacs-devel saying here’s my package, please have a look. Then you get someone to apply your patch for elpa.git.

                    I completely understand this is not what people are used to with Github pull requests et al, but I don’t see anything fundamentally bad about this - you can use sourcehut to prepare patches over a web interface. The ability to use git send-email with a web interface is one of the really amazing innovations at sourcehut, mad props to @ddevault.

                    1. 3

                      What’s so bad about it? You email emacs-devel saying here’s my package, please have a look. Then you get someone to apply your patch for elpa.git.

                      Ah, yeah - I’ll wait for something else to apply patches for my package. :-) A recipe for productivity. But even assuming that everyone can just apply whatever changes are needed for their package, why go through the trouble of maintaining two instances of your package (as le’ts be real - almost all Emacs packages are hosted on GitHub/GitLab these days). You can’t afford not to be on GitHub/GitLab as this limit the potential collaborators for your package a lot, so in effect to be on GNU/non-GNU ELPA you have to do additional work. How is this a good idea for anyone? And that’s a lot of the beauty of MELPA - it spares the maintainers from having to deal with additional work for package distribution. That’s really important IMO! If GNU non-ELPA replicates the same approach, however, this will make the rationale for their repo pointless, though, so I guess they’ll want the code to be copied to a repo that supposedly will be vetted and what not.

                      I completely understand this is not what people are used to with Github pull requests et al, but I don’t see anything fundamentally bad about this - you can use sourcehut to prepare patches over a web interface. The ability to use git send-email with a web interface is one of the really amazing innovations at sourcehut, mad props to @ddevault.

                      And code reviews over email are so much fun, right? Seriously, even before GitHub sending lots of patches over email and discussing improvements there was both annoying and inefficient. Being able to do something in a certain way, doesn’t make it the optimal way. While I do like GitHub and maintain lots of projects there, I’m fine with any approach to work that provides enough structure and doesn’t results in wasted efforts.

                      1. 3

                        Ah, yeah - I’ll wait for something else to apply patches for my package. :-) A recipe for productivity. But even assuming that everyone can just apply whatever changes are needed for their package, why go through the trouble of maintaining two instances of your package (as le’ts be real - almost all Emacs packages are hosted on GitHub/GitLab these days). You can’t afford not to be on GitHub/GitLab as this limit the potential collaborators for your package a lot, so in effect to be on GNU/non-GNU ELPA you have to do additional work. How is this a good idea for anyone? And that’s a lot of the beauty of MELPA - it spares the maintainers from having to deal with additional work for package distribution. That’s really important IMO! If GNU non-ELPA replicates the same approach, however, this will make the rationale for their repo pointless, though, so I guess they’ll want the code to be copied to a repo that supposedly will be vetted and what not.

                        With ELPA, you can actually maintain your package as an out-of-tree remote ref. Just do

                        git push elpa master:refs/heads/externals/yourpackage
                        

                        and the next nightly build will have it updated. You just need push rights to elpa.git which you can request from emacs-devel. This way you don’t have to maintain separate instances.

                        I think one of MELPA’s worst aspects is the fact that it just builds on every commit. There are lots of quality regressions! Many times after updating packages I’ve had to erase my ~/.emacs.d/elpa directory and start over, pinning stuff to melpa stable or something. This often happens because breakage in transitive dependencies.

                        What I would like to see is MELPA distributions like Quicklisp, which does monthly releases of packages that have been tested to work together. MELPA Stable has no end to end tests, you can just tag any commit you like.

                        And code reviews over email are so much fun, right? Seriously, even before GitHub sending lots of patches over email and discussing improvements there was both annoying and inefficient. Being able to do something in a certain way, doesn’t make it the optimal way. While I do like GitHub and maintain lots of projects there, I’m fine with any approach to work that provides enough structure and doesn’t results in wasted efforts.

                        Well, I just think Github issues are not good for structured conversation, it’s really just a flat list. Email threads are superior in this regard, but you need an email client that supports them (or just use a newsreader with Gmane).

                        1. 1

                          I think one of MELPA’s worst aspects is the fact that it just builds on every commit. There are lots of quality regressions! Many times after updating packages I’ve had to erase my ~/.emacs.d/elpa directory and start over, pinning stuff to melpa stable or something. This often happens because breakage in transitive dependencies.

                          That’s why there is MELPA Stable. Personally I use MELPA for years and faced problem only once but I exactly for those reasons there is MELPA Stable. As package author I find MELPA approach far more better then ELPA.

                          Well, I just think Github issues are not good for structured conversation, it’s really just a flat list. Email threads are superior in this regard, but you need an email client that supports them (or just use a newsreader with Gmane).

                          I think code reviews should be bound to code not to maili. Even though GitHub issues might not be the best solution from threaded point of view it still keeps all comments regarding code in one place which I find much better.

                          1. 3

                            That’s why there is MELPA Stable. Personally I use MELPA for years and faced problem only once but I exactly for those reasons there is MELPA Stable. As package author I find MELPA approach far more better then ELPA.

                            The stability guarantee isn’t in any sense a real guarantee. If the package author feels like pushing a tag, it gets published to MELPA Stable.

                            In general we should see that there is a distinction between distributions (sets of working packages) and development builds. I think we should try to get something cohesive for MELPA stable, and especially for NonGNU ELPA.

                            1. 2

                              I get your point, but I’ve used MELPA since day 1 and I’ve encountered only a handful of issues with the snapshot builds. (and I was fully aware what I had signed up for, so that was fine) The notion of distributions is nice, but I’m not quite sure how you’ll reliably infer that all packages play nicely with each other, as I don’t think the fact that a package can be loaded is enough of a criteria.

                              I also wonder why I’d be tagging as a release, something that’s not a release but that’s a different topic I guess. What I’m trying to say is that often developers are trying to solve issues that are not that big of issues to begin with.

                              1. 1

                                The stability guarantee isn’t in any sense a real guarantee. If the package author feels like pushing a tag, it gets published to MELPA Stable.

                                That’s absolutely true but that is general rule not related to MELPA in any way. Otherwise we wouldn’t have sections in changelogs named “Fixed bugs” ;)

                      2. 3

                        The Emacs developers could have just as easily enabled MELPA/MELPA Stable by default

                        Melpa has a history of making very bad decisions around security, so I’m glad they didn’t do this. It’s better nowadays but I still don’t trust their judgement after it took them three years to disable distribution of packages that were publicly editable on a wiki.

                        1. 4

                          Well, I think they were mostly forced there, but the package development/maintenance culture that was common a few years back. In really, MELPA and GitHub/GitLab were the major reasons why hosting packages on EmacsWiki was finally (mostly) abandoned. I had never installed anything from wiki sources, for obvious reasons, but I know that many people considered this a feature. :-) MELPA also addressed another big problem back in the day - virtually no one was cutting releases and many projects would go on for years and years without a “stable” release. Back that a repo for “stable” packages would have never worked simply because there were so few of those of they were often incompatible with one another.

                          1. 1

                            I think they were mostly forced there, but the package development/maintenance culture that was common a few years back.

                            This does very little to inspire confidence in their decision-making ability.

                            I had never installed anything from wiki sources, for obvious reasons

                            How do you know this for sure? The wiki-backed packages were not clearly marked, and non-wiki-backed packages could easily declare a dependency on a wiki-backed package. A big part of why this was such a disaster is that everything got tossed into one big pile, and there was no way to say “give me the stuff from github but not the stuff from the wiki”.

                            MELPA also addressed another big problem back in the day - virtually no one was cutting releases and many projects would go on for years and years without a “stable” release.

                            All the more reason guix-style repeatable packaging is needed rather than just tossing everything in a big pile and saying “here just have… I dunno; whatever version is newest; it’ll be fine probably”.

                            1. 1

                              How do you know this for sure?

                              Fair point about the deps. I’m generally very careful with the packages that I use and I don’t install anything before skimming over the package source to acertain its general quality, but package deps can, of course, change, so you’re right.

                              I do believe, however, that in MELPA’s web UI the source of each package was clearly visible. Sadly, you can’t have such additional data in Emacs’s own UI.

                              All the more reason guix-style repeatable packaging is needed rather than just tossing everything in a big pile and saying “here just have… I dunno; whatever version is newest; it’ll be fine probably”.

                              True, but time has made me quite practical and I’ll take any reasonable solution that solves my problem over waitng for a great/perfect solution. In theory MELPA sounds like a recipe for trouble, but I’ve used it since day one and I had very few issues with it (and none of them were serious). When I compare that to vendoring packages manually beforehand, it seems like a massive improvement to me. :-) No to mention all the efforts of the MELPA team to clean up some packages so they could be distributed with package.el in the first place.

                    2. 1

                      With regards to

                      In case someone is curious about my Emacs wish list - I don’t really care about changing any defaults, package improvements or anything like this. I’d like to see more efforts for improving Emacs Lisp, the standard library (libraries like seq.el and map.el were great additions IMO), making it possible to build rich UIs in some sane manner (overlays are quite limiting).

                      I wonder if the above would help with solving existing adoption problems for existing features of Emacs and its ecosystem of packages, or would it mostly benefit new features, that, perhaps will find their new audience?

                      My personal feedback in the survey was that I cannot:

                      • get Emacs to support Gradle projects for JDK and for Android,
                      • cannot get emacs to support Facebook-Flow based Javascript projects that use React CRA build chain, and I - -
                      • cannot figure out how to integrate ASCII art into comments in Java, Javascript, and org-mode
                      • cannot figure out how to do Java code refactoring (such that all classes that are used within a Gradle project would get changed, updated when update package structures, move methods from inner class to outer class, change member names, etc)

                      Every one of the above usage patterns seem to requires multiple existing packages to talk to each other, in other words to be ‘integrated’ into a cohesive flow. May be I am a bad example, but the complexity to accomplish this type of integration of packages, even if they exist, is enormous.