Add an article on application windowing

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
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
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