8 votes

Emacs Writing Studio — A comprehensive guide for writers seeking to streamline their workflow using Emacs

4 comments

  1. BeanBurrito
    Link
    I was a huge EMACS fan in college. I even belonged to the Usenet group alt.religion.emacs. :-) I can't either. However I think it is a beautiful thing that someone who enjoys a piece of software...

    I was a huge EMACS fan in college. I even belonged to the Usenet group alt.religion.emacs. :-)

    But I can't for the life of me understand why someone would regress to the age of a text-based interface.

    I can't either. However I think it is a beautiful thing that someone who enjoys a piece of software and a style of doing things from yesteryear can indulge themselves by creating a project like this.

    While this book, and old-school purists, seem to think that modern word processors, research tools, and other applications get in the way of writers,

    I haven't needed to use word processing software in a serious way since college. I think modern word processors do get in the way of writers. It is much easier though to do a web search on how to turn the automatic crap off than to relearn EMACS.

    3 votes
  2. hungariantoast
    Link
    Author's announcement on /r/emacs: https://www.reddit.com/r/emacs/comments/1f5ebq0/emacs_writing_studio/ GitHub repository that includes the full text and source code of the book, and the book's...

    Author's announcement on /r/emacs:

    https://www.reddit.com/r/emacs/comments/1f5ebq0/emacs_writing_studio/

    GitHub repository that includes the full text and source code of the book, and the book's example Emacs configuration:

    https://github.com/pprevos/emacs-writing-studio

    You can actually use that repository's code to compile your own EPUB or PDF of the book if you want

    2 votes
  3. [2]
    LetterCounter
    Link
    I looked through the Github version of the book because, while this does interest me, I had a bad feeling. Sure enough, chapter 3 (the first real chapter after both the introduction and why emacs...

    I looked through the Github version of the book because, while this does interest me, I had a bad feeling.

    Sure enough, chapter 3 (the first real chapter after both the introduction and why emacs chapters) starts by info dumping about buffers, then moves on to several keyboard shortcuts using shortened terminology for each.

    Sure, I can get behind "C" standing for "Control", but "M" standing for "Alt"? Then this paragragh, which got me to stop reading altogether:

    Each modifier key has an abbreviation, as shown in table tab-modifier-keys. You can combine modifier keys, occasionally leading to awkward combinations, such as C-M-S-a (Control, Alt and Shift a), which requires the nimble fingers of a sleight-of-hand artist to execute smoothly. The shift modifier is usually not indicated because C-M-A is the same as C-M-S-a. The escape key can also act as a modifier key. Pressing escape once is the same as holding the meta key. So typing <esc>-x is the same as M-x.

    Look, I consider myself a nerdy computer guy. So does most of my family. I know how to program, use game engines, and can adapt to any software you throw at me. I work with ERP systems daily for a living.

    But I can't for the life of me understand why someone would regress to the age of a text-based interface. Modern UI exists for a reason. While this book, and old-school purists, seem to think that modern word processors, research tools, and other applications get in the way of writers, there is something else that gets in the way too: learning how to be creative using tools written before UI design existed as a career.

    Programmers are usually not the best at UI design. While they are great at designing systems, like emacs, I do not want to learn the entire mental shift that emacs would require, even if, somehow, it made me more efficient as a writer.

    I'm not trying to be overly dramatic, but if the goal of this resource is to onboard existing writers into this ecosystem, I think it will fail. The promise is not attractive enough to justify the effort.

    I do hope this guide is useful for others, I just can't see how it would work for me.

    1 vote
    1. hungariantoast
      Link Parent
      That's because there used to actually be a Meta key. In fact, back in 1976, when the earliest versions of Emacs were written, the keyboards they were using at the MIT-AI lab didn't even have an...

      but "M" standing for "Alt"?

      That's because there used to actually be a Meta key. In fact, back in 1976, when the earliest versions of Emacs were written, the keyboards they were using at the MIT-AI lab didn't even have an Alt key. That came later.

      So using "meta" instead of "alt" is an "archaism"? I think that's the right word.

      But I can't for the life of me understand why someone would regress to the age of a text-based interface

      Because it isn't a regression. Text-based interfaces aren't automatically worse or better than graphical interfaces.

      And just to be clear, I have never typed C-M-a in my entire life. That, or any other "double modifier" keybinding, is not something you would use regularly in Emacs.

      I was curious, so I checked all of the keybinds that start with C-M, or C-S, or any other combination of two or more modifier keys. The only one I have ever actually used is C-S-s, and it's a custom keybind that I bound for myself literally last night.

      (I bound it to consult-imenu, for any curious Emacsers reading this, because I've been experimenting with outlining my configuration file, and (setopt use-package-enable-imenu-support t) adds use-package declarations to imenu's search list.)


      If you did happen to need or want to use that keybind regularly, for whatever reason, then Emacs makes it trivial to discover what command that keybind calls. With that information, you could then rebind that command to any keybind you want. For example:

      If we want to know what C-M-a does, then we can press C-h to bring up the help buffer. From here we have a bunch of options, but we want to press k to run describe-key. After that, we type whatever keybind we are interested in learning about (C-M-a), and Emacs will open a help buffer with some info for us:

      https://i.horizon.pics/voXGm7F1CH.png

      From there we can see that C-M-a runs the command beginning-of-defun, and that command is also mapped to a few other keybinds as well. We can read about what the command does and how to use it interactively, along with a lot of other documentation and links to other help pages, but we already have what we came for.

      To rebind beginning-of-defun permanently, we would put something like the following line in our init.el file:

      (global-set-key (kbd "C-c C-a") #'beginning-of-defun)

      I say "something like" that line because first, you don't have to bind beginning-of-defun to C-c C-a, you could bind it to whatever keybind you want. Second, in true Emacs fashion, there are a bunch of different ways we can bind a key. This is just the most popular way.

      I'd also like to note that the command beginning-of-defun is specific to programming. It does not have any use when writing text. Knowing that, we could do some fancy stuff, like not rebind the command to C-c C-a globally, but instead only when we are writing code. So that keybind could do one thing when we are in a Lisp buffer writing code, but do another thing when we are in a Markdown buffer writing Tildes comments.


      I do not want to learn the entire mental shift that emacs would require, even if, somehow, it made me more efficient as a writer.

      That's really what it comes down to: whether the effort you put into learning and customizing Emacs will be worth it compared to the functionality you will get out of the editor.

      For me, that makes Emacs an obvious choice. I don't use it for literally everything like some people, but for programming, taking notes, and writing, it has very much been worth it for me.

      I'm not going to pretend like the default keybinds aren't strange though. It's not even that they're archaic (they are), it's that they're almost unique and not found anywhere else. That uniqueness, more than anything else, makes them difficult to learn. I wrote a comment on /r/emacs recently about my thoughts on the keybinds:

      I'm still a fairly recent Emacs convert, from Visual Studio Code. The native Emacs keybindings were, by far, the biggest obstacle for me. I've been doing all of my work in Emacs full-time since the start of 2024, and by now I am definitely used to, and even prefer, the native Emacs keybindings, but they were a real struggle to learn in the beginning.

      So yeah, the keybinds are tough to get used to, but I also prefer them these days, and I think they're better than the typical keyboard shortcuts pretty much any other text editor or software uses. In that same Reddit post, another person does a pretty good job of laying out why:

      There seems to be a common misunderstanding about some of Emacs's default key bindings. Because many people are used to CUA-style bindings, like C-n for "new file", and C-s for "save file", Emacs's bindings seem strange. But they are actually quite sensible once you realize that, for these kinds of bindings, there are two basic levels:

      1. editing/movement commands that operate within the current buffer, and

      2. for lack of a better description, commands that relate buffers to the external system.

      Saving a buffer to a file or opening a file in a new buffer are common actions, but they are less frequently taken than actions that operate within a buffer, like editing and movement, so Emacs's bindings prioritize the more frequently taken actions. For example, C-n is "next line", not "open new buffer"; C-s is "search," not "save this buffer." The less frequent actions, like saving and opening buffers, are placed behind a prefix, C-x; you could think of it as a mnemonic like "external" or "extra."

      So, in a sense, CUA-style bindings are somewhat wasteful in that they spend valuable, simple bindings like C-n and C-s on actions that are only taken when beginning and ending an editing session, rather than actions that are taken many times within a session.

      The other ostensible anomalies are mostly relics of terminology, e.g. "find file" instead of "open file," "kill" instead of "cut", "yank" instead of "paste." While some of these terms seem more natural than others, they are still just jargon, and every user has to learn some of that to use any system (e.g. there are no actual scissors nor paste involved, and analogies to paper seem more like relics as time passes; even the classic floppy disk icon for the saving action is fading away, as many users have never seen one).

      So I would encourage users (and developers of various published configurations) to not spend much effort "papering over" the Emacs default key bindings. Instead, encourage users to learn a few basics (so they can always use emacs -q), and show users how to customize bindings to their own preferences. There's not a lot of value in making Emacs's bindings more like those in other software, because bindings are not the main reason to use Emacs. And if bindings are holding a user back from using Emacs, they might as well use a different editor, unless and until they come to desire what Emacs has to offer.

      Of course, this is a battle that has already been lost. Emacs-style keybinds probably won't ever re-enter popular use, and most people who learn about Emacs keybinds will probably have an immediate reaction along the lines of "that's weird, I don't like it". I don't think that's the end of the world, and I don't think it's a good reason for Emacs to give up its keybinds. Not all software should be written with the lowest common denominator of user in mind.

      So, I won't pretend like getting started with Emacs is easy, or that using Emacs for writing is easier than Microsoft Word or Scrivenver or whatever, but I will die on the hill that it is better.


      Recently, another person on Tildes asked for advice on getting started with Emacs, including for writing novels. In my comment on that post, I shared a lot of additional thoughts about Emacs. You can read it here, if interested:

      https://tildes.net/~comp/1hkw/thinking_of_getting_into_emacs_any_advice#comment-d6id

      4 votes