17 ms·

When I started using Emacs, I didn't think I'd use it much except for org-mode, which was the reason I started learning it. Then, as my usage expanded, I didn't

When I started using Emacs, I didn't think I'd use it much except for org-mode, which was the reason I started learning it. Then, as my usage expanded, I didn't think I'd want to use it for anything beyond org-mode, programming, and core text editing functions. Certainly not email or any of that other foolishness. Flash forward a couple of years and here I am, looking into making Emacs into my actual X window manager [1] so that I finally use it for everything, period. I recognize that the practical arguments in favor of doing this are limited at best. Sometimes people "Emacs evangelize" by talking about how living entirely within the program allows them to have one text editing paradigm for everything in their lives; even though that is indeed nice, non-users aren't wrong to be skeptical about the practical benefits, given the amount of effort that will probably be involved. The secret is that for many Emacs users, it's just plain fun -- hence the things shown in this article, and also EXWM. [1] https://github.com/ch11ng/exwm https://github.com/ch11ng/exwm

AlanYx 6y ago
IMHO using Emacs as your X window manager isn't particularly strange -- conceptually at least, it seems more natural than the Chromebook model, where people are essentially using a web browser as a window manager.
basicneo 6y ago
+1. For many years I heard strange things from Emacs users about how they wanted to do everything in Emacs. It's just a text editor! Now I'm one of those strange users. It's not just a text editor.
- deleted 6y ago
  [deleted]
- taeric 6y ago
  I view it more as it being evidence that relying on text interactions is more powerful than folks acknowledge. It can be slower, for dinner things, but usually is more resilient than binary integrations. If only because it is easy to see what it was trying to do.
