1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
html lang="en" {
head { HEAD }
body {
header {
div .head {
h1 {-Windowing Considered Harmful}
INCLUDE(nav.gsp)
}
figure .quote {
blockquote {
p {-Sugar is the new gunpowder}
}
figcaption {-Sayed Jawad al-Qazwini}
}
}
main {
p {=
As of late I’ve been thinking up ideas about a potential future
text-editor of mine. One standard feature of nearly all text
editors worth their salt is windowing: the ability to have
two-or-more files open side-by-side or in other configurations.
At a surface level this might seem like a no-brainer feature —
and one which can substantially increment on the user-experience
— but I think we can do better …by removing it all together.
}
p {=
What I am not suggesting is that people should remove windowing
from their workflows entirely — windows are incredibly useful and
even more so on larger monitors. I instead suggest that we begin
delegating the task of windowing to the tool that does windowing
best: the window manager.
}
p {=
Window managers come in all sorts of shapes and sizes. Most
computer users will be using @em{-floating} window managers;
these are the window managers where you open a window and the
window pops up somewhere random on your screen. As the user it’s
your job to resize the window, move the window where you want it,
etc. This is the standard behaviour on the classic MacOS or
Windows system, along with most mainstream Linux systems.
}
p {=
There are also other forms of window managers such as
@em{-tiling} window managers. These are more popular in the
Linux space although you can find these for other systems too.
The idea behind a tiling window manager is that you delegate the
positioning and sizing of windows to your window manager. The
methods that tiling window managers use to cut up the screen
varies but typically you can expect that launching an application
will cause it to take up the full width and height of the screen,
while launching a second application will cause the screen to be
segmented into two halves, with one window taking up 50% of the
screen on the left and another taking up 50% of the screen on the
right@sup{=MKREF(wm)}.
}
p {=
Why do I mention all of this? I mention this because I want to
emphasize the fact that window management is not an easy task,
and we all have different preferences for how we want it done.
This means that unless you implement an entire window management
solution into your text editor complete with tiling- and floating
window management options, some large subset of your users are
going to be having an experience that is suboptimal compared to
what they could be having. Not only is it suboptimal, but it
differs from the standard behaviour of their system.
}
hr{}
aside data-ref="REF(wm)" {=
This is very dependent on the window manager being used and the
users configuration of it of course, but this holds in the
general case in my personal experience.
}
h2 #code-gone {-Where’d My Code Go?}
p {=
There is a second issue that implementing windowing in your
editor results in, specifically this is an issue that is
extremely prevalent if you use a tiling window manager: it is the
issue of your code disappearing, allow me to explain in three
pictures.
}
figure {
figcaption {-Split Windows in Emacs}
img width="100%" src="split.avif"
alt="An Emacs instance with two split Emacs windows"
{}
}
figure {
figcaption {-Oops! Firefox Made My Code Unreadable!}
img width="100%" src="oops.avif"
alt="The window split with Emacs and Firefox on each side"
{}
}
figure {
figcaption {-Making Things Better}
img width="100%" src="better.avif"
alt="The window split in three panes, not two"
{}
}
p {=
The problem here is quite clear: because I use a tiling window
manager, opening Firefox to read some documentation caused my
screen to be split into two halves — one for Emacs and one for
Firefox — rendering my Emacs buffers unreadable. This is
completely correct behaviour from my window manager and I don’t
expect it to behave any differently, but it is clearly not ideal.
The result we want is the result seen in the third image, where
the window is split into 3 parts allowing me to more easily read
my Emacs-lisp code while simultaneously reading documentation in
my browser.
}
p {=
So how do we go from the second image to the third image? The
answer is obvious: we used three windows. Instead of having one
dedicated Emacs window that itself manages two sub-windows, by
simply breaking it up into two separate Emacs instances each
displaying only a single file, I allowed my window manager to
make a more informed decision about where to place my web
browser. Intuitively this should make sense; if we have two
files in one Emacs window our window manager will have no idea
that we want to see three different things when we launch
Firefox; it will only be aware that we want to see Emacs and
Firefox side-by-side.
}
p {=
Now we need to keep in mind the usability issues that windowing
in text editors attempt to solve; it is unreasonable to expect
the user to need to manually and laboriously open a new instance
of their text editor, navigate to the project they’re working on,
open a file, etc., all just to view two related files
side-by-side. The reason we all use windowing in our editors is
because of how convenient it is to be able to simply click a
button or execute a key-binding and instantly have a second
buffer of text appear on our screen.
}
h2 #solution {-The Solution}
p {=
This is not as difficult of a problem as we might imagine though,
and as I’ll discuss it’s actually not even an unsolved problem.
The first potential solution is to just make your text editor not
slow. We live in the 21@sup{-st} century with hardware that is
unbelievably fast; there is absolutely no reason why your editor
should not so instantly open that it’s done before your finger
has left the enter key or the left-click mouse button. Of course
most software doesn’t do this, but we are living in a world of
never-before-seen inefficient and slow software.
}
p {=
The second solution is a more technically involved one, but one
that has seen real success: the server-client model. The idea
here is that when you use your editor it spins up a server (or
dæmon) with which the editor (the client) will connect to and
communicate with. When you want to open a new file in a second
window, your client can simply launch a second instance of itself
that connects to the same dæmon process. This should in theory
also help to improve startup times as little initialization will
need to be done, most of it will need to instead be done by the
server which after the first client has spawned will already be
complete.
}
p {=
This server-client model also solves a second important usability
issue I have yet to mention in this presentation, and that is
shared state between your windows. Many editors such as Vim or
Emacs have their own clipboards, bookmarks, and registers which
the user can create, store information to, etc., during regular
usage of the program. When a user stores data in their clipboard
in one window that data should be accessible in the other (but
not in a totally unrelated editor session where you’re working on
an unrelated project). By using the client-server model all this
information can be stored on the server, and connecting clients
simply use the server as a middle-man to broadcast changes to
this shared state between other clients.
}
p {=
As mentioned earlier, this is not a new novel concept and has
seen actual success in practice. Emacs is perhaps the best
example of this where many users will spawn an Emacs dæmon on
their system and then connect to that dæmon via the Emacsclient
client program. This allows for both dramatically improved
startup performance, and shared state between client instances.
}
p {=
Another editor that uses such as idea is Kakoune. Kakoune in
fact was designed with a philosophy that I find myself deeply
aligned with; it doesn’t even have the editor windowing support
that I rail against in this presentation. If a user wants to
open multiple buffers in a Kakoune session they must actually
spawn multiple Kakoune clients which will communicate with a
server. All window management is delegated to specialized tools
such as Tmux or your window manager.
}
}
footer { FOOT }
}
}
|
