summaryrefslogtreecommitdiffhomepage
path: root/src/blog
diff options
context:
space:
mode:
Diffstat (limited to 'src/blog')
-rw-r--r--src/blog/index.gsp1
-rw-r--r--src/blog/windowing/better.pngbin0 -> 1217316 bytes
-rw-r--r--src/blog/windowing/index.gsp216
-rw-r--r--src/blog/windowing/oops.pngbin0 -> 1168926 bytes
-rw-r--r--src/blog/windowing/split.pngbin0 -> 1286522 bytes
5 files changed, 217 insertions, 0 deletions
diff --git a/src/blog/index.gsp b/src/blog/index.gsp
index 19f799e..66e35de 100644
--- a/src/blog/index.gsp
+++ b/src/blog/index.gsp
@@ -28,6 +28,7 @@ html lang="en" {
p {-Posts:}
ul {
+ ARTICLE(windowing, {-Application Windowing is Bad})
ARTICLE(extend, {-Extensible Scripting})
ARTICLE(grab, {-Making Grep Better})
ARTICLE(gsp, {-Writing an HTML Preprocessor (feat. Tree-Sitter)})
diff --git a/src/blog/windowing/better.png b/src/blog/windowing/better.png
new file mode 100644
index 0000000..1052ce2
--- /dev/null
+++ b/src/blog/windowing/better.png
Binary files differ
diff --git a/src/blog/windowing/index.gsp b/src/blog/windowing/index.gsp
new file mode 100644
index 0000000..cb2d347
--- /dev/null
+++ b/src/blog/windowing/index.gsp
@@ -0,0 +1,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{-1}.
+ }
+
+ 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="1" {=
+ 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.png"
+ alt="An Emacs instance with two split Emacs windows"
+ {}
+ }
+
+ figure {
+ figcaption {-Oops! Firefox Made My Code Unreadable!}
+ img width="100%" src="oops.png"
+ alt="The window split with Emacs and Firefox on each side"
+ {}
+ }
+
+ figure {
+ figcaption {-Making Things Better}
+ img width="100%" src="better.png"
+ 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 seperate 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 labouriously 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 }
+ }
+}
diff --git a/src/blog/windowing/oops.png b/src/blog/windowing/oops.png
new file mode 100644
index 0000000..50ec706
--- /dev/null
+++ b/src/blog/windowing/oops.png
Binary files differ
diff --git a/src/blog/windowing/split.png b/src/blog/windowing/split.png
new file mode 100644
index 0000000..df81be4
--- /dev/null
+++ b/src/blog/windowing/split.png
Binary files differ