Emacs As Operating System | Hacker News Reader

Emacs As Operating System

c2.com

91 pointsfogus86 comments

Friend gave me this link once: http://www.informatimago.com/linux/emacs-on-user-mode-linux.... - Emacs standing alone on a Linux Kernel.

BTW. you can get a pretty good Emacs-as-an-OS feel with the combo of Emacs, Conkeror [0] and StumpWM [1]. They are all extremely extensible (via Emacs Lisp, JavaScript and Common Lisp, respectively) and can be even made to talk to each other.

[0] - http://conkeror.org/

[1] - http://www.nongnu.org/stumpwm/

In a similar fashion boot-to-guile : http://lists.gnu.org/archive/html/guile-user/2013-02/msg0013...

you can get a pretty good Emacs-as-an-OS feel with the combo of Emacs, Conkeror, and StumpWM

That is the setup that I use at home, and it. is. GLORIOUS.*

*YMMV

I did that for a while, but now use wmii instead of StumpWM.

Unfortunately as far as I can tell it's no longer possible to compile recent Emacs versions statically. Would love to be proven wrong on that point; I could have missed something due to not knowing the first thing about autotools.

> BTW. you can get a pretty good Emacs-as-an-OS feel with the combo of Emacs, Conkeror [0] and StumpWM [1].

This sort of setup is exactly what makes me, a Vim user, think I may have made a mistake by not picking up Emacs instead.

Have you tried pentadactyl? wmii has vim keybindings too.

Sure, it's not the same as emacs OS, but it does feel like at least vim-keys-everywhere.

This sort of setup is exactly what makes me, a Vim user, absolutely sure I made the correct decision by not picking up Emacs instead. :)

I love Vim so much but I sure wish it had a proper scripting language without requiring me to recompile the whole binary to get partial functionality.

Has anyone used Vile? I tried to compile it once and it looked to be quite onerous to fix all of Clang's whinging. Evil?

I think evil mode in emacs is probably the best bet. However I've messed around with elisp a bit in the past though and I can't say I am thrilled enough with it to make the jump. I wish one of the projects to get Emacs going with a scheme would get off the ground...

If mzscheme/racket scripting support for Vim were given the love that python support is getting instead, that would please me immensely. It seems nobody is using that though.

One can use Python, Lua, Ruby, and a bunch of other programming languages to write VIM scripts. At least on ArchLinux, the vim binary comes with support enabled for these scripting languages.

About a month ago I heard about evil-mode in emacs and gave it a shot. It will allow you to by-pass much of the 'boilerplate' learning curve (how to move around inside and between buffers and edit, etc) so you can just focus on the cool aspects of emacs that vi doesn't do as well. Spent the first week or so setting emacs up more or less with the same features and shortcuts I got used to in my customized vim environment and haven't looked back. Have your cake and eat it too. :)

In case anyone is interested here is a HN page-mode for Conkeror I wrote a while back: https://github.com/legumbre/hackernews-mode It makes the site a bit easier to navigate.

Thanks for mentioning Conkeror. I just installed it (on Windows) and am enjoying it very much. I keep my Emacs 80 characters wide so it takes up only half the screen. Now I have Conkeror taking up the other half and Alt-Tab between the two and I can do most things without touching the mouse. Having the two using common key maps really reduces mental strain!

Using Emacs and Conkeror, with Herbstluftwm.

Conkeror was what tipped everything for me: Having been used to gui apps for a long time, my continued use of gui browsers kept me in some kind of limbo. Learned just enough of Emacs to get things done but never going whole hog in learning its shortcuts mainly because I was still relying on mouse clicks on things like the browser. With Conkeror, those shortcuts work well on both my non-gui emacs setup as well as the browser. It's been a great working environment.

Re: conkeror, I keep hoping the lazy web will take Shane Celis's emacsy and webkit proof of concept[0] and make a scheme-based emacs-like browser.

[0]https://github.com/shanecelis/emacsy/blob/master/README.md

there are all kinds of random shitty pages on c2.com.

Emacs is an editor extensible in Lisp. Nothing more. Just like Autocad is a cad program extensible in Lisp. Autocad is also no Lisp OS. Just like Quicksilver is a publishing program extensible in Lisp. It's still no OS. Just like Audacity is a sound editor extensible in Lisp. Still no OS.

An OS is Movitz. Written in Lisp. Runs on Intel and talks to the hardware. Talks to the graphics card. Keyboard. Network card.

Please, not every shitty Lisp interpreter which can print to the screen and take user input is an operating system. Not every Lisp program which can send mail is an operating system.

