WEBVTT

00:07.600 --> 00:00:09.120
Hi! I'm Erik Anderson,

00:00:09.120 --> 00:00:10.559
and I'll be talking about tui,

00:00:10.559 --> 00:00:11.840
a user interface framework

00:11.840 --> 00:00:15.040
that I've written in Emacs Lisp.

00:15.040 --> 00:00:16.196
First, I want to talk a bit about

00:00:16.196 --> 00:00:17.296
the problem space of

00:00:17.296 --> 00:00:18.728
user interface development,

00:00:18.728 --> 00:00:20.880
specifically, I want to quickly illustrate

00:00:20.880 --> 00:00:22.320
some of the complexities involved

00:00:22.320 --> 00:00:26.480
with UI implementation in Emacs.

00:26.480 --> 00:00:27.920
In Emacs, we have the ubiquitous 

00:00:27.920 --> 00:00:29.920
buffer object type that forms the container

00:00:29.920 --> 00:00:31.920
for most content in Emacs.

00:00:31.920 --> 00:00:34.079
Most interfaces we interact with

00:00:34.079 --> 00:00:36.239
consist of character based content

00:00:36.239 --> 00:00:38.239
in a buffer that's presented

00:00:38.239 --> 00:00:40.079
in a window in frame.

00:40.079 --> 00:00:41.520
Although the underlying content

00:00:41.520 --> 00:00:44.320
may be textual, Emacs has capable APIs 

00:00:44.320 --> 00:00:47.680
to present rich content.

00:47.680 --> 00:00:49.200
The pervasiveness of buffers

00:00:49.200 --> 00:00:50.879
affords us wonderful flexibility.

00:00:50.879 --> 00:00:52.559
This presentation, for instance,

00:00:52.559 --> 00:00:55.520
is running in an Emacs buffer.

00:55.520 --> 00:00:57.420
Using Emacs's built-in basic

00:00:57.420 --> 00:00:59.199
button library, we can insert

00:00:59.199 --> 00:01:00.884
an interactive button

00:01:00.884 --> 00:01:01.760
that shows a message 

00:01:01.760 --> 00:01:06.080
in the minibuffer when clicked.

01:06.080 --> 00:01:09.200
What about UIs that express application state?

01:09.200 --> 00:01:11.439
Most applications don't have a static UI.

01:11.439 --> 00:01:13.280
As application state changes,

00:01:13.280 --> 00:01:14.320
the UI should change

00:01:14.320 --> 00:01:18.479
to display the desired content.

01:18.479 --> 00:01:20.320
One simplifying strategy is to simply

01:20.320 --> 00:01:23.600
re-render the entire UI upon any change.

01:23.600 --> 00:01:25.680
First erase the contents of the buffer,

01:25.680 --> 00:01:27.600
and then reinsert your UI again

00:01:27.600 --> 00:01:29.040
with desired changes,

00:01:29.040 --> 00:01:33.040
and restore things like point and region.

01:33.040 --> 00:01:34.560
Basic composition is possible

00:01:34.560 --> 00:01:35.759
with this approach.

00:01:35.759 --> 00:01:37.200
Simply insert the elements

00:01:37.200 --> 00:01:39.280
of the UI in sequence.

01:39.280 --> 00:01:40.640
Complex elements can be

00:01:40.640 --> 00:01:44.320
composed of multiple sub-elements.

01:44.320 --> 00:01:45.840
UIs can be made extensible,

00:01:45.840 --> 00:01:47.040
and expose this composition,

00:01:47.040 --> 00:01:49.360
for example, with insertion hooks

00:01:49.360 --> 00:01:52.320
like magit's status sections hook.

01:52.320 --> 00:01:54.159
This generally relies on elements

00:01:54.159 --> 00:01:56.640
being well-behaved inserting themselves,

00:01:56.640 --> 00:02:00.399
not affecting the rest of the buffer.

02:00.399 --> 00:02:02.960
If we find ourselves with complex UIs,

02:02.960 --> 00:02:04.640
large buffers, long lines,

00:02:04.640 --> 00:02:06.320
or poor rendering performance,

00:02:06.320 --> 00:02:09.039
we might consider partial UI updates

00:02:09.039 --> 00:02:11.360
rather than re-rendering completely.

02:11.360 --> 00:02:12.800
In that case, the complexity 

00:02:12.800 --> 00:02:15.840
for maintaining the UI quickly increases.

00:02:15.840 --> 00:02:17.360
As accessible as buffers are,

00:02:17.360 --> 00:02:19.120
we don't have high level abstractions

00:02:19.120 --> 00:02:20.879
for managing portions of a UI

00:02:20.879 --> 00:02:22.160
rendered to a buffer.

00:02:22.160 --> 00:02:23.520
(It) is left up to the programmers

00:02:23.520 --> 00:02:25.440
to track and update UI state.

00:02:25.440 --> 00:02:26.540
This is generally done by

00:02:26.540 --> 00:02:28.959
one of two methods, reflection,

00:02:28.959 --> 00:02:30.800
searching for strings or text properties

