This is still the header! Main site

Emacs OS Mobile


... yet another speculative thing that I wrote because we need more articles.

So, just like tabs, the world seems to be converging on how mobile operating systems are supposed to look like.

There is a main screen, mostly with little icons; there are "apps", which are full-screen-only things, generally only sharing data with some cloud service, with navigation looking like a single browser tab. Sometimes, there are text fields; a keyboard will pop up to let you type into those. Replacing "features" with "whitespace" is cool.

Sadly, the rest of "computing" is also turning into something similar. It's increasingly common that even desktop apps that should be capable of opening multiple things at once are designed like a phone app.

There is one refreshing example I encountered that goes against this trend: SXMO the mobile UI / OS / environment.

It's a collection of shell scripts. (Not even especially complicated ones!) And then you get to navigate via menus and use gestures to do stuff. The gesture detector is... questionable, the entire thing is really unintuitive first, and even putting the phone to sleep is kind of a challenge (you got to tap the "volume up" button three times, fairly quickly). It also comes with an actual tiling WM. But... it... kinda grows on you. And it feels like you can actually modify things.

... any other environment being famous of the feeling of "you can modify things", anyone?

... yes, I'm serious.

Because we'll need to take "mobile", whose one defining quality is "lack of a reasonable keyboard", and combine it with the thing which is great because you never have to use anything but a keyboard. Logical. Right?


But then using shell scripts for mobile wouldn't quite make sense either. Except... SXMO uses menus and gestures in front of them. I'd actually argue that Emacs is a better fit!


We'll need a tiling WM. Inside Emacs. Well, there is EXWM. Problem solved.


One of the nicer features of EXWM (... disclaimer: haven't tried it yet...) is that you can rebind all the keys in actual apps, since input is going through Emacs itself. Meanwhile, Emacs keymaps have a nice, abstract feel to them: each mode can add bindings, with them adding up to something sensible.

What if... adding certain commands to keymaps would put up touchscreen buttons executing them? With this being customizable?

E.g. in a text buffer, next line / previous line being bound would result in up / down arrows showing up in one of the corners of the screen.

Of course, it's not super easy to fit all keybindings to a screen, but a combination of "picking the most frequently used ones" and "some tree representation that's mildly more usable than an actual on-screen keyboard" might do it.

But even if it's just menus... Emacs does have support for menus.

Bridging the terminal and GUIs

Terminals are not an overly good fit for phones: you got to scroll up and down, enter commands, etc. It's actually nice, especially on a smaller screen with a bad keyboard, to have information presented to you in the form of, say, a list, or some kind of UI. However, TUI apps (htop, etc.) wouldn't do especially well on a phone, due to their hard-to-change key bindings.

So we go and rewrite everything in Qt and GTK. Resulting in things that are hard to create, rigid and slow.

Emacs has neat UIs with key bindings that are easy to modify... or where they are replaceable with clicks / arbitrary other ways of selecting commands. Just wrapping the output of a UNIX command in a neatly syntax-highlighted Emacs mode and putting it on a menu is significantly less effort compared to reformatting all the contents using a "proper" GUI toolkit.

... and it's Lisp!

This is also somewhat controversial as a feature, but in a competition of Lisp vs. shell scripts, "better debuggability" probably goes to Emacs Lisp.

(... this might actually go onto the pile of side projects I don't quite have time for.)

This is post no. 24 for Kev Quirk's #100DaysToOffload challenge.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.