Live data from Hacker News

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

chrisdone.com

31–40 of 58 posts

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

#31
post #18
post #10

People who don't know how to program emacs don't get how easy it is to write some code in it to make your life easier. Some say Atom and VSCode also have plugins. That's true, but can you write code to extend some VSCode functionality in a minute? You just go to the scratch buffer, write some code, evalute it and it instantly becomes part of the editor. I don't know if there are other editors which can replicate this…

Can you recommend a good starting-point for learning emacs internals?

A few pointers, from very knowledgeable fellows (warning C code ahead)

- https://nullprogram.com/blog/2014/01/04/

- https://tromey.com/blog/?p=305

- http://emacshorrors.com/

- http://emacsninja.com/

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

#32
post #18
post #10

People who don't know how to program emacs don't get how easy it is to write some code in it to make your life easier. Some say Atom and VSCode also have plugins. That's true, but can you write code to extend some VSCode functionality in a minute? You just go to the scratch buffer, write some code, evalute it and it instantly becomes part of the editor. I don't know if there are other editors which can replicate this…

Can you recommend a good starting-point for learning emacs internals?

I made a tutorial series on emacs 2 years back (hasn't change at all since anyway), the last episode is about exploration: https://mickael.kerjean.me/2017/03/23/emacs-tutorial-series-...

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

#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 can't really represent those machines very well. C was really designed for a specific, restricted kind of architecture, one that is popular today).

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

#34
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.

As someone else has mentioned. Maybe the lines are very long. That is a known problem, and some minor solutions have been proposed, but it is an entrenched problem (in the way data structures handle text), and not one that programmers run into at any rate (unless you open those terrible "one-liner" javascript files).

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

#35
In my opinion, Emacs is the only piece of software that I've ever used that is truly self-documenting. Once you learn about Ctrl+h {c,f,v} you can "lookup" what every key-combination, function and variable does. I don't think I've ever used a piece of software that's close to it in this regard.

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

#37
I use VS Code and in theory I can modify the source code: it should be as simple as editing source code within the developer tools of Chrome.

However the tooling for VS Code is absolutely nothing like the Emacs REPL (however disclaimer: I haven't used Emacs for a very long time)

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

#38
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.

As someone else has mentioned. Maybe the lines are very long. That is a known problem, and some minor solutions have been proposed, but it is an entrenched problem (in the way data structures handle text), and not one that programmers run into at any rate (unless you open those terrible "one-liner" javascript files).

See fooker's reply in this thread. He is using the same setup as I am.

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

#39
post #10

People who don't know how to program emacs don't get how easy it is to write some code in it to make your life easier. Some say Atom and VSCode also have plugins. That's true, but can you write code to extend some VSCode functionality in a minute? You just go to the scratch buffer, write some code, evalute it and it instantly becomes part of the editor. I don't know if there are other editors which can replicate this…

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?

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

#40
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. Emacs is famous for being super customizable. But everything I touched was extremely brittle, and essentially impossible to configure to work as I wanted it to.

1. Wasn't a huge fan of "\star" "\star\star" "\star\star\star" as the headlines. I would prefer "\t\star" "\t\t\star" "\t\t\t\star". Hmm, seems the only way to do this is a hack that changes the leading stars to the same color as my Emacs background. That's kind of hack-y. The rationale I could find for this was to keep a consistent on disk format. I guess that makes sense, though it's not something I care about ... I don't intend on sharing my TODO list (and my understanding is there's no 100% compatible org-mode parser outside of Emacs anyway). Not a big deal, I'll live with it.

2. Agenda view. As I started using org-mode more and more for task management I decided I needed a good task view. I set my own task and project states (nice: simple, works) then I set to work on creating a nice view of all my tasks organized in separate sections (REFILE tasks, active projects, active tasks). Hmm, now it takes multiple seconds to refresh my agenda view. And I have to manually refresh it any time I make a change to any file ... This kinda sucks. Might be a solution for this, never got around to investigating.

3. File structure for my org files. Despite the occasional org-mode article on Hacker News, it's actually pretty hard to find good examples of a full org-mode workflow. When I was actively working on this I found one or two. When writing my org files I kept running in to the odd problem with certain features because of how I was laying out my files. Should there be an empty line after a headline? Are paragraphs separated by empty lines? If you don't do this correctly (and since there's so few examples available, "correctly" is something you have to figure out by trial and error) then certain exporters (pdf, html) don't give correct output, or folding doesn't work.

4. Directory structure of my org files repo. I like being aggressive about breaking things up in to different files. And then organizing these files in to different directories. New project? New directory, new project org file. Let's make a separate file for research. So /Research.org. Unfortunately this butts up with how org-mode assumes you have things organized (which again, you can only really figure out by trial and error when things don't work). Take REFILE for example. It tab completes by file name. But problematically I now have a lot of files with similar names (e.g. Research.org) in different directories. org-refile-use-outline-path sort of fixes this but it's still clunky.

5. Emphasis. The straw that broke the camel's back. All of the above were minor and I kept with org-mode. It sorta worked. But I was annoyed. Eventually I started doing some research that involved quotes where I really wanted to basically highlight phrases or sentences that were important. I figured this would either be built-in to org-mode or easily added in my Emacs conf. I never did find a solution that actually worked. I can underline, italicize, bold, etc, but no highlight (i.e. classic yellow background for text). Apparently org-mode deliberately prevents the end user from adding their own custom emphasis formats in order to have a consistent file format.

At this point I left org-mode and emacs all together and ended up writing my own rich text editor so I could do whatever formatting I wanted. It doesn't do 1% of what org-mode can, but dammit I can highlight in 6 different colors.

I'm disappointed I never got to experience the Emacs nirvana that all these articles describe. Maybe it's just org-mode, but everything I touched seemed extremely brittle. Felt very much like I was forced to do it the org-mode way. It was really disappointing.

Post reply on HN