00:02:30.800 --> 00:02:34.239
within the buffer, or tracking segments 

00:02:34.239 --> 00:02:36.080
of a UI buffer manually 

00:02:36.080 --> 00:02:38.959
using numeric offsets, or marker, 

00:02:38.959 --> 00:02:45.280
or overlay objects.

02:45.280 --> 00:02:47.280
Here we have a basic timer component

02:47.280 --> 00:02:48.720
that shows elapsed time

00:02:48.720 --> 00:02:50.319
after it's inserted.

00:02:50.319 --> 00:02:52.160
It works, but has several problems.

00:02:52.160 --> 00:02:55.519
It doesn't restore the user's point or mark,

02:55.519 --> 00:02:59.120
so it snaps back after every render,

02:59.120 --> 00:03:01.040
after every update.

03:01.040 --> 00:03:03.360
It relies on singleton global state,

00:03:03.360 --> 00:03:05.124
so isn't designed to coexist

00:03:05.124 --> 00:03:12.000
with other instances of itself.

03:12.000 --> 00:03:13.200
It doesn't use a marker,

00:03:13.200 --> 00:03:14.640
so it's sensitive to content

00:03:14.640 --> 00:03:16.239
proceeding it, that's following it, 

00:03:16.239 --> 00:03:23.519
changing in the buffer.

03:23.519 --> 00:03:25.120
The update logic doesn't even consider

03:25.120 --> 00:03:26.799
which buffer it's trying to update.

00:03:26.799 --> 00:03:27.840
If I switch buffers,

00:03:27.840 --> 00:03:29.360
it will insert into another buffer,

00:03:29.360 --> 00:03:31.519
or even the minibuffer.

03:31.519 --> 00:03:33.360
It can't remove itself, or re-render

00:03:33.360 --> 00:03:34.879
if it gets corrupted, as you see.

00:03:34.879 --> 00:03:35.920
All in all, it's not

00:03:35.920 --> 00:03:38.400
a readily composable component.

03:38.400 --> 00:03:39.519
Addressing these components

00:03:39.519 --> 00:03:41.920
within this logic further increases 

00:03:41.920 --> 00:03:43.936
the implementation complexity

00:03:43.936 --> 00:03:45.680
of this component,

00:03:45.680 --> 00:03:46.640
and still this component

00:03:46.640 --> 00:03:47.280
would likely have

00:03:47.280 --> 00:03:49.120
various subtle differences

03:49.120 --> 00:03:52.480
with other components

00:03:52.480 --> 00:03:58.959
implemented by other authors.

03:58.959 --> 00:04:00.319
For those of you unfamiliar

00:04:00.319 --> 00:04:02.159
with this term Yak Shaving,

00:04:02.159 --> 00:04:04.080
that is a quite technical term

00:04:04.080 --> 00:04:07.599
for any seemingly pointless activity,

00:04:07.599 --> 00:04:09.680
which is actually necessary

00:04:09.680 --> 00:04:10.879
to solve a problem,

04:10.879 --> 00:04:11.920
which solves a problem,

00:04:11.920 --> 00:04:14.799
which, several levels of recursion later,

04:14.799 --> 00:04:18.239
solves the real problem you're working on.

04:18.239 --> 00:04:19.943
The itch that led to this project

00:04:19.943 --> 00:04:21.840
was the desire to display a dense summary 

00:04:21.840 --> 00:04:24.400
of local Git repository statuses.

04:24.400 --> 00:04:26.560
Encountering various implementation

04:26.560 --> 00:04:30.080
complexity for building UI elements,

04:30.080 --> 00:04:31.680
it led to the yak shaving endeavor

00:04:31.680 --> 00:04:33.680
that produced tui.

04:33.680 --> 00:04:35.440
When I wrote the library,

04:35.440 --> 00:04:36.479
I had recently played with 

00:04:36.479 --> 00:04:39.360
a popular UI framework called React,

00:04:39.360 --> 00:04:41.840
and had an interest in learning

00:04:41.840 --> 00:04:44.080
about the internal architecture of React.

00:04:44.080 --> 00:04:45.680
So, rather than implement

00:04:45.680 --> 00:04:46.960
a string caching layer

00:04:46.960 --> 00:04:49.280
on top of tabulated list mode,

00:04:49.280 --> 00:04:50.360
I was rather inclined

00:04:50.360 --> 00:04:52.400
to go down the path of implementing

00:04:52.400 --> 00:04:58.960
the React API for Emacs Lisp.

04:58.960 --> 00:05:00.896
I'll offer a brief view of

00:05:00.896 --> 00:05:05.120
the tui Emacs Lisp API.

05:05.120 --> 00:05:07.360
Inserting component content 

00:05:07.360 --> 00:05:08.320
is pretty straightforward.

00:05:08.320 --> 00:05:10.160
You take a component tree

00:05:10.160 --> 00:05:16.240
and render it in an Emacs buffer.

05:16.240 --> 00:05:18.639
If any elements in that tree are updated,

05:18.639 --> 00:05:21.039
their respective content on the tree

00:05:21.039 --> 00:05:26.320
is updated automatically.

