commit 2e2a3f560c04602de8f47aa8578242f3f5afb0ff
parent 92e8f1f2b76ea6c38ffa9194d36c258a253cf273
Author: Charlie Stanton <charlie@shtanton.com>
Date: Tue, 4 Aug 2020 14:00:38 +0100
Second drafts ex
Diffstat:
| M | posts/ex.md | | | 155 | +++++++++++++++++++++++++++++++++++++++++++++++++------------------------------ |
1 file changed, 97 insertions(+), 58 deletions(-)
diff --git a/posts/ex.md b/posts/ex.md
@@ -1,77 +1,116 @@
-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.
+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.
-### So what's wrong with modal editors then?
+### Minimise the brain to editor gap
-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
+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);`.
+Doing this with an existing editor requires me to do
-TODO combine these into one more fluid issue
-### Issue 1: I want a code editor
+- Find the function
+- Find the line that return starts on
+- Select the whole expression (how this is done depends on the editor, but I don't think any of them have a text object to select an expression)
+- Wrap it in a function (probably with a keyboard shortcut)
-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.
+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
-### Isn't that just an IDE?
+- Find the function
+- Find the return expression
+- Wrap it in a function
-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.
+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
-### Can an ex like editor do this?
+### Edit code not text
-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.
+Editors have drifted towards more semantic features for ages now, with language server protocol, paredit and ctags being excellent examples of this.
+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.
+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?
-### How could an ex-like editor improve on this?
+### A cursor only makes sense for inserting
-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
+This is something that I think is obvious now I've realised it, but because of its universal use, I hadn't considered before.
-### Issue 2: I don't want a cursor
+Why do I need a cursor while I'm viewing/moving/deleting code?
-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.
+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.
-### How could an ex-like editor fix this?
+### A shell for code
-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.
+How about instead of a working position, 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.
+So again a middle ground is needed.
-### Bonus issue: config
+### The display
-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.
+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.
+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 solution: ex (sort of)
+### The workflow
-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.
+- 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
+- Make semantic changes
+- If the feature still needs work save the views and working selections to a register while you work on something else, then come back later
-TODO Somewhere mention how this is like using the filesystem with a shell
-TODO mention several working selections
+### Customisation
+
+These days everything has a massive config file and an API to allow the user to bend the software to their 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
+
+- No runtime overhead
+- No limits on what is possible
+
+> 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.
+
+### Simplicity
+
+Up until now I'd understand if thought I just needed an IDE, but here's why you're wrong.
+If you haven't already, maybe read [Text Editing Hates You Too](https://lord.io/blog/2019/text-editing-hates-you-too) which highlights some of the pains of making modern text editing software.
+
+- Getting a cursor to behave in a way usable by people is really hard.
+- A data structure that can hold a large text file and update it quickly is quite complex, although xi managed it.
+- The complexity of semantic features is massively increased by having the document checked on every keystroke, most of which will be while it is in an invalid state.
+
+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.
+This will allow for a much simpler codebase.
+
+### 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.
+
+### Conclusion
+
+This is mostly just me playing with ideas.
+I don't know how this would actually look and feel in a real editor, but I plan on finding out.
+Maybe there'll be a another post one day with details of a working usable editor, based on ex that I'll have written.
+Maybe someone else will see these ideas and agree with one or two of them and build something new and impressive.
+Maybe all my ideas suck and I'm completely dillusional.
+Either way I'd appreciate you letting me know any thoughts this has provoked via my email, charlie@shtanton.com