How do you know that some Lisp is actually an operating system? A good rule of thumb is this: Is the network stack talking to the ethernet interface written in Lisp? Is the file system and the block level interface to the disk written in Lisp? Is the routine which formats the disk written in Lisp? Is the routine which puts a file system onto a blank disk written in Lisp? If that's the case, then you have a winner. Then it looks like it is a Lisp OS.

> Emacs is an editor extensible in Lisp. Nothing more.

I disagree.

> Please, not every shitty Lisp interpreter which can print to the screen and take user input is an operating system. Not every Lisp program which can send mail is an operating system.

I agree with that point.

Calling Emacs an OS is dubious, it certainly isn't a general purpose OS, and won't run on real hardware. But, let me make the case that Emacs is an OS.

Emacs has two parts, the C part, and the Emacs Lisp part.

The C part isn't just a Lisp interpreter, it is a Lisp Machine emulator. It doesn't particularly resemble any of the real Lisp machines. The TCP, Keyboard/Mouse, display support, and filesystem are done at the hardware level (the operations to work with these things are among the primitive operations provided by the hardware). Of these, the display being handled by the hardware isn't particularly uncommon, historically; the filesystem is a little stranger.

The Lisp part of Emacs is the operating system that runs on that emulated hardware. It's not a particularly powerful OS, it not a multi-tasking system. It has many packages available for it (though not until recently was there a official package manager). It has reasonably powerful IPC mechanisms. It has shells, mail clients (MUAs and MSAs), web browsers, web servers and more, all written entirely in Emacs Lisp.

My might say "but a lot of that is being done by the host operating system!" Sure, some of it is, but all of it is sufficiently low level. If you wanted to share the filesystem with another OS running in a VM, you might do it by sharing it as a network filesystem; this is necessary when the VM OS is not designed around running in a VM. However, because Emacs OS will always be running in the Emacs VM, we can optimize it by having the Emacs VM include processor features mapping the native OS, and have the Emacs OS be aware of them. It would be slower and more code to do that all over the network.

Considering that you can't even write an OS kernel in pure C (Linux has a lot of inline asm IIRC), writing one in Lisp seems like a fairly unrealistic, slightly weird dream.

But "Operating System" is being used ambiguously. Can Emacs be an OS kernel? Um, no. Can Emacs be a shell/UI replacement? Yes, I think so. The discussion appears to be partly about that.

> writing one OS in Lisp seems like a fairly unrealistic, slightly weird dream.

It's not - it actually was done[1]. There were OSes written in other high-level languages, like Smalltalk and Forth (which may not be "high-level", but at least it's higher level than C).

[1] http://en.wikipedia.org/wiki/Lisp_machine

I'm not sure I'd classify Forth as higher level than C; in many ways, it operates on abstractions more akin to assembler. In every way, it's really, really strange.

Agreed. Typeless, completely unsafe, treats RAM as a contiguous byte array with a dictionary growing one way and data stack growing the other, allows using the return stack as scratch space... it's very asm-ish.

It is a very good way of managing complexity, though, at the level you would write a program in assembly. And higher-level stack languages (such as Factor) bring that same degree of complexity management to application-land.

It might not be the best or most efficient way, and you might not be able to access all the features of your hardware but its certainly possible to write an OS kernal in pure C. We even did in our Operating Systems class. We did use exactly one GCC extension to C that made things a lot easier for us, but we could have used setjmp/longjmp instead if that extension hadn't been available. Since the machines that real Lisp OSes were made for were often designed as a Lisp target, I don't see any reason they couldn't be pure Lisp.

Interesting, I thought it might be pretty hard to do some things efficiently without inline asm.

Who says Lisp has no inline asm?

To your first point, that depends on your target architecture. On a Symbolics (and TI Explorer, LMI, Xerox D-machine, etc), there is no Unix-ish "asm layer" communicating that last inch to the bare metal. The "assembly language" of these was Lisp primitives and once the microcode loaded, it was all lisp from there. In fact, on the Xerox D-machines you loaded one microcode and got a Lisp machine, a different microcode and got a Smalltalk machine, or a Mesa/Cedar machine. Nifty stuff, from The Before Time, when we were still fundamentally innovating hardware architectures and not figuring out how to make x86 go faster.

Definitely with you on the second point.

A nitpick:

AutoLisp is far less powerful than elisp - e.g. AutoLisp has no macros. It also ceased being enhanced many years ago, while elisp rolls ever onward to the point where it now includes lexical scoping.

A remark because writing my nitpick got me going:

The degree to which Emacs is an OS depends on a person's definition of OS - if it is the primary means of interacting with the computer from the user's chair then Emacs looks more like an OS. On the other hand, if we start from a more formal stance, then it looks less like one.

