Lets type?

Plan “Typewriter”

I hasten to inform you that I have launched a project to return the UNIXtypewriter to Plan 9/9 front - Plan “Typewriter”¹. The project is focused on preparing an environment that ignores the mouse completely and allows you to work without removing your hands from the keyboard.

– We built, built, and finally built! Long live us, hooray!

So far, it is ready ** very basic** only the window manager - nwm. At this stage, this is a fork of rio from the 9front project, to which I added the rendering of the navigation bar and the processing of hotkeys. When developing the interface, I was inspired by dwm², a simple and concise window manager for the X server. Only working with windows and the file system will remain directly from rio. As development progresses, everything “superfluous” will be removed to reduce the amount of code.

I’ve been hatching the idea for about a year. The project seemed too complicated and unaffordable to me. But one day I decided to make a couple of sketches of the bar rendering. It just went on by itself…

On the way as well:

• st³/foot⁴-like terminal emulator. So far, I’ve only made small sketches and am diving into the technical details.
• Emacs⁵-like text editor, extensible (in the future) not just with its Lisp dialect, but with a full-fledged Scheme (I haven’t decided which one to use yet). As soon as everything is ready, it will be published on the project’s website.

Acme: OFF

Acme (as conceived by the developers) is a system interface. After all, if everything is a files and most of them are with text, then only a text editor is needed to work with the system. But what I can’t accept is the very limited keyboard support. The editor is too mouse-oriented. It also lacks syntax highlighting. The idea is not to write code so complex that syntax highlighting is needed. If you plan to limit writing code to “Hello, world!"’s applications, then its capabilities should be quite sufficient. But few people will be able to say that the code, for example, rio is simple.

So when developing, I used Emacs and immediately tested the code in 9front. And drawterm helped me in this. When connected to Plan 9 via drawterm, the machine’s local file system is mounted to the current environment. All files are available absolutely transparently. Just go to the right directory, compile and run.

Amazing C

In the process, I discovered something very interesting about Plan 9 dialect C - embedding structures. We are used to the fact that in C you can use one structure inside another in two ways.

1. As a variable:

struct A {
	int x;
};

struct B {
	struct A a;
};

After that, we can access the field from the structure A through b.a.x.

2. As an anonymous structure:

struct B {
    struct {
        int x;
    };
};

This is especially noticeable when there is a high level of nesting of structures in large projects and long field names.

But in Plan 9 dialect C, the developers didn’t look back. They will later transfer this behavior to Go:

struct A {
	int x;
};

struct B {
	A;
};

The field x is now available as native through b.x. And you know what, it’s very pleasant and convenient to work with it. Especially after Go. There is a small fleur of OOP (in the good sense).

What’s next?

I will certainly bring the application to 1.0 releases (not mean quickly). I will develop the project as much as I can. As always, I will not refuse advice and recommendations. At this stage, the most important help you can provide to the project is the dissemination of information and commits/patches. Yes, the project is currently at a very early stage. But I did not say that this is Production-ready software.

The main purpose of this publication is to attract the attention of an already narrow community. Maybe there are 3.5 people somewhere who wanted to see in Plan 9 what they were used to on their UNIX machines.

If you are there, please respond!