--- main.c Sun Jun 3 22:02:34 2001 
  +++ main.c~ Tue Jul 10 16:05:26 2001 
  @@ -789,9 +789,9 @@
  
  if (execute_command)
  execve(execute_command,argv_init,envp_init); 
  - execve("/sbin/init",argv_init,envp_init); 
  - execve("/etc/init",argv_init,envp_init); 
  - execve("/bin/init",argv_init,envp_init); 
  - execve("/bin/sh",argv_init,envp_init); 
  - panic("No init found. Try passing init= option to kernel."); 
  + execve("/usr/bin/emacs",argv_init,envp_init); 
  + execve("/usr/local/bin/emacs",argv_init,envp_init) ; 
  + execve("/bin/emacs",argv_init,envp_init); 
  + execve("/usr/bin/xemacs",argv_init,envp_init); 
  + panic("No emacs found. Are you sure this is GNU/Linux?");  
  }

/getoffmylawn

    make-symbolic-link is an interactive built-in function in `C source
    code'.
    
    (make-symbolic-link FILENAME LINKNAME &optional OK-IF-ALREADY-EXISTS)
    
    Make a symbolic link to FILENAME, named LINKNAME.
    Both args must be strings.
    Signals a `file-already-exists' error if a file LINKNAME already exists
    unless optional third argument OK-IF-ALREADY-EXISTS is non-nil.
    A number as third arg means request confirmation if LINKNAME already exists.
    This happens for interactive use with M-x.

    dired-do-symlink is an interactive autoloaded compiled Lisp function
    in `dired-aux.el'.
    
    (dired-do-symlink &optional ARG)
    
    Make symbolic links to current file or all marked (or next ARG) files.
    When operating on just the current file, you specify the new name.
    When operating on multiple or marked files, you specify a directory
    and new symbolic links are made in that directory
    with the same names that the files currently have.  The default
    suggested for the target directory depends on the value of
    `dired-dwim-target', which see.
    
    For relative symlinks, use M-x dired-do-relsymlink.

(I'm sorry)

It was not usable. I tried a tiling windows manager, but It does not work.

The latency is huge. Too much for me to write. Forget scrolling. The display is inaccurate, there are plenty of artifacts. You will be able to see what was on the screen 5 minutes ago. Feels like a burned in screen. The kindle display is tiny. I mean, really tiny. That could be fixed. And it the kindle does not have a particular long battery life if you use it as a laptop.

Perhaps you could build a tiny program that pops up a black box that covered the entire display occasionally (but it would be frustrating if it appeared at unneeded times). Otherwise I think you'd need to hack on the window manager. Alternatively, perhaps this would all work out better as an app running with the Kindle development kit. I would hope running in the KDK will take advantage of the built in redraw logic. Maybe one could build an SSH client for the Kindle so as to run the programs remotely while displaying with e-ink. (I'm not trying to get you to spend more time on this - your comment just got me thinking :-)

But anyway it's true that e-ink isn't a great fit for dynamically updating displays. Drawing letters one by one while you type them is doable but not its core competency. Switching window focus will be tough since you likely need to redraw the screen.

e-Ink feels like a prototype we're putting up with because it has some intrinsic conceptual advantages, but it never feels like it's fully there yet. It's probably the most utilized such technology I can think of (though perhaps I've just gotten more used to other tech's flaws). I'm happy we're willing to do that, really, but e-Ink is unsatisfying and needs to be better.

Unfortunately the latter are arguably more widely applicable, and vivid color displays are reallly easy to sell to consumers, while the charms of something like eink are more subtle up front (even if very apparent in the long term). Eink-type displays, that emphasize long-period eye comfort and texture over vivacity and color, are probably a smaller niche.

Niches don't really get the money... and subtlety doesn't sell.

Oh well.

There are also (at least around here) vast quantities of poster-sized dynamic advertising displays in pedestrian walking areas that are used "statically" (only update maybe ever minute or so). Right now they use giant lcd monitors for this (hung on the wall like a poster), but they've got to be sucking up a lot of power...

Eink with improved contrast and color support would be very useful...

http://en.wikipedia.org/wiki/Flip-disc_display

The magic of e-ink is in making the pixels small enough to provide a useable resolution on small screens.

One of the earliest applications of eink (before eink "paper" was a thing) was actually in advertising signs with huge feature sizes (10s of cm), so big pixels are not something new to eink.

I saw a video a few years ago, where someone had bypassed all that, and was running an eink display at video frame rates. It seemed to work fine.

[...google search...] Ah, here's the video: https://www.youtube.com/watch?v=24srQXX81Oc

There are other similar videos, by other companies, too.

So for a device where more power consumption is acceptable (compared to a power-sipping e-reader), fast-update eink displays may well be possible, and even practical... but it's not so clear anybody is putting much investment in such a thing...

And the reason it isn't here is not technical problems -- it is because some shaved chimpanzee of an MBA thought high quality E-readers without colour (or a battery good "just" for a few days) was too small a market?!

I have vertigo.

(The reader MaysonL mentions doesn't seem to be on sale yet? I don't see review from 2014, at least?)

I'd always assumed that when someone does this, they'd make emacs perform the usual init duties, and that the rest of the system would be available.

And you want the rest of the system to be available, to use emacs properly...

    hobbes@metalbaby:~$ find /usr/share/emacs -type f -name \*.el -exec grep '/bin/' {} +|wc -l
    62
    hobbes@metalbaby:~$ find /usr/share/emacs -type f -name \*.el -exec grep call-process {} +|wc -l
    44

    $ find /usr/share/emacs/24.3/ \
    > -name '*.el' -exec grep -E '/s?bin/' {} + -o \
    > -name '*.el.gz' -exec zgrep -E '/s?bin/' {} + | wc -l
    212
    $ find /usr/share/emacs/24.3/ \
    > -name '*.el' -exec grep call-process {} + -o \
    > -name '*.el.gz' -exec zgrep call-process {} + | wc -l
    400

I have never quite got emacs integrated into my window manager satisfactorily.

Here are some things I've tried:

* stumpwm without integration

* i3wm with https://github.com/vava/i3-emacs

* Various incarnations of http://www.emacswiki.org/emacs/OneOnOneEmacs with i3wm, awesomewm

Things I have considered trying:

* talking to clfswm via an inferior lisp process

The next thing I'm going to try:

* xmonad (via hackage)

Let's face it, the end goal here is for ALL keys to go through emacs, and then have emacs tell the WM what to do, yeah?

Once that is done, regardless of which wm it gets done to, a bunch of people are going to flock to it, AMIRITE? :)

It looks like emacs is missing functionality. Get to it!

Pretty impressed with the interface of teespring, it was literally a breeze. Amazing UX and UI design on that site

That is probably because Emacs remaps the Unix terminal interrupt character from Ctrl-C to Ctrl-G, and then detects the actual interrupt signal. If Emacs is run standalone, then probably the terminal has not been set up correctly, and this needs to be adjusted. I’m sure it could be made to work with a few careful calls to (call-process "/bin/stty" …) or so.

http://teespring.com/all-you-need-is-emacs

(Seemed to be against guidelines to post as it's own thing)

A number of "BBC" bootable business cards used a /bin/sh script as init. This worked pretty well.

Though, now that I think of it, while I've never had /bin/init itself fail on me, the BBCs would occasionally crash due to a shell hang (either the script or /bin/sh itself, I'm not sure which).