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.
My emacs init checked argv -- 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.
Interesting how things get reinvented every so often:
> 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.
> 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. and
> MILTEN is terminal control software used by both ORVYL and WYLBUR for start/stop terminals.
> 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.
> 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.
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.
These are plugins which are loaded on demand. So if you never use them, then they are not loaded into the platform.
Now I'm one of those strange users. It's not just a text editor.
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.
I was using GhostText and enjoyed it very much. Though it stopped working for me and I could never muster the energy to properly look into it. Nowadays I tend to write longer comments in vim and then copy paste to the browser which can be a bit cumbersome.
- 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.
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.
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.
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.
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.
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
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.
> Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
> People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
Regarding Emacs being an universal UI platform, I wrote a metapost to emacs-devel to celebrate that fact very recently. Indeed, Emacs is the only platform I know which can be used to write programs which work on the terminal and with a GUI toolkit alike. I call that modality-independant.
I see we share a similar view of what Emacs really is (https://www.eigenbahn.com/2020/01/12/emacs-is-no-editor) and enjoyed your piece. Thanks for posting it.
Having the possibility to have a system that "glues" together different functionalities in a coherent way is really something.
And you being a blind person, I can only conceive how even more critical that is.
Disclaimer: While I don't work for GPD I'm a very happy owner of a Win 2 that I use for light gaming and game streaming with Stadia and Geforce Now, and I've started using it for "computery tasks" more and more as I just keep that and my iPad Pro in my backpack - not that I leave the house often these days, though...
Too bad it came along a decade after I ceased to really need the kind of road-warrior sysadmin capability that such a device excels at providing. I'm still glad to have it.
I could type blind too - talking and interacting with someone whilst finishing a sentence with my other hand brain. I miss it so much.
I'm quite surprised to see this got posted and made it to the front page.
I'm a bit late to the party.
Don't hesitate to ask questions, though.
Oh how far we've come since '93.
For example, I often find myself quit Emacs to jump to a different directory just to open a file. I think I am doing this wrong. I have tried Dire/Neotree but those are not providing enough convenience imo.
Do you you a workflow or setup to "live" in emacs? Note: I use pure Emacs and not spacemac or Doom.
That should prompt you to enter a path, which, without any customization, should perform very similar to a shell prompt in terms of using tab for file completions.
A huge improvement to this in my opinion is the use of a completion framework package. I use ivy but helm is also popular and there are others.
The main draw in this case is instead of having to tab through completion candidates, they appear as a vertical list which is updated as you type. It also allows more advanced filtering, for example by regex which I find a lot easier to use than shell completion which only supports prefix.
For example say I want to navigate to a directory called `the-project` but I always forget whether it's named `the-project` or `a-project`, it doesn't matter because I just type `project` and would see `the-project` as an option so I'd navigate to that and select it (using `C-n` and `C-p` to navigate the list).
If that isn't what you're looking for then another option is `emacsclient`  which let's you open files in an already existing Emacs process.
I will leave this here for the small set of people that use both emacs and windows. The 'everything' extension for emacs is really great, instant HD(s) wide file/folder search. If you don't have Everything.exe installed on your windows machine i'd urge you to go try it. (with or without emacs)
As far as emacs integration this is what I use for it. The 2nd function requires the projectile and perspective extensions, it opens a new virtual-desktop-thing inside emacs.
(if (eq system-type 'windows-nt)
(setq everything-cmd "C:\\Program Files\\Everything\\es.exe")
(setq everything-ffap-integration nil)))
(defun open-file-from-anywhere ()
(defun open-file-from-anywhere-in-new-persp-if-in-project ()
(let* ((fpath (everything-find-prompt))
(f-projectile-root (projectile-project-root fpath))
(project-name (projectile-project-name f-projectile-root)))
(message "File is not in a valid project directory")