gushogg-blake

Ah OK. Tree mode navigation only works on whole lines as I think there's benefit to keeping the model simple and text cursors are good enough for horizontal navigation. I do have a couple of ideas for this though - 1) a key to select the condition so that you can edit it in normal mode (standard text editing), e.g. select the if then press c to change the condition; 2) some way of temporarily expanding single-line constructs into multi-line ones so that the vertical navigation commands navigate and edit them - so you would navigate to it then press a key that would temporarily expand the if (condition) to if (\n\tcondition\n). This would also work with things like argument lists - temporarily expand to get the arguments on separate lines for editing.

Thanks for the feedback!

- can you move into an if/while if it's not already selected? For already selected blocks I've had it both ways and found it better to be able to drag from anywhere in the block - you can select a child by clicking it. Both ways have their advantages and disadvantages though. "d" should also work to navigate to a block's first child.

- yes maybe some kind of visual indicator would be good, but if required after the first few uses then the interaction would need to be redesigned I think, as there shouldn't be any unexpected or unintuitive behaviour

- hmm, that's working for me, does anything at all happen when you drop it?

- yeah, haven't implemented that yet

I thought about doing it as a plugin as well, but I think trying to add something genuinely new to an existing editor would be possibly harder than just making one (I've been working on Treefrog for about 7 months full time and using it as my only editor for the last 2), and would end up either not fitting in well with the existing UI or having clunky UX to switch between modes etc. Designing new modes from the ground up (and being able to prototype them quickly with web tech and Electron) allows for much easier experimentation.

Yes, sort of, but they've always been added on top of a standard text editing interface so tend to be behind context menus (which is OK as they're also often high-level refactorings that aren't used that often). Treefrog's structure-aware edits are lower-level and more deeply integrated into the editing interface - there's a whole mode dedicated to them where the mouse and keyboard behave differently. The aim is to design an intuitive editing interface; the AST itself is just one tool to help with that.

Right - this is where I would use an LSP server

Thanks - fixed

Thanks! Error should be fixed now

So things like classes and functions would be represented as files within a dir representing the actual file?

Ah yeah, it's canvas based so I suppose it will be being scaled like an image. Thanks!

Interesting! Yes, one of the main things I'm doing at the moment is thinking of and prototyping new commands and ways to represent code. I like the shell idea.

Current langs are javascript, html and (s)css - there's a dropdown on the toolbar to create a new file in a given lang (the others there are partially supported, no Tree mode commands). The goal is to support all popular languages, as they can be added fairly easily with tree-sitter grammars.

Thanks! Are you on a mac? Someone else noticed it on mac, just on the actual editor, so I thought it might be to do with rendering text on canvas (sometimes you have to use half-pixel coordinates to get things to align properly)

I wonder if it was important that an actual abstract syntax tree was used? I'm realising the title might be a bit misleading - it should probably be "AST-inspired" commands, as the tree-sitter trees are technically concrete as opposed to abstract and the commands aren't tightly coupled to a particular representation.

Thanks. Just checked and j/k are actually not implemented yet, so that explains that!

It's more that the selection operates on whole lines in Tree mode, so it would parse fine with the tree-sitter grammar (for syntax highlighting etc) but selecting the inner contents of a block would take the block's closing ) with it. This would only matter if you wanted to move the contents somewhere though - editing and refactoring commands (including with the help of LSPs) will work, with the selection being the outermost node on the first selected line.

I'm not necessarily against it in the long term, just keeping all options open for now as I want to be able to work on it full time and that obviously involves making money somehow.

Nice! One thing I thought ASTs weren't that good at was the initial writing of code - did you find that?

:) I was surprised touchpad did anything tbh - turns out it sends wheel events with different deltaY/deltaX values, so I just had to use the actual values instead of what it was doing before (checking if < or > 0 and scrolling by 3 rows/columns worth)

Yeah, that's one of the main issues with ASTs and why I think they make the same mistake as text editors ultimately - designing around a particular data structure just constrains you into weird UX scenarios that don't have anything to do with the actual problem of making something that lets you write code.

One example would be turning a group of statements "xyz" into "if (some condition) then xyz, else (something else)" - with a text editing interface you have to think a bit about the exact text selection you want (or enter visual mode in vi to get the lines), cut them, write the if statement, paste them in, and usually some reformatting, whereas with Tree mode (the dedicated mode for expressing meaningful edits to the code) you can do Esc-w for "wrap", type the if statement, and insert the original statements from a dedicated clipboard.

Other cases are similar, e.g. being able to just drag and drop a div into another div without thinking about the exact text selection - the benefit is having to think slightly less about the mechanics of your editor or the particular data structure (text or ASTs).

Yeah, tree-sitter and LSP are both steps in the right direction I think.

Yeah using them as is and haven't had any issues so far. I think they are at a slightly lower level of abstraction than an AST, e.g. an async method in JS is a method_definition with an "async" node followed by a property_identifier, whereas an AST might wrap all this into an AsyncMethod node - but all the info you need is there.

Thanks! Yeah, I think of refactorings as being a level of abstraction above text and AST editing - kind of like macros for AST edits.

Should be fixed now

I haven't added any yet, but all parsing is done with tree-sitter so languages can be added pretty quickly. One issue is that tree mode works on whole lines (I think the benefit of AST-style navigation vs moving a text cursor diminishes as the selections you want get smaller), so it's better suited to languages where the blocks are naturally separated by newlines as opposed to the ")))))" style.

Thanks, I haven't tried it on a touchpad yet, will have a look.

Backstory - I started experimenting with AST editing ideas after getting frustrated with my editor's lack of understanding of the structure and meaning of code, ie. the editing primitives all dealt with text and simple changes to the code often required repetitive manual text edits that had nothing to do with the meaning of the change. I went through a couple of prototypes and landed on the idea of augmenting a standard editing interface with a new mode that works on a simplified representation of the structure, which basically follows indentation levels - blocks of code like functions, loops, etc, can be moved and manipulated as units, and there are specific editing commands for the different elements.

The main idea is to design all of the editing and navigation commands around the thought processes (instead of designing around a data structure, which I think is where traditional editors have gone wrong), so that it feels natural and intuitive to use - like something that's been designed for what editing code actually involves, as opposed to a text editor that's had lots of code intelligence stuff added on top of it.