Pretty pictures aside, how much more or less of an OS is Emacs than Chrome, and if different, in what fundamental ways?

How different is Chrome running on a VM on a Linux box from Emacs running on the same box?

So for someone who is writing office document, Microsoft Word is the OS?

I think your definition attempt renders the term Operating System useless.

We have pretty good definitions of 'operating system' already, no need to invent new useless ones.

The popular packages are properly described as "GNU/Linux." That we deem their combination to be an operating system is a matter of convention.

When an Emacs user greps from Emacs why is this less blessed than my grepping from Bash? Is it considered blasphemy against vi?

Yes, I see that Bash is not the OS and vi is not the OS and neither of course is grep, for the OS is the turtle upon which these things rest and it is turtles all the way down until you get to microcode. Just because someone calls themselves "a computer scientist" it does not make their abstractions are any less metaphysical.

It is when we use an human centered definition of "operating system" rather than a machine centered one that Emacs can be seen in a different light. It is not that either group is failing to develop a scientific model. It is that each model has orthogonal metrics.

"So for someone who is writing office document, Microsoft Word is the OS?"

If the computer is never used for any other application, then that's an arguable position.

To be fair, if you are going this route then you should note that the most of the things you describe in the last paragraph of your post are part of the kernel as opposed to the OS. By the way I don't consider Emacs to be an Os, it is just a convenient and advanced (as far as the user programs go) interface to the facilities provided by the OS/kernel along the lines of Shell (in this regard).

Technically these guys are all talking about emacs as a CLI not as an OS. I don't think they're calling for reimplementing the e1000e network card driver in elisp as much as commenting out a getty on /dev/ttyWhatever and replacing it with a screen/tmux connection to an emacs session or a zillion other ways.

Now that we've learned from 'Emacs as Operating System', how about we move into the future.

As the saying goes, "Emacs is a great OS but it's got a crappy text editor".

"Firefox/Chrome is a great OS but it's got a really crappy text editor that has about as much power as Notepad(TM)"

How about we figure out how to embed a real text editor into the edit fields of web pages?[1]

Oh, and if it only worked under Linux, I don't see a problem with that.

[1] http://emacs.1067599.n5.nabble.com/An-Emacs-plug-in-for-a-br...

That's kind of the direction Lighttable seems to be going. The entire editor runs inside node-webkit, so you can have a browser window running inside your editor.

No, I want a real editor inside my browser.

Firemacs is decent, but still has a few hangups:

    https://github.com/kazu-yamamoto/Firemacs

It's the closest thing to a real editor on the I've been able to find.

Node-webkit is a browser.

This article was interesting:

http://tkf.github.io/2013/06/04/Emacs-is-dead.html

The lack of multi-threading is #1 on his list, and it seems to me for good reason. If one of my emacs buffers locks up (which can happen for any number of reasons), the whole session is hosed.

Notwithstanding that, one thing I'd love to see is an FTP client mode something like FileZilla.

There is many filezilla'esk ways of accessing files over ftp and ash in emacs. Two are:

Dried

Sunrisecommander

>If one of my emacs buffers locks up (which can happen for any number of reasons), the whole session is hosed.

I have used Emacs every non-vacation day for the last 22 years, starting with version 18 and extending through version 24, on over a dozen computers, on Linux, OS X and a proprietary Unix, in text mode and with a GUI. I think I understand Emacs internals pretty well, and I cannot imagine what you mean by "if one of my Emacs buffers locks up".

go-mode (at least used to) have a bug in the auto-indent code that would occasionally throw it into an infinite loop. This should only affect the buffer with the code being indented. I should be able to switch buffers, switch to another frame, and edit other code. I should be able to kill the buffer. However, I can't, as the lisp is stuck trying to parse go code that can't be parsed. Now, my Emacs session, which may include several unsaved files, my IRC sessions, and connections to remote hosts, must be killed.

Now I see: great grandparent's "emacs buffer locks up" refers to the (multi-threaded) way he (and probably you) wish Emacs worked, not the way it actually works.

Typing control-G does not get you out of the infinite loop?

Both this and problems like LukeShu mentioned. For example, I had a problem where org-mode would hang in certain cases when using \mdash with pretty-entites turned on. Or csharp-mode would hang when editing around preprocessor directives. Emacs becomes non-responsive in such cases. It would be cool if I could just close that buffer, like a browser tab that had crashed.

This and the fact that all async processing has to be done through OS jobs (or something like that) make it unsuitable as a replacement for many kinds of app.

When you're using zenirc and Gnus all day as well as editing, network issues also block emacs. Which is why I stopped doing that.

