Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: