commit 92e8f1f2b76ea6c38ffa9194d36c258a253cf273
parent 802682842933911f1cc201b5b1e8e6f4810cdda3
Author: Charlie Stanton <charlie@shtanton.com>
Date: Mon, 3 Aug 2020 17:02:23 +0100
Adds first draft for ex.md
Diffstat:
3 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/config.json b/config.json
@@ -0,0 +1,9 @@
+{
+ "posts": [
+ {
+ "title": "Reviving ex in 2020",
+ "file": "ex",
+ "date": "2020-08-03 15:06:32"
+ }
+ ]
+}
diff --git a/posts/ex.md b/posts/ex.md
@@ -0,0 +1,77 @@
+Over several years I've been on a text editor journey backwards in time, in chronological order, my primary programming interface of choice has been DreamWeaver, brackets, VSCode, emacs, vim, kakoune.
+With the exception of kakoune, I've basically jumped to an editor with less features at every step, but there's a good reason for this, a lot of the modern abstractions in text editors seem like good ideas but aren't.
+I want an editor that is an extension of my very self, I want to be as close as possible to thinking about the change I want and then seeing it happen, so I want abstractions that match the way I think.
+As an example, people who use modal editors like vim and kakoune often mention that a programmer spends only a little bit of time writing new code, but a lot of time reading and modifying existing code, hence it makes sense to be in a "normal mode" most of the time for exactly that.
+I should clarify, I'm not gonna be using ex, but I do want to write a new editor based on it.
+
+### So what's wrong with modal editors then?
+
+My issue with existing modal editors stems from 2 things: 1) They are text editors and not code editors 2) They have a cursor which indicates which part of the file you are editing right now
+
+TODO combine these into one more fluid issue
+### Issue 1: I want a code editor
+
+When I'm thinking about code, the objects that I'm concerned with are functions, variables, parameters, types etc. Not characters and lines.
+Nearly every editor I've seen allows you to move around a document treating it as a grid of characters.
+You can go up, down, left, right, start of file, end of file, start of line, end of line, forward a word, backward a word etc.
+A lot nowadays have some motions for select inside brackets or select both open and closing tags of HTML, but this is clearly an addition to an editor focused on editing text.
+LSP helps here to with features like rename and jump-to-definition but I want to be able to move around primarily by searching for a symbol, or jumping to a function definition.
+If I want to edit a function I know the name of, I don't want to look at the screen to jump there.
+If I want to add a new parameter to every function ending with "test" over the whole project, again, I don't want to need to search the code to do that, the editor should make it easy.
+Sure that's a contrived example, but very occasionally I want to do something like this and lose several minutes of productivity.
+I think most people are well aware that this is a feature they want, as there are a lot of efforts to get more semantic features into editors, to name a few:
+language server protocol, paredit, folding function contents, ctags
+When I think about functions, I don't consider them to be in an order, just like the compiler doesn't care which order to functions are in.
+I should be able to work on 2 related functions as if they are the only 2 functions in a file and in an order convenient for my editing.
+
+### Isn't that just an IDE?
+
+Nope, I definitely don't want an IDE.
+What I want should be light, not integrated with build systems or debugging, not cluttered with a million different windows of information.
+
+### Can an ex like editor do this?
+
+The part of this that visual editors struggle with is that by always displaying lines of characters as they appear in the file, they don't have the ability to show you a filtered view of just function signatures or just variable definitions local to a function.
+When an ex user wants to see part of the code they specify what they want to see.
+If the method for specifying this is concise and understandable, it can be extended to also have commands that show particular parts of the file.
+
+### How could an ex-like editor improve on this?
+
+Right now ex also shows parts of the file using not very clever line and regex based selections.
+But it would be relatively straightforward to add new smart selections:
+list function signatures,
+delete the second argument,
+add a statement just before the return of a function.
+These are all much more suited to an editor like ex
+TODO expand on this
+
+### Issue 2: I don't want a cursor
+
+This I realised more recently.
+A cursor makes sense only when inserting new code which, as previously mentioned, is probably 10-20% of the time in my case.
+Even with issue 1 taken care of, moving around the file is still gonna be a massive pain as long as you have to think about both where you are and where you want to be.
+The best way for moving around a file that I've found is a mixture of easymotion and ctags.
+This works quite well with one cursor, but easymotion and multiple cursors just don't mix.
+
+### How could an ex-like editor fix this?
+
+Now always specifying every edit relative to the root of the project is gonna be way too slow, but just because there isn't a cursor doesn't mean there can't be a "current working selection" (or several!).
+This would function much like a working directory in the shell, where initially the current working selection is everything.
+Once you want to work on a feature, you set the working selection to everything that concerns that feature, and then you can use much shorter selections for working until you move onto something else.
+This way, a change should be along the lines of a ~5 character command to remove everything you don't want, and then a bunch more characters to type out what you want to replace it with.
+
+### Bonus issue: config
+
+Using config files is unnecessarily bloated and limited.
+For something like a text editor which should be incredibly fast to start up, a very small binary and highly configurable, a config file is not enough.
+This is why most modern text editors are configured with a programming language like shell scripting, python, vimscript, elisp or javascript, and not TOML or JSON.
+Personally I think a text editor running an entire interpreter just to configure it is insane and a massive waste of computing power.
+Suckless software is mostly configured just by modifying the source code and recompiling, time that they would've spent adding support for a config file is instead spent cleaning up the code, making it possible for newcomers to understand it.
+
+### The solution: ex (sort of)
+
+So ex as it exists now doesn't solve any of these problems, but the line editor as a concept can solve all of them.
+I've got some ideas for specifics but I'm gonna save them for another post I think.
+
+TODO Somewhere mention how this is like using the filesystem with a shell
+TODO mention several working selections
diff --git a/testfile b/testfile