And the work on preliminary thread support is well under way..

Concurrent != parallel != multi-threaded

Threads are WorseIsBetter concurrency which break pretty-much everything they touch. Elisp would be best without them, and use a sane concurrency mechanism like asynchronous events (like Node/Erlang). This would require private variables (ie. lexical scope), and that the interpreter be aware of what is accessed from each scope, so that concurrent code can be run in parallel. Switching to Scheme (Guile) would be the first step.

What I'd really like to see is an editor with an FRP interface. That won't happen with Emacs though, since it's too big a leap in philosophy.

I think the Emacs as OS feeling particularly rings true for those using Windows. It certainly makes Windows a lot more usable for me.

With dynamic languages the ability to run REPL inside an editor is also a huge plus. In Emacs the way you can interact with text is pretty much unlimited. For example, with the right modes you can pretty much free form evaluate any expression anywhere in the editor. One has to use it to experience the power.

The SELF guys http://en.wikipedia.org/wiki/Self_%28programming_language%29 had the same dream, but used a different strategy. They wanted to replace underlying components by a rewrite in SELF, one component at a time. Until the only thing left was a SELF system.

I think the SqueakVM was developped in the same way. Can't remember where I read this. </remembering in progress>

emacs the Operating system is both the idea of the LISP machine and the situation that since it is extremely extensible, you can use it as a shell, for irc or mail, read pdf and view images, listen to music and do anything that doesn't require a modern web browser, or video player.

For me that was the situation for a while, nothing but Firefox and emacs. I even used it for IM and Twitter. All I needed was for it to render the web and I could ditch anything but it.

No, it really isn't. A Lisp OS (like Genera) is about extensibility down toward bare metal, not up towards applications. As you point out, if all you want to do is live your whole computing life inside of Emacs and hacking about with Lisp, people have been doing that for years (decades) without an underlying Lisp OS. Having a Lisp OS is being able to live inside that environment and being able to say things like "I'm going to add a new queuing scheme to networking" or "I wonder what happens if I change how the GC subsystem works" and the ability to do that is in the environment, in Lisp, all the way down.

Once upon a time people made fun of Emacs for being bloated:

Eight Megs And Constantly Swapping

I think those people would have fainted at the thought of some of the Java IDE's these days.

There was a point in time when it took longer to load a fresh copy of the project I was working on in IntelliJ than it did to update, build from source, and launch Emacs. That said more about the project I was working on than IntelliJ, but still.

It wasn't that long ago. Those guys are probably still around.

To be fair, Emacs still doesn't have anything quite like the extensive support for things like refactoring that Eclipse does. Not without bulky kluges like CEDET, anyway.

Well, you can turn Emacs into an IDE, but then you have an IDE, which seems to inevitably include slowness and bloatedness. That's what CEDET is, basically, I couldn't bear using it.

I don't find it hard to live without auto completion and friendly refactoring wizards. regex replace and grep/sed do the job for me. I might be wasting a bunch of seconds here and there, but I'm quite sure I'm saving more than that in loading/hanging time.

The major difference seems to be that those Java IDE's hook directly into the compiler, so they "know about" the language's syntax and libraries in a way that Emacs likely never will.

That's a nice thing in some ways, but my guess is that when you try and edit, say, Erlang or something else, those big IDE's are just going to sputter and flail because they're outside their comfort zone. Emacs is more of a rugged jeep in that, ok, it doesn't know all the methods for all the classes in Java, but throw some Erlang, Tcl, Ruby, ASM, or whatever else at it, and it'll handle it ok, just as it does a decent job for Java, C, Perl or whatever else.

When I write Erlang and I hit ":" after a module name, I immediately see a list of functions with arity and docs, thanks to Distel. The same is true when I hit a "." when writing JavaScript, thanks to js2. It's the same for Python, too, thanks to elpy.

There is a great support for refactoring too - for Python it's Rope and it works quite well. It's a bit slow to start sometimes, but that's equally true for "bloated Java IDEs".

I don't think there's anything my teammate can do in his PyCharm which I can't in my Emacs. And if there is something like that, and it's useful, then I'm sure it will come to Emacs soon enough.

To summarize: Emacs is an editor for programmers and can be programmed (with 3rd party or your own scripts) to have any feature you'd like. Setting up an Emacs environment which is on par with other IDEs takes a bit of work, but is possible.

> That's a nice thing in some ways, but my guess is that when you try and edit, say, Erlang or something else, those big IDE's are just going to sputter and flail because they're outside their comfort zone.