05:26.320 --> 00:05:27.919
Here's a basic re-implementation 

00:05:27.919 --> 00:05:29.919
of the straw man timer from earlier,

00:05:29.919 --> 00:05:32.400
using a macro for syntactic trigger.

05:32.400 --> 00:05:34.404
You'll notice that

00:05:34.404 --> 00:05:36.164
the signature includes its own

00:05:36.164 --> 00:05:44.560
object reference, arguments, and state.

05:44.560 --> 00:05:46.400
Associating arguments in the state

05:46.400 --> 00:05:51.360
with a component instance out of the box,

05:51.360 --> 00:05:54.400
makes it easy to design reusable components,

00:05:54.400 --> 00:06:06.080
and forms the basis for partial UI updates.

06:06.080 --> 00:06:07.840
The component rendering anchors

00:06:07.840 --> 00:06:09.199
are durable, so content can be

00:06:09.199 --> 00:06:11.360
added and removed surrounding content,

00:06:11.360 --> 00:06:12.479
or even within the region

00:06:12.479 --> 00:06:13.280
of the component,

00:06:13.280 --> 00:06:16.319
and replaced when it re-renders.

06:16.319 --> 00:06:17.600
Components will also

00:06:17.600 --> 00:06:20.880
cleanly remove themselves from a buffer

00:06:20.880 --> 00:06:28.400
when instructed to.

06:28.400 --> 00:06:30.160
tui contains the core implementation

00:06:30.160 --> 00:06:33.440
of the React API, so components,

06:33.440 --> 00:06:35.840
their constituent props, state,

00:06:35.840 --> 00:06:38.000
and all of the lifecycle methods

00:06:38.000 --> 00:06:39.440
associated with them,

06:39.440 --> 00:06:41.120
as well as keys, refs,

00:06:41.120 --> 00:06:43.228
and the fundamental

00:06:43.228 --> 00:06:47.520
reconciliation algorithm of React.

06:47.520 --> 00:06:52.188
A variety of other React APIs

00:06:52.188 --> 00:06:58.080
that haven't been implemented yet.

06:58.080 --> 00:07:00.080
It contains some useful features so far,

07:00.080 --> 00:07:02.639
such as hot reloading, reflection,

00:07:02.639 --> 00:07:06.164
and various debugging tools,

00:07:06.164 --> 00:07:12.639
and some reconciliation logging.

07:12.639 --> 00:07:14.880
Lastly, I'd like to give you some quick

07:14.880 --> 00:07:19.039
visual taste of components built with tui.

07:19.039 --> 00:07:20.240
The grid view that motivated

00:07:20.240 --> 00:07:21.520
my development of this package

00:07:21.520 --> 00:07:23.039
is very similar to Magit's

00:07:23.039 --> 00:07:30.720
list repositories functionality.

07:30.720 --> 00:07:36.080
Essentially, tabulated list mode

07:36.080 --> 00:07:39.440
but portable and has a separated model

00:07:39.440 --> 00:07:49.360
and presentation layers.

07:49.360 --> 00:07:51.840
Here's a basic xkcd comic viewer

00:07:51.840 --> 00:08:07.360
showing a couple classics.

08:07.360 --> 00:08:10.080
A long-standing React tutorial is

08:10.080 --> 00:08:13.280
building a tic-tac-toe game

08:13.280 --> 00:08:14.879
as a bit of a gimmick,

08:14.879 --> 00:08:17.039
and I'm not quite satisfied with

00:08:17.039 --> 00:08:25.599
the buffering direction,

00:08:25.599 --> 00:08:27.120
but it got me thinking about

00:08:27.120 --> 00:08:28.639
layout engines with text,

00:08:28.639 --> 00:08:35.120
so it was interesting.

08:35.120 --> 00:08:38.560
And here's a small

00:08:38.560 --> 00:08:46.080
Unicode character viewer

08:46.080 --> 00:08:55.279
capable of showing a bunch of characters.

08:55.279 --> 00:08:57.279
If this piques your interest,

00:08:57.279 --> 00:08:59.200
I would encourage you to check it out.

08:59.200 --> 00:09:01.440
tui should be usable by anyone

00:09:01.440 --> 00:09:04.640
with some basic Elisp familiarity,

09:04.640 --> 00:09:09.680
no prior knowledge about JavaScript

00:09:09.680 --> 00:09:12.080
or React is necessary.

09:12.080 --> 00:09:13.732
I'd absolutely love to talk with people

00:09:13.732 --> 00:09:14.880
about the tui package,

00:09:14.880 --> 00:09:17.440
textual user interfaces in general,

00:09:17.440 --> 00:09:19.040
and really anything in Emacs.

00:09:19.040 --> 00:09:20.693
If you have any ideas, feedback,

00:09:20.693 --> 00:09:21.680
or want to contribute,

00:09:21.680 --> 00:09:23.360
please reach out.

09:23.360 --> 00:09:24.360
Thank you all for listening.

00:09:24.360 --> 00:09:27.000
[captions by bhavin192 (Bhavin Gandhi)]