commit 55497256c1237a1eee87752cf9cb60305b3d6cf3
parent 2e2a3f560c04602de8f47aa8578242f3f5afb0ff
Author: Charlie Stanton <charlie@shtanton.com>
Date: Tue, 4 Aug 2020 14:29:47 +0100
Does third draft of ex
Diffstat:
| M | posts/ex.md | | | 63 | ++++++++++++++++++++++++++++++++++++++++++--------------------- |
1 file changed, 42 insertions(+), 21 deletions(-)
diff --git a/posts/ex.md b/posts/ex.md
@@ -1,9 +1,12 @@
-I think programming oriented text editors in 2020 still feel like they're missing a lot, and I think that a modern editor more like ex could fix most or all of these problems, here's why.
+I think programming oriented text editors in 2020 still feel like they're missing a lot, and I think that a modern editor more like ex could fix most or all of these problems. Here's why.
### Minimise the brain to editor gap
-What I mean here is that the way I tell my editor what to do, should closely match the way I think about what to do.
-For example, I think I want to pass the return expression of a function through another function, `return expr;` to `return modified(expr);`.
+The way I tell my editor what to do, should closely match the way I think about what to do.
+
+For example:
+I think I want to pass the return expression of a function through another function, `return expr;` to `return modified(expr);`.
+
Doing this with an existing editor requires me to do
- Find the function
@@ -13,20 +16,22 @@ Doing this with an existing editor requires me to do
The really annoying part here is selecting the expression, which either has me using a mouse (eurgh) or using a keyboard shortcut that will work here but wouldn't in other places.
Here I could jump forward one word to get to the start of `expr` and then go to the end of the work, or until the `;`, but these couldn't handle an expr spanning multiple words or one that contained a `;`.
+
This is work my brain does which the editor could do, the process should be
- Find the function
- Find the return expression
- Wrap it in a function
-I'm not think about text when I think about a code change, I'm thinking about semantics, so the operations I'm dictating to the editor should be semantic
+I'm not thinking about text when I think about a code change, I'm thinking about semantics, so the operations I'm dictating to the editor should be semantic
### Edit code not text
-Editors have drifted towards more semantic features for ages now, with language server protocol, paredit and ctags being excellent examples of this.
+Editors have drifted towards more semantic features for ages now, with language server protocol, paredit and ctags being excellent examples of the demand for semantic editors.
Even with these, the editor feels like a text editor with semantic features and not a semantic editor.
-There's a definite demand for an editor that has you working with an AST.
-If ex is a line editor, we should aim for an AST editor.
+
+> If ex is a line editor, we should aim for an AST editor.
+
Instead of printing ranges of lines, we could print function signatures, or globally defined types, or construction sites of a struct.
This feature doesn't necessarily require an editor like ex, but the large number of motions available with this system would likely require at least a modal editor, so why go even further and abandon the whole visual interface?
@@ -34,32 +39,33 @@ This feature doesn't necessarily require an editor like ex, but the large number
This is something that I think is obvious now I've realised it, but because of its universal use, I hadn't considered before.
-Why do I need a cursor while I'm viewing/moving/deleting code?
+> Why do I need a cursor while I'm viewing/moving/deleting code?
Obviously for just looking at the code, a cursor is pointless and losing it allows for the more customisable views I mentioned earlier, but for doing anything other than inserting in a modal editor it boils down to moving the
cursor roughly to the site of the edit and then specifying the text object and the action.
This means that the sequence to do a change often relies on where the cursor is now, as that dictates which motion you use to get it where the change is happening.
-This is more unnecessary brain work.
-However, perhaps worse is always globally specifying the site of an edit relative to the project root, so ideal should be somewhere in between.
+This is more unnecessary brain work, but globally specifying the site of an edit relative to the project root is worse.
+Ideal is in between.
### A shell for code
-How about instead of a working position, a working area, much like the current working directory in a shell.
+How about instead of a working position (cursor), a working area, much like the current working directory in a shell.
With this idea comes the realisation that what we're approaching is fundamentally a shell for manipulating code instead of a file system, which is a brilliant idea.
I used to use a graphical file browser to work with file systems, but having got so proficient with the shell, it's now faster for me to use that. It is also vastly more powerful.
Only focusing on a single code object at a time would also be cumbersome, but why not have a working selection be many objects, and have registers for these selections to be saved to and loaded from?
-File systems and code are both basically trees, but files basically just have names, and you aren't really concerned with the contents while browsing. Not so with code.
+File systems and code are both trees, but files basically just have names, and you aren't really concerned with the contents while browsing. Not so with code.
So again a middle ground is needed.
### The display
Ex requires if you want to see some code you specify which code you want to see using some line numbers or regex etc.
The new editor can have more advanced ways of selecting what to see, but it is still not gonna be usable if you are constantly printing the same bit to see your changes.
-I propose printing creates a window with that view of the code, and it updates with any changes the user does as they do them.
+I propose printing creates a window with that view of the code, and it updates with any changes you do, as you do them.
+
To clarify, it is only displaying, no cursors allowed.
The option for the simpler printing should still be there, as it would be useful for shell scripts or editing over ssh.
-### The workflow
+### The OOTB workflow
- Move the current working selection(s) to everything concerning the feature you are working on
- Bring up a couple of views to see what the current state of affairs is
@@ -68,7 +74,7 @@ The option for the simpler printing should still be there, as it would be useful
### Customisation
-These days everything has a massive config file and an API to allow the user to bend the software to their will.
+These days everything has a massive config file and an API to allow you to bend the software to your will.
Being able to configure software is certainly a good thing, but config files, GUI settings menu, an extra program to send messages over sockets, an entire interpreted language etc. these are not the way to do config.
Suckless gets this right.
Their software is configured by modifying the source code
@@ -76,10 +82,13 @@ Their software is configured by modifying the source code
- No runtime overhead
- No limits on what is possible
+A lot of people might think
+
> Modern text editors are highly complex! How could I possibly tweak the source code?
This problem has 2 solutions, don't tweak the source code, or make the code simpler and more understandable.
Pretty much everyone took the wrong path here.
+
In June of 2019, I fixed a tiny bug in vim, [PR 4584](https://github.com/vim/vim/pull/4584).
It took me over 4 hours to figure out how the code worked, and vim is maybe the simplest editor usable for day to day programming.
@@ -94,17 +103,29 @@ If you haven't already, maybe read [Text Editing Hates You Too](https://lord.io/
Ex doesn't have a cursor which removes pretty much all of this complexity.
To insert text you select where it's going to go, then enter it all in as a block.
-Inserting that one block requires changing the file buffer and recomputing the semantic features once, instead of hundreds of times.
-This means these processes can be slightly slower, but wayyyy simpler.
-The block of text you work on is small enough that the cursor doesn't need to be able to move really, you just type and can backspace if you make a mistake.
-If a mistake is bigger, finish that block and change it with another command.
+Checks only happen once when the block is actually inserted, meaning structures and algorithms for handling the text and semantic features can be slightly slower and much simpler.
+Plus, the cursor when working on a block can be simple, just typing and backspace.
+A mistake too big for backspace can be fixed with another command.
This will allow for a much simpler codebase.
+Also special mention to electron apps which get around this complexity by being unacceptably sluggish.
+
### Learning curve
Although the source code will be a lot simpler than most projects, it's still an editor drastically different from every other currently in use.
-Being usable for everyone, is not a goal here.
-It would be suited for power users who are happy to invest significant time into learning to use it fully before being productive, and even then probably will cap at around 20% faster since existing editors are already so good.
+
+> Being usable by everyone, for everything, is not a goal.
+
+It would be suited for power users who are happy to invest significant time into learning to use it fully before being productive, and even then probably will at best make you marginally more productive.
+But that would be enough for me!
+
+### Why aren't these features already being used?
+
+Most of them just because this whole idea is crazy outlandish.
+The one that could is the semantic features, but these features tend to be incredibly hard to implement in a language agnostic way.
+The best we have currently is LSP which is language and editor agnostic, but not even close to what I want out of a new editor.
+This new editor would have to be (at least initially) specific to a language as finding abstractions that allow it to work on any language would be incredibly difficult.
+Only once it has a foothold would that be worth pursuing, maybe as semantic features in other editors grow, this issue will be solved though.
### Conclusion