Yup, as much as I like Emacs and dislike IDEs, I fire up Eclipse without hesitation if I need to work on some Java code. Java just begs you to use an IDE because (1) It is incredibly cumbersome and (2) It's very nature make it possible to create powerful IDEs, that's not the case for most languages.

Refactoring ? Which language ? Around 2008, Eclipse was only great at refactoring Java. Other languages had few basic transformation (scoped rename, variable lift, ...). Is it different now ?

"What's more, it's about the most portable operating system ever."

So browsers and ECMAScript are the new EMACS. Looks about right.

Emacs as text editor with hackable presentation and interpreter. Browsers as hypertext with hackable presentation and interpreter.

It really, really, isn't. Try using emacs on windows for any length of time, see how you get on.

More like "Emacs as default shell", as Emacs is next to worthless without all those userspace utilities.

>Emacs is next to worthless without all those userspace utilities

GNU/Emacs?

Emacs as default init, shell, window manager and "desktop" environment. Emacs has a reimplementation of almost all basic shell commands [1][2], in eshell. You get a unix style shell that works in windows too.

[1] http://www.gnu.org/software/emacs/manual/html_mono/eshell.ht...

[2] http://www.masteringemacs.org/articles/2010/12/13/complete-g...

Emacs is used as an operating system (interface), by blind users! Emacspeak adds speech syntheses and more to Emacs, and can do better than traditional screen readers in many ways due to being able to easily access the underlying lisp states easily.

My father has difficulty seeing, and spends most of his computer time within Emacs, occasionally switching to Gnome (for certain websites) or a speech enabled console.

The most amazing discovery I made was a minor mode that put a battery indicator into the status line. Emacs as OS – effectively true.

Whoa anyone can edit the text? What site is this?

It's the original wiki! See http://en.wikipedia.org/wiki/Wiki#History

Yet it's quite devoid of noise.

This made more sense in the days when 80 column by 25 lines were all that one could see into a computer, and BSD Unix shells had no sensible response to arrow keys ...

In those days, having three or four Emacs buffers where one could have a couple of files being edited, a shell session, and the output of the compiler was considered a blessing.

The rest of the "OS" moniker referred to things such as email and NNTP clients written in Elisp. It was really possible to start the day in Emacs and never leave, and I saw some people do it, although it was never quite my cup of tea. Fortunately, megapixel displays and window systems soon came to the rescue.

The main reason why emacs can't be an operating system (or at least a decent one) is that it doesn't support multi-threading. And even if you added multi-threading to emacs, the fact that all of the elisp code out there has no locking and doesn't expect other threads to be modifying various data structures and buffers out from under them, means that it really can't be done at all in any kind of practical way.

No multi-tasking doesn't mean it can't be an OS, just not a decent OS. DOS was not a multi-tasking OS. Prior to ITS, the MIT AI Lab (which RMS was a member of) were opposed to multi-tasking OSs. Lack of that feature doesn't make it not an OS.

Forgive me for this but...

Now if only Emacs as an OS had a good editor.

evil-mode

I miss emacs more than I like Sublime Text… never really liked it as an OS though (bash is better).

Those of us who actually used Genera on a Symbolics Lisp Machine really, really hope that anyone who contemplates this sets their sights a helluva lot higher than GNU Emacs. All of this mythologizing GNU Emacs as something more than a pale imitation created on hardware with a tiny fraction of the expressive power of the real thing is like watching some cargo cult culture talk about how they're going to build a real airplane out of bark and vines.

FYI:

http://www.cliki.net/VLM_on_Linux

http://www.ugcs.caltech.edu/~weel/lispm.php

http://thepiratebay.sx/torrent/3769989/Symbolics_Open_Genera...

I'm waaaay ahead of you here, but thanks for putting the links up for those who aren't in the know.

And before someone cranks one of these up and nit-picks some functionality GNU Emacs has that this doesn't, do try and remember that serious development of Genera for all practical purposes ended before Stallman released the first public release of GNU Emacs.

Awesome. I'm trying to get the Open Genera on OS X now and I'm running into problems getting the ES40 emulator built and compiled for OS X.

How are you running OpenGenera?

I think many of us are waiting for a lisp os to come back. At least personally, Emacs is just the closest thing to this idea which is also runnable right now (Except buying an old lispmachine, or running the genera image floating on the web not long ago).

If you stay in Emacs, a Lisp OS will never come back.

Ok, back to Eclipse then <o/

> Those of us who actually used Genera on a Symbolics Lisp Machine really, really hope that anyone who contemplates this sets their sights a helluva lot higher than GNU Emacs.

What's the best demonstration of its appeal? Any good videos to watch? Is there an equivalent of Englebart's Mother of All Demos for Lisp machines?

Reply on news.ycombinator.com