hoschi / yode

Yode - Focused Code Editing
https://hoschi.github.io/yode/
MIT License
30 stars 1 forks source link
ast code editing javascript

Yode - Focused Code Editing

npm version lerna Build Status

Edit smaller parts of a code base, so you can focus better on the important parts of a task. You can edit functions of JavaScript code as deeper level of a file. By focusing on functions of interest you can open an editor for each of it and arrange them to serve as context of your work. This frees you from the clutter of the rest of the file, containing this function. Yode is designed as library, so it can be integrated in existing text editors (NeoVim, Atom, ...).

Introduction Video

Yode Introduction Video

Motivation

I love text editors and I am a Vim/NeoVim user for years now. The power you get from a modal editor and such memoizable commands like ciw (change inner word) is very usefull when writing code. There are more editors out there, for every kind of person at least one. So I don't want to write a new text editor, instead I want to give them even more power.

Code is saved in files and with your text editor of choice you edit them, fine. They even help you by recognizing patterns (text objects) like words, lines, paragraphs, blocks in brackets and so on, great. For soucre code there is a version which is even more descriptive, called abstract syntax tree. I want to bring this knowledge to text editors so they can make use of it. For some ideas what could be done with this knowledge, just keep reading. When reading a file into the text editor it should be converted to an AST and from then this is the source of truth. This means when you change text of a node it gets converted back to an AST. Every time the AST or some part of it changed, the whole AST of the corresponding file gets written as text into the file, so the file is the destination of truth. This is important, because every other tool can still work with files and doesn't need to change anything. It also means you can still use features of your text editor which work on files like search/replace, removing files from disk and so on.

The smallest editable container in a text editor is a file. But files contain a lot of code, they group some kind of stuff together so you don't get too much files. This is a good thing, because you need an overview of your current code base. When you tackle a task you search the files you need to edit and then the parts of them which you need to change. At this point current text editors leave you a little bit alone when you want to organize these parts. Yode gives you the possibillty to focus on smaller parts of code than "a file". This prototype adds another level of changabillty, function nodes of the AST. A function can have its own editor, which is just an instance of your text editor but editing not a whole file. This way you can still use the features of your text editor, but in a more focused way. By removing all other content of the file around the function of interest, you remove clutter. By removing clutter, you get more screen space for other parts of code you are interessted in. Editing AST nodes brings also another way to navigate. Instead of switching between files you can now switch between nodes in the hierarchy the tree represents. You can drill down deeper into a node when you are interessted in an even smaller part of the current code. The other way around, you can walk up the tree to get a better overview when you lost track.

Features

Features of library accessible through prototype UI:

Demo

https://hoschi.github.io/yode/

Sourcemaps are included, check console for profile logs which can be used as debugging entry point.

Current state of screenspace management

Splits are the current way to divide the editor screen into spaces which can show different parts. These parts can be different files or different parts of a file. A split has a (fragile) connection to the position it shows. In NeoVim you can create a split and scroll the current line to the top of the split. This position is mantained when you insert text above or below the current content of your split in another tab/split, which is already usefull. Unfortunately the position gets lost easily:

This makes the split useless, because you aren't looking at what you want to see anymore. You can close the split or manually reposition its content to show what you want to see.

NeoVim uses the tab/split model where you have tabs which contain splits. Other editors e.g. Atom uses the split/tab model where you split the screen and in one split you can have tabs. Latter model is even more useless, because now the size of your split must fit the size of content showed in each tab.

Yode solves a bunch of these problems by creating view containers which have their size connected to their content. This way you must not resize the view container you edit at the moment or other containers around. When more view containers visible then screen space availible, you still need to position them to view what is important to you at the very moment. In addition the current implementation of the prototype could be changed, so you can dip out of the "size of function editor is size of content" model, if you prefer this.

A first implementation of layout logic should help you with positioning by e.g. moving to top(/left) what is most important for you. You just mark the editors which you want to focus and layout logic shifts these windows to top, where all other go below of them. After that this can be improved or the user can select different layout logics per tab. As layouts used in Xmonad to manage window position in different ways

Implications

The features of current state implicate additional ones for the mature version of the library integrated in a real editor:

Roadmap

This project is actively mantained and development. It is a side project, so don't expect a full time working pace.

Name

"Yode" comes from the english word "node", because you edit (AST) nodes. I swapped the letter "n" with a "y". Y you ask? Y not! :sob:

Additional docs

Known issues

As this is a prototype, the list is not complete.

Contribution

Use the issue tracker for all kind of questions, bug reports, etc. I'll tag it then as needed. As the project is fast moving at the moment, ideas, general discussion and research about the problem space are also a good way to contribute. I'll collect them and pick it up when it is appropriate. As the current milestone is refactoring and the ideas for the next one are pretty roughly described, contributing with code is at the moment difficult. Please create a ticket, before submitting a pull request.

Ressources

These projects helped me a lot when developing this :heart: