5 ms·

This is amazing bug-fixing work Lars! Here are my thoughts on what is needed for emacs to have a real future in the 21st century: 1. We must create a strong c

This is amazing bug-fixing work Lars! Here are my thoughts on what is needed for emacs to have a real future in the 21st century: 1. We must create a strong community of highly-skilled programmers who use Emacs for their work, for it is out of this community that emacs contributors, developers and maintainers will come. 2. Therefore Emacs must be first-class for day-to-day programming work. 3. This means LSP. I think it means taking some lessons from VSCode: i.e. not being a traditional IDE, but having first-class LSP functionality in all common languages. 4. It probably also means being able to follow VSCode's lead in remote container-based development. 5. The emacs development community needs to become less of a weird argumentative place. The points above will help because it will have more representation from programming traditions other than lisp. 6. Development should move to something like Github/GitLab, i.e. with PRs, not emailed patches. 7. The memory of Stallman and the FSF should not be forgotten but their opinions should not be given any special weight. E.g. on using a non-free platform like Github/GitLab, and on supporting MacOS. 8. Things like org-mode and gnus are a distraction: emacs core should focus on programming modes. If it would help focus emacs development on programming modes to severely trim the core, then let's do it, and move these things into packages. org-mode is very popular but too unfocused to be in core. gnus is great but the next generation aren't going to use it for their email. 9. We should kill the idea that it's desirable for projects to become part of core. It's not desirable: it makes it extremely hard for people to contribute to those packages due to FSF papers and email/bug tracker workflows that are totally alien to contributors and not as good as more modern workflows, and it makes the emacs bug tracker unfocused. 10. We should not think about making emacs popular and instead just focus on making it excellent for programming.

e3bc54b2 5y ago
I agree with some of your points and have to disagree with others. > Things like org-mode and gnus are a distraction: emacs core should focus on programming modes Emacs can and has been doing both of these for a long time. Emacs is unlike anything else out there because it empowers the user, who does not need to be programmer. The popular Helm package is maintained by a mountain climbing trainer for almost a decade. We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers. > on using a non-free platform like Github/GitLab, and on supporting MacOS. MacOS is already supported, as I understand. Github/Gitlab advice zounds nice, but we have to zoom out on this. Emacs is older than most programmers out there. It is older than git and bazaar. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. If you have a network connected device, it can probably send/receive email.
- da39a3ee 5y ago
  Thanks, fair enough. > We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers. Yeah, I do see that view. I just wonder whether we need to make some tough decisions in order for emacs to survive. Specifically: although emacs is wonderful for tinkerers and non-programmers, what it actually is is a lisp execution environment powering a text editor. When described like that, it's pretty clearly a tool for programmers and expert / adventurous ones at that. I think it might be best to embrace that: it's great for others to join the ride but, sadly, not the raison d'etre of emacs. Better to focus on making it very, very, good within a well-scoped area. > MacOS is already supported, as I understand. Stallman et al. have refused to accept into core various patches that are required to make Emacs great on MacOS. For example, native MacOS SVG rendering software is not supported. This is why the Mitsuharu emacs-mac fork [0] exists and is so loved. The reason they've refused to accept those patches is because their inner 14-year olds don't like "companies that make money" and so don't want to accept patches that give "for profit software" an advantage over "free software". > Github/Gitlab advice zounds nice, but we have to zoom out on this. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. I guess we have to agree to disagree there. My claim is simply that PRs are a technological advance over email review. The fact that Emacs uses non-PR based development makes me not contribute to them. Emailing patches is absurd: a patch is a thing that exists in a code lineage; it has a parent; it's not an entity in its own right. There are many things that are ubiquitous but not the best choice! [0] https://bitbucket.org/mituharu/emacs-mac/src https://bitbucket.org/mituharu/emacs-mac/src
  - pama 5y ago
    I can see SVG fine on my Mac from top of tree emacs. (I think I use the rsvg library.) Maybe I misunderstood something; what is the thing I am missing?
    - da39a3ee 5y ago
      So, for example, if you use preview-latex in auctex, or the equivalent functionality in org-mode, you'll notice that the small image previews are very fuzzy, and not at all what you'd expect from your retina screen. The reason ultimately is that the Mitsuharu emacs-map fork has implemented certain things which make PNGs scale correctly for Retina screens, and makes use of Apple's native webkit-based SVG renderer rather than the Stallman-acceptable librsvg. But of course Stallman refused to accept the hard work done by Mitsuharu, which makes Emacs better for a subset of Emacs users and therefore is an _improvement_ to Emacs, with the childish logic that they don't want to allow things that makes emacs better on "non-free" systems than on "free" systems. See the following for example: https://stackoverflow.com/questions/30151338/org-latex-preview-is-fuzzy-on-retina-displays https://stackoverflow.com/questions/30151338/org-latex-previ... https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mode_inline_latex_images_fuzzy_only/ https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mod... https://github.com/politza/pdf-tools/issues/51 https://github.com/politza/pdf-tools/issues/51