slmjkdbtl 6y ago
I love the idea of a huge monolith program that you "live in", although it's contradictory to the popular philosophy "do one thing and do it well". A program that one live in is a perfect example of software as a manifest, in this case a manifest of one's personal digital lifestyle. I hope there's more people doing this, but in a more personal way, however the time and mind commitment required is huge.
- a_e_k 6y ago
  I like to think of Emacs more as a platform for a collection of Emacs lisp programs living in a shared process space. It's not unlike what I've seen of Smalltalk (though I don't use that myself): you wouldn't necessarily think of the Smalltalk VM and image as a huge monolith program.
- bitwize 6y ago
  Emacs integrates well with Unix software that does one thing and does it well. You can even think of it as a buffering super shell with Lisp programmability, and use it to integrate and automate complicated tasks and put a usable UI on them.
  - slmjkdbtl 6y ago
    I'm saying it's not because it has stuff like text editor, games even email client built-in (need confirmation never seriously used emacs), if it's only a scripting + text UI engine and offering all other apps as optional plugins then I'd agree it's "doing one thing".
    - dmortin 6y ago
      > games even email client built-in These are plugins which are loaded on demand. So if you never use them, then they are not loaded into the platform.
    - bitwize 6y ago
      I'd say facilities for text editing (buffers, kill rings, etc.) are built in, but nearly everything else -- the different modes for programming languages, games, mail, web, and IRC clients, etc, are all in Emacs Lisp.
alpaca128 6y ago
My situation is similar but with Vim. I have a comfortable setup that combines a terminal multiplexer and Vim, and that lets me do almost anything text-based within the same environment. In the recent year I also starting doing some of my own custom scripting and syntax files and it's been fun. Also with Firefox plugins it's possible to use NeoVim as text editing backend on websites which is nice. I'd prefer a lightweight terminal browser for certain use cases, but I haven't found one that can convincingly handle the cluttered web of today. Emacs' eww seems to be more consistent there.
- pmoriarty 6y ago
  Can you: - surf the web in vim? - read/write your email in vim? - read RSS feeds in vim? - IRC from vim? People do these regularly in Emacs. Emacs just offers a far greater range of things you can do in it than you can in vim.
  - agumonkey 6y ago
    vi has never held the concentric view of life lisp thus emacs did.
  - alpaca128 6y ago
    I could do all these things beside Vim in the same terminal multiplexer instance or within Vim's terminal buffer. You have to understand that I'm not impressed by the number of features in a program but how it fits my workflow. Emacs just doesn't cut it for me despite multiple attempts, and Vim does.
    - pmoriarty 6y ago
      Having it beside your editor is just not nearly as good. It's hard to get across how great it is to have everything you use totally integrated in to one system, and everything programmable and extensible in the same easy and powerful language that the whole integrated system uses, as Emacs does with all of its packages in Lisp. A tightly integrated system minimizes mental context switching and having to deal an hodgepodge of different languages, configuration systems, and help systems. To extend or fix an Emacs package, I don't have to jump down in to C for one thing, Python for another, Rust for another, OCaml or Haskell of another, and Javascript for yet another. It's a rare person who knows all of these languages and is expert enough in them to be able to tweak, modify or extend all the applications they use that are written in them. In Emacs you just have to know Lisp, and all of the applications written for Emacs are open to you. That's hugely powerful. If you want these Emacs applications to behave a different way or integrate in to your setup in a different way from how they were designed, that's super easy to do compared to doing the same thing outside of Emacs, and the workflow you can develop in a system that you designed to be just the way you want can be extremely streamlined and efficient. I'm sorry to hear that trying Emacs hasn't worked out for you. I'll just say that I used vi and vim for decades before switching to Emacs, and while it did take a lot of work to set up Emacs the way I wanted, in a very vim-like fashion using Evil, it was very much worth it, and now my Emacs setup could do many things that my vim setup never could and probably never will.
anyonecancode 6y ago
Picked up doom-emacs last month for org-mode, and am slowly getting into it. Then a couple of weeks ago started using beancount, with the emacs mode. So far I'm still far more comfortable in vim and the terminal -- even, for instance, switching back to my terminal to do `bean-check` rather than doing it within emacs itself. I could see myself keeping my use of emacs pretty limited like this indefinitely, and still finding it useful - I'm unlikely to give up these uses of emacs. Maybe over a long enough time horizon emacs will feel a bit less strange to me and I'll find more places it fits a niche, or maybe not. Either way, it's a nice addition to my tool set, and I'll be curious to see where I land with in in a year or so.
- crankyoldcrank 6y ago
  In Emacs, add (start-server) to your config. Then in your shell rc file: alias vim='emacsclient -a/usr/bin/vim -nw' Now if emacs is running you'll get emacs in the terminal when you use the command vim to open a file. If it's not running, vim opens it instead. Super slick for converts from the vim workflow
  - Jtsummers 6y ago
    I think using the `--daemon` flag is better. Especially because you can then name the server session. I do this with an unnamed daemon for general use, but a project or language name for other efforts. It helps keep my configurations and buffers cleanly separated based on context.
- tarboreus 6y ago
  You'll probably want to look into using Emacs as a server. Emacs creeps up on you, you'll be surprised looking back on this comment in a year.
gumby 6y ago
When I started using Unix in '85 or so I didn't find it especially user friendly so the first program I wrote was a little trampoline alternative to the login shell (/bin/sh in those days) that exec'd emacs as the terminal's controlling process. At least that way I could be an a more familiar environment. My emacs init checked argv[0] -- if the name started with '-' then it asked if I intended to log out before exiting. That was on the original GNU machine -- yes, when the FSF's entire computing resource was an unused VAX 750 that nobody wanted and that had been purchased and installed by someone unknown for reasons also unknown and was just taking up space in a small machine room.
- msla 6y ago
  > When I started using Unix in '85 or so I didn't find it especially user friendly so the first program I wrote was a little trampoline alternative to the login shell (/bin/sh in those days) that exec'd emacs as the terminal's controlling process. At least that way I could be an a more familiar environment. Interesting how things get reinvented every so often: https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR > The names ORVYL and WYLBUR are often used interchangeably, but: > ORVYL is a timesharing monitor that supports a file system, command language, program execution and debugging, and provides supervisor services.[1] > WYLBUR is a text editor, word processor,[a] job submission and retrieval, and e-mail program designed to work in conjunction with ORVYL or with IBM's OS/360, SVS, and MVS operating systems.[2] and > MILTEN is terminal control software used by both ORVYL and WYLBUR for start/stop terminals.[1] > WYLBUR is not a full standalone operating system in the mold of Dartmouth Time Sharing System (DTSS) or Unix. Instead it runs on top of an IBM batch operating system (OS/360, SVS, MVS). It takes the form of an editor with a Remote Job Entry system and thus has much the same relationship to the IBM operating systems as Emacs does to Unix. For these reasons WYLBUR is often thought of as a text editor rather than a time-sharing system. However, whereas Unix does not need Emacs to provide text editing services, IBM's operating systems originally needed WYLBUR. Later innovations such as IBM's Time Sharing Option (TSO) made WYLBUR less relevant for IBM users and gradually replaced it. [snip] > ORVYL and WYLBUR first became available in 1967–68, before TSS/360, TSO, or any other official time-sharing solution from IBM. This was roughly the same time that third-party time-sharing systems such as MTS became available and the under the radar development effort of CP-67 at IBM's own Cambridge Scientific Center took place. WYLBUR had the additional advantage that it could be used in conjunction with IBM's mainstream operating system, OS/360. "Text editor as a primary user interface" is a design idea which pops up every so often. People pushing modern Emacs into being their widow manager (exwm) is a new reinvention.
generalizations 6y ago
> for many Emacs users, it's just plain fun That's what I've come to realize, which is why I don't think I'll ever use emacs. For me, the effort involved would be very not-fun: I just want a tool that works, with a minimum of ongoing effort and mental overhead. If emacs could be made to fit that, I'd go for it.

AlanYx 6y ago

IMHO using Emacs as your X window manager isn't particularly strange -- conceptually at least, it seems more natural than the Chromebook model, where people are essentially using a web browser as a window manager.

basicneo 6y ago

+1. For many years I heard strange things from Emacs users about how they wanted to do everything in Emacs. It's just a text editor! Now I'm one of those strange users. It's not just a text editor.

deleted 6y ago
[deleted]
taeric 6y ago
I view it more as it being evidence that relying on text interactions is more powerful than folks acknowledge. It can be slower, for dinner things, but usually is more resilient than binary integrations. If only because it is easy to see what it was trying to do.

slmjkdbtl 6y ago

I love the idea of a huge monolith program that you "live in", although it's contradictory to the popular philosophy "do one thing and do it well". A program that one live in is a perfect example of software as a manifest, in this case a manifest of one's personal digital lifestyle. I hope there's more people doing this, but in a more personal way, however the time and mind commitment required is huge.

a_e_k 6y ago
I like to think of Emacs more as a platform for a collection of Emacs lisp programs living in a shared process space. It's not unlike what I've seen of Smalltalk (though I don't use that myself): you wouldn't necessarily think of the Smalltalk VM and image as a huge monolith program.
bitwize 6y ago
Emacs integrates well with Unix software that does one thing and does it well. You can even think of it as a buffering super shell with Lisp programmability, and use it to integrate and automate complicated tasks and put a usable UI on them.
- slmjkdbtl 6y ago
  I'm saying it's not because it has stuff like text editor, games even email client built-in (need confirmation never seriously used emacs), if it's only a scripting + text UI engine and offering all other apps as optional plugins then I'd agree it's "doing one thing".
  - dmortin 6y ago
    > games even email client built-in These are plugins which are loaded on demand. So if you never use them, then they are not loaded into the platform.
  - bitwize 6y ago
    I'd say facilities for text editing (buffers, kill rings, etc.) are built in, but nearly everything else -- the different modes for programming languages, games, mail, web, and IRC clients, etc, are all in Emacs Lisp.

alpaca128 6y ago

My situation is similar but with Vim. I have a comfortable setup that combines a terminal multiplexer and Vim, and that lets me do almost anything text-based within the same environment. In the recent year I also starting doing some of my own custom scripting and syntax files and it's been fun. Also with Firefox plugins it's possible to use NeoVim as text editing backend on websites which is nice. I'd prefer a lightweight terminal browser for certain use cases, but I haven't found one that can convincingly handle the cluttered web of today. Emacs' eww seems to be more consistent there.

pmoriarty 6y ago
Can you: - surf the web in vim? - read/write your email in vim? - read RSS feeds in vim? - IRC from vim? People do these regularly in Emacs. Emacs just offers a far greater range of things you can do in it than you can in vim.
- agumonkey 6y ago
  vi has never held the concentric view of life lisp thus emacs did.
- alpaca128 6y ago
  I could do all these things beside Vim in the same terminal multiplexer instance or within Vim's terminal buffer. You have to understand that I'm not impressed by the number of features in a program but how it fits my workflow. Emacs just doesn't cut it for me despite multiple attempts, and Vim does.
  - pmoriarty 6y ago
    Having it beside your editor is just not nearly as good. It's hard to get across how great it is to have everything you use totally integrated in to one system, and everything programmable and extensible in the same easy and powerful language that the whole integrated system uses, as Emacs does with all of its packages in Lisp. A tightly integrated system minimizes mental context switching and having to deal an hodgepodge of different languages, configuration systems, and help systems. To extend or fix an Emacs package, I don't have to jump down in to C for one thing, Python for another, Rust for another, OCaml or Haskell of another, and Javascript for yet another. It's a rare person who knows all of these languages and is expert enough in them to be able to tweak, modify or extend all the applications they use that are written in them. In Emacs you just have to know Lisp, and all of the applications written for Emacs are open to you. That's hugely powerful. If you want these Emacs applications to behave a different way or integrate in to your setup in a different way from how they were designed, that's super easy to do compared to doing the same thing outside of Emacs, and the workflow you can develop in a system that you designed to be just the way you want can be extremely streamlined and efficient. I'm sorry to hear that trying Emacs hasn't worked out for you. I'll just say that I used vi and vim for decades before switching to Emacs, and while it did take a lot of work to set up Emacs the way I wanted, in a very vim-like fashion using Evil, it was very much worth it, and now my Emacs setup could do many things that my vim setup never could and probably never will.

anyonecancode 6y ago

Picked up doom-emacs last month for org-mode, and am slowly getting into it. Then a couple of weeks ago started using beancount, with the emacs mode. So far I'm still far more comfortable in vim and the terminal -- even, for instance, switching back to my terminal to do `bean-check` rather than doing it within emacs itself. I could see myself keeping my use of emacs pretty limited like this indefinitely, and still finding it useful - I'm unlikely to give up these uses of emacs. Maybe over a long enough time horizon emacs will feel a bit less strange to me and I'll find more places it fits a niche, or maybe not. Either way, it's a nice addition to my tool set, and I'll be curious to see where I land with in in a year or so.

crankyoldcrank 6y ago
In Emacs, add (start-server) to your config. Then in your shell rc file: alias vim='emacsclient -a/usr/bin/vim -nw' Now if emacs is running you'll get emacs in the terminal when you use the command vim to open a file. If it's not running, vim opens it instead. Super slick for converts from the vim workflow
- Jtsummers 6y ago
  I think using the `--daemon` flag is better. Especially because you can then name the server session. I do this with an unnamed daemon for general use, but a project or language name for other efforts. It helps keep my configurations and buffers cleanly separated based on context.
tarboreus 6y ago
You'll probably want to look into using Emacs as a server. Emacs creeps up on you, you'll be surprised looking back on this comment in a year.

gumby 6y ago

When I started using Unix in '85 or so I didn't find it especially user friendly so the first program I wrote was a little trampoline alternative to the login shell (/bin/sh in those days) that exec'd emacs as the terminal's controlling process. At least that way I could be an a more familiar environment. My emacs init checked argv[0] -- if the name started with '-' then it asked if I intended to log out before exiting. That was on the original GNU machine -- yes, when the FSF's entire computing resource was an unused VAX 750 that nobody wanted and that had been purchased and installed by someone unknown for reasons also unknown and was just taking up space in a small machine room.

msla 6y ago
> When I started using Unix in '85 or so I didn't find it especially user friendly so the first program I wrote was a little trampoline alternative to the login shell (/bin/sh in those days) that exec'd emacs as the terminal's controlling process. At least that way I could be an a more familiar environment. Interesting how things get reinvented every so often: https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR > The names ORVYL and WYLBUR are often used interchangeably, but: > ORVYL is a timesharing monitor that supports a file system, command language, program execution and debugging, and provides supervisor services.[1] > WYLBUR is a text editor, word processor,[a] job submission and retrieval, and e-mail program designed to work in conjunction with ORVYL or with IBM's OS/360, SVS, and MVS operating systems.[2] and > MILTEN is terminal control software used by both ORVYL and WYLBUR for start/stop terminals.[1] > WYLBUR is not a full standalone operating system in the mold of Dartmouth Time Sharing System (DTSS) or Unix. Instead it runs on top of an IBM batch operating system (OS/360, SVS, MVS). It takes the form of an editor with a Remote Job Entry system and thus has much the same relationship to the IBM operating systems as Emacs does to Unix. For these reasons WYLBUR is often thought of as a text editor rather than a time-sharing system. However, whereas Unix does not need Emacs to provide text editing services, IBM's operating systems originally needed WYLBUR. Later innovations such as IBM's Time Sharing Option (TSO) made WYLBUR less relevant for IBM users and gradually replaced it. [snip] > ORVYL and WYLBUR first became available in 1967–68, before TSS/360, TSO, or any other official time-sharing solution from IBM. This was roughly the same time that third-party time-sharing systems such as MTS became available and the under the radar development effort of CP-67 at IBM's own Cambridge Scientific Center took place. WYLBUR had the additional advantage that it could be used in conjunction with IBM's mainstream operating system, OS/360. "Text editor as a primary user interface" is a design idea which pops up every so often. People pushing modern Emacs into being their widow manager (exwm) is a new reinvention.

generalizations 6y ago

> for many Emacs users, it's just plain fun That's what I've come to realize, which is why I don't think I'll ever use emacs. For me, the effort involved would be very not-fun: I just want a tool that works, with a minimum of ongoing effort and mental overhead. If emacs could be made to fit that, I'd go for it.