Comment by da39a3ee | Hacker News Reader

Comment by da39a3ee | Hacker News Reader

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.

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.

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

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?

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-previ...

https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mod...

https://github.com/politza/pdf-tools/issues/51

Thanks! pdf-tools gives me very crip images without the flag mentioned in the gibhub issue (perhaps that's default by now?). My personal org setup uses pdf-tools, so maybe that's why I didn't notice that one either. I hadn't used the the Mac, and Emacs on a Mac as a primary driver for work from home until about 3 months ago, but after the first couple of weeks of dealing with annoying minute changes during my adaptation from Linux, I now work more-or-less fine on it (with external keyboard, mouse, and monitor most of the time, and most of the time in iterm2 on a remote Emacs server; the remaining time, from the local Emacs, for visualization, reading PDF papers or documentation, and composing local documents.)

The precise term-of-art for "companies that make money" in the Emacs community, coined by RMS himself, is "Evil Software Hoarders".

https://news.ycombinator.com/item?id=26113192

>Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun.

https://en.wikipedia.org/wiki/Gosling_Emacs

>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.

>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"

>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."

>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!

[...]

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).

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).

Reply on news.ycombinator.com