pama 5y ago
I think that 1 and 2 are already there. I am not sure about 8 and 9. In addition to programmers, Emacs has amazing communities of researchers, writers, note keepers, cooks, sysadmins, all kinds of remote workers. It is nice to have direct support for all kinds of things beyond LSP (which is useful and supported).
- da39a3ee 5y ago
  We don't need LSP to be "supported"; it needs to be as good as e.g. VSCode. Seriously; that is what is required if Emacs is to maintain a large enough community of skilled programmers to maintain it in this century. I get it, the diverse userbase of people from all walks of life using this crazy lisp-based editor from the early 80s is cool. But it will fizzle out if it is not loved and used by the next generation of professional programmers (well, this generation of under-40 professional programmers).

e3bc54b2 5y ago

I agree with some of your points and have to disagree with others. > Things like org-mode and gnus are a distraction: emacs core should focus on programming modes Emacs can and has been doing both of these for a long time. Emacs is unlike anything else out there because it empowers the user, who does not need to be programmer. The popular Helm package is maintained by a mountain climbing trainer for almost a decade. We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers. > on using a non-free platform like Github/GitLab, and on supporting MacOS. MacOS is already supported, as I understand. Github/Gitlab advice zounds nice, but we have to zoom out on this. Emacs is older than most programmers out there. It is older than git and bazaar. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. If you have a network connected device, it can probably send/receive email.

da39a3ee 5y ago
Thanks, fair enough. > We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers. Yeah, I do see that view. I just wonder whether we need to make some tough decisions in order for emacs to survive. Specifically: although emacs is wonderful for tinkerers and non-programmers, what it actually is is a lisp execution environment powering a text editor. When described like that, it's pretty clearly a tool for programmers and expert / adventurous ones at that. I think it might be best to embrace that: it's great for others to join the ride but, sadly, not the raison d'etre of emacs. Better to focus on making it very, very, good within a well-scoped area. > MacOS is already supported, as I understand. Stallman et al. have refused to accept into core various patches that are required to make Emacs great on MacOS. For example, native MacOS SVG rendering software is not supported. This is why the Mitsuharu emacs-mac fork [0] exists and is so loved. The reason they've refused to accept those patches is because their inner 14-year olds don't like "companies that make money" and so don't want to accept patches that give "for profit software" an advantage over "free software". > Github/Gitlab advice zounds nice, but we have to zoom out on this. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. I guess we have to agree to disagree there. My claim is simply that PRs are a technological advance over email review. The fact that Emacs uses non-PR based development makes me not contribute to them. Emailing patches is absurd: a patch is a thing that exists in a code lineage; it has a parent; it's not an entity in its own right. There are many things that are ubiquitous but not the best choice! [0] https://bitbucket.org/mituharu/emacs-mac/src https://bitbucket.org/mituharu/emacs-mac/src
- pama 5y ago
  I can see SVG fine on my Mac from top of tree emacs. (I think I use the rsvg library.) Maybe I misunderstood something; what is the thing I am missing?
  - da39a3ee 5y ago
    So, for example, if you use preview-latex in auctex, or the equivalent functionality in org-mode, you'll notice that the small image previews are very fuzzy, and not at all what you'd expect from your retina screen. The reason ultimately is that the Mitsuharu emacs-map fork has implemented certain things which make PNGs scale correctly for Retina screens, and makes use of Apple's native webkit-based SVG renderer rather than the Stallman-acceptable librsvg. But of course Stallman refused to accept the hard work done by Mitsuharu, which makes Emacs better for a subset of Emacs users and therefore is an _improvement_ to Emacs, with the childish logic that they don't want to allow things that makes emacs better on "non-free" systems than on "free" systems. See the following for example: https://stackoverflow.com/questions/30151338/org-latex-preview-is-fuzzy-on-retina-displays https://stackoverflow.com/questions/30151338/org-latex-previ... https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mode_inline_latex_images_fuzzy_only/ https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mod... https://github.com/politza/pdf-tools/issues/51 https://github.com/politza/pdf-tools/issues/51

pama 5y ago

I think that 1 and 2 are already there. I am not sure about 8 and 9. In addition to programmers, Emacs has amazing communities of researchers, writers, note keepers, cooks, sysadmins, all kinds of remote workers. It is nice to have direct support for all kinds of things beyond LSP (which is useful and supported).

da39a3ee 5y ago
We don't need LSP to be "supported"; it needs to be as good as e.g. VSCode. Seriously; that is what is required if Emacs is to maintain a large enough community of skilled programmers to maintain it in this century. I get it, the diverse userbase of people from all walks of life using this crazy lisp-based editor from the early 80s is cool. But it will fizzle out if it is not loved and used by the next generation of professional programmers (well, this generation of under-40 professional programmers).