diff options
Diffstat (limited to 'src/blog')
| -rw-r--r-- | src/blog/index.gsp | 1 | ||||
| -rw-r--r-- | src/blog/windowing/better.png | bin | 0 -> 1217316 bytes | |||
| -rw-r--r-- | src/blog/windowing/index.gsp | 216 | ||||
| -rw-r--r-- | src/blog/windowing/oops.png | bin | 0 -> 1168926 bytes | |||
| -rw-r--r-- | src/blog/windowing/split.png | bin | 0 -> 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew file mode 100644 index 0000000..df81be4 --- /dev/null +++ b/src/blog/windowing/split.png |
