Live data from Hacker News

Emacs Users Are Like Terry Pratchett’s Igors (2013)

chrisdone.com

41–50 of 58 posts

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#41
post #33
post #12

Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow. It’s probably possible today to write an Emacs in a high-performance Lisp. Elisp has no support for concurrency, for example. “Some 359,000 lines of C code comprise its kernel, and 1,637,000 lines of Emacs Lisp take the rest of it.1”

> Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow. 43 years ago Emacs wasn't written in C or Lisp. It was first just a bunch of TECO code, and TECO was written in assembler (I still have the source on my bookshelf). In fact none of the first three machines to have Emacses (PDP-10, Multics, and the CADR Lispm) supported C. (C was eventually ported to the PDP-10/KL-20 but C…

You’re right the first implementation in C was Gosling Emacs in 1981. Stallman based GNU Emacs on that in 1984.

https://en.m.wikipedia.org/wiki/Emacs

So, would you just say around 38 years and agree that 43 or 38 is pretty much irrelevant to my point?

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#42
post #29
post #26

Earlier quoted context omitted.

> Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. Then there is something wrong with your environment. Emacs has no problems with big files. It can have problems with very long lines, but big files shouldn't slow it down.

I can reproduce this with emacs obtained from the repo on a newly installed Ubuntu 18.04 virtual machine.

Then I recommend M-x report-emacs-bug

The emacs developers will be very interested to hear about it.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#43
post #41
post #33

Earlier quoted context omitted.

> Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow. 43 years ago Emacs wasn't written in C or Lisp. It was first just a bunch of TECO code, and TECO was written in assembler (I still have the source on my bookshelf). In fact none of the first three machines to have Emacses (PDP-10, Multics, and the CADR Lispm) supported C. (C was eventually ported to the PDP-10/KL-20 but C…

You’re right the first implementation in C was Gosling Emacs in 1981. Stallman based GNU Emacs on that in 1984. https://en.m.wikipedia.org/wiki/Emacs So, would you just say around 38 years and agree that 43 or 38 is pretty much irrelevant to my point?

I don't really know what your point was. I started using TECO emacs in the 70s and it's pretty deeply wired into my fingers.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#44

Every time one of these articles about Emacs is posted here I kind of shake my head and wonder why my experience with it is so different. So big caveat: my experience with Emacs is pretty much entirely limited to org-mode (which is the only reason I picked up Emacs at all). I really liked a lot of the ideas in org-mode, but the more I used it the more I really wanted to make some minor tweaks. No problem, I thought.…

Yeah. Org-mode’s nature is pretty different from Emacs’. I don’t feel that way about Gnus, weirdly. I wonder if I’m missing something there. Helm, like org-mode, is from people getting something pretty different out of Emacs than I am. That’s okay! I just wish we had better terms to describe it.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#45
post #26
post #16

Earlier quoted context omitted.

Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. It takes 5 seconds to redraw the visible text after hitting "page up" or "page down". I don't think emacs should be made any slower than it already is.

> Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. Then there is something wrong with your environment. Emacs has no problems with big files. It can have problems with very long lines, but big files shouldn't slow it down.

That's not true. Emacs has several problems with big files. Though, to be more specifically, built-in minor-modes have them. So it depends on whether you run a bleak vanilla emacs without anything, or a mildly comfortable emacs with at least something like fontlock-mode and stuff.

But, 2000 lines are really not that much. Usually problems on my systems start to show at >10k lines.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#46
Very nice last line.

Also, I disagree about the 'lisp makes people selfish'. It may be true at first, but I dearly believe that every long time lisper on earth is totally aware of that and knows where to draw the line. It's been discussed to death early on and regularly since. We all enjoy the freedom to fool depth first into every idiosyncratic itch we think of, but we know that they're most of the time only that. And that others can give different views on a similar problem, yielding a more generic notation/solution by blending all attempts.

It does cost a bit though, for instance scheme lack of standard module (until recently IIUC) forces one to work a bit more, or maybe port by hand. But very often, lisp libs are tiny. I still remember the article from early 2ks about a guy searching for graph libraries in java. Found 3, none of them was good enough, in the end he wrote his own in CL in a day. There's a cost of sharing too.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#47
post #4

using emacs was so revolutionary for me because I had never before thought about building an editor that fit my workflow. Before it was always trying to fit my workflow to fit my editor. The potential in emacs to be anything I wanted it to be was mind blowing.

How did it turn out?

Great. I am still using it to this day. Even when I switch jobs or switch products, I just change Emacs to match my new workflow.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#48
post #39

Earlier quoted context omitted.

For VS Code, it’s like developing for another web browser, your VS Code IDE launches another instance of VS Code with your plugin running, and you can “Refresh” the second instance of VS Code to reload your plugin’s changes. Installing a plugin once developed is of course possible, but as far as I know there’s no hot-reload outside of this Extension Development Host window. Basics at https://code.visualstudio.com/api…

> you can do a heck of a lot with VS Code extensions, enough that I don’t want to install any I don’t trust —they can run programs and never prompt you for permissions Doesn't Emacs have the same issue - you really really have to trust any package you install?

That is true, probably even more so then VS code. Though I never heard of malicious Emacs package. That may because it is such a small attack vector compared to something like VS code.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#49
post #16
post #12

Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow. It’s probably possible today to write an Emacs in a high-performance Lisp. Elisp has no support for concurrency, for example. “Some 359,000 lines of C code comprise its kernel, and 1,637,000 lines of Emacs Lisp take the rest of it.1”

Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. It takes 5 seconds to redraw the visible text after hitting "page up" or "page down". I don't think emacs should be made any slower than it already is.

That is surprising. I open log files all the time with several million lines without issue. If you are having issues try running it in fundamental-mode.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#50
post #28

Can anyone recommend an editor like Emacs that doesn’t use LISP? I find the syntax to be an abomination.

If you use it for a while you get used to it. It's just another programming language.

Second this. The parenthesis look abhorrent because they are foreign, But that is where the real power of lisp resides.
Post reply on HN