Hacker News new | past | comments | ask | show | jobs | submit login
Emacs Users Are Like Terry Pratchett’s Igors (2013) (chrisdone.com)
86 points by signa11 26 days ago | hide | past | web | favorite | 57 comments



Emacs is the ultimate example of free software. You really do feel free in emacs, experimenting, tweaking.

Free as in breathing, free as in drinking water. Code is such an integral part of life that it is unthinkable that we cannot have control over it. Emacs gives you control, it gives you freedom.

I am amazed how Stallman got it right and invented on his principles. Thank you Dr. Stallman, thank you.


> Dr. Stallman

rms has a doctorate? Or is this some sort of honorific I've never heard before?


Right, he has multiple honorary doctorates according to Wikipedia.


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


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/get-started/your-first-ext... and you can run automated tests also in that second IDE window.

That said, VS Code isn’t as flexible—there’s a distinction between building VS Code and building an extension, and the two aren’t equivalent. The closest analogy I can think of is developing an old-fashioned XUL Firefox extension vs a new Chrome-style extension. The former used the same building blocks the app used, the latter was intentionally sandboxed and sanitized.

That said, 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, etc. So with great power comes great responsibility ;-)

And it could be argued that in a perfect world, VS Code should have both a live-edit-and-reload experience for plugin development alongside a more formal, sandboxed approach with signing and permissions and everything.


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


> small attack vector

That's irrelevant: what matters is the value of an attack vector. e.g. Bill Gates is a small attack vector.

Attack the high value of some developers assets, or attack the high value of some of the businesses they work for.


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


Not OP, but the Emacs manual is excellent[0] and there's Mastering Emacs[1] and Sacha Chua's blog[2].

Because it's lisp you can inspect just about everything. See an unfamiliar symbol? Put your cursor on it and press M-.

0: launch help from within Emacs

1: https://www.masteringemacs.org/

2: https://sachachua.com/blog/emacs/


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


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/


To digress a bit, on the Lisp curse, and freedom more generally:

In the HyperCard thread on the front page right now (https://news.ycombinator.com/item?id=20550189), someone linked a talk (https://www.youtube.com/watch?v=9nd9DwCdQR0&feature=youtu.be...) on the history of educational software, and one of the presenters said something like, "Some technologies we are simply not mature enough for."

I think this is not a bad description of "the Lisp Curse." I definitely wasn't mature enough for Lisp when I first learned it---high on my knowledge of what was possible, surrounded by myopic fools, as I thought.

But that was years ago. I'm mature enough now. It is possible.

In my consulting work my partner and I have marveled at how managing technology projects is a skill --- learnable, but only with some effort and practice, and carrying relatively heavy requirements of being technically competent and having a context of the business.

That's the skill that's needed, IMO, to make Lisp "work." Lisp itself---and Clojure---are really not complicated languages. My boss teaches them to undergrads and they can be productive fairly quickly. They are complicated when someone has built a crappy, leaky tower of abstractions on them. Recognizing when you're in danger of doing so, and when it's not worth it given other factors (business value, maintainability, etc) is the key.

So I wonder, idly, if metaprogramming---no, really, the meta of programming, like "Don't Call Yourself A Programmer" (https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... ) and "Developer Hegemony" (https://www.amazon.com/Developer-Hegemony-Erik-Dietrich/dp/0... )---might develop some more, esp. among the Lisp communities. When the language is no longer the barrier, you start to realize that other things are.


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


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.


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.


Syntax high-light pays its tool on not so huge files, but I remember opening without slowdowns files with around 100K lines in text mode (mostly log files).

Not exactly related but with Emacs 27 will be distributed the so-long mode that could toggle minor modes that affect redrawing like "font-lock", "visual-line", "whitespace" when files with long lines are opened: https://git.savannah.nongnu.org/cgit/so-long.git/plain/so-lo...


Clearly I meant "toll" not "tool" above...


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.


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.


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.


I was asking for the nature of the file, not the setup.


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.


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.


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.


I lack even a reference for the sorts of things that can be done. How have Emacs users here customized their workflow?


A huge amount is taking preweitten plugins—someone upthread said you should just learn your editor’s existing feature set, and this is true.

But I use Emacs as a mail client—message mode is awesome—and extended it with a procedure to create text/html parts and all the necessary MIME headers. I especially like using that for tables that are readable in monospaces text/plain or as HTML tables. Compare that to a GUI mail editor, which surely defaults to HTML but which probably isn’t going to offer you tabular support.

Let’s see. I have some fine control over white space in here, to meet different collaborator’s guidelines. And that integrates with the magit git front end.

I have a bunch of macros driven by the abbrev autocorrect scheme.

But in reflecting on this, the big important category is “Other”. I write 5-50 line programs, sometimes starting from a macro recording of one run of the core loop, weekly.

Imagine a world where general spreadsheets didn’t exist; you had accounting software but it was all like TurboTax or quickbooks, very hard wired for a purpose. And imagine asking how users of Excel customized their workflows, as they tried to explain that the point was the total flexibility. Emacs is like that for text files.


I'm currently working on an extension to modify the built-in symbolic calculator to display its stack entries in rendered LaTeX--it already has various language modes for displaying its s-expression based formulas, including LaTeX, so this honestly isn't that big of a lift.


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)


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 <PROJECT DIR>/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.


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.


The big issue with elisp is how alien it is to read code in it with so many parens and the tendency by elisp programmers to inline huge gobs of code in function calls.


> the tendency by elisp programmers to inline huge gobs of code in function calls

Observation on point, and ironically it limits the ability for developers to tweak third-party software (what if you want to change some aspect _in the middle_ of the large code gob?)


That's where I found this[0] packages so useful

[0]https://github.com/raxod502/el-patch


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


You could try leo. Definitely inspired by emacs in many ways.

https://www.leoeditor.com/


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.


You could try Edwin, based on Scheme.

Yi, in Haskell.

Good luck.


It is arguable that no such editor exists.

Take away the Lisp and you are already very unlike Emacs.


It's possible to write a language that is arguably a lisp, but without sexprs.

Elixir is one that comes to mind (It has the "big" Lisp things, like hygienic macros).

Actually, Erlangs concurrency model might well work very well for emacs, since you can spawn off hundreds of independent tasks with close to zero overhead, and use all available cores to run them on.


A good point. Sweet-expressions might be an example of such a language implemented as a Lisp reader macro, in fact.

https://dwheeler.com/readable/sweet-expressions.html


(2013)


I wonder how “hackable” Electron editors fit in to this: might they be emacs for the masses?


Someone else[0] has answered your question, I think.

[0] https://news.ycombinator.com/item?id=20551432


It sounds, from this description, like Lisp is similar to Perl - "There's more than one way to do it". i.e. extremely flexible, and the outcome is a lack of coherence, such that my Lisp code might look substantially different from yours, making it a nightmare to maintain.

I'm pretty sure that if I found myself doing development on my editor then this would be a form of procrastination because modifying the editor certainly ain't developing product related functionality. For me it's more effective to ignore or work around failings in my editor, or better yet, invest some time in trying to learn in more depth the functionality that is already present in my IDE that might approximately meet my need.


The codebase is as coherent as the author wants it to be, without the language imposing metaphors like objects or a pure functional style where they're not needed. Lisp won't force you to write bad code, but that means it can't force you to write good code, either: If your Lisp code is incoherent, that's on you.


>> If your Lisp code is incoherent, that's on you.

It's actually on anyone who comes after.

That might be just me, or if the code is public it could be anyone.


The phrase "that's on you" means "it's your fault".




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

Search: