This issue is particularly bad in Python, where a block is the same size as an expression statement is the same size as a call and so are indistinguishable with the region overlay. Tree-edit should detect this case and display the current node type.

• Node keybindings should be named
• #29
• Nodes should allow grammar overrides

Hi! I recently tried to run the code, and got prompted by this message:
tree-edit-view--setup: Sorry, I hardcoded this mode to only work with evil-tree-edit. Please remind me if I forgot!

I understand that this is a work in progress and I do not expect this to be fixed soon (or at all, as you owe nothing to us), but I wanted to ask if the code may be ready for use without evil-tree-edit and you just forgot about the prompt!

In any case, I thought that it may be useful to keep this github issue open until that changes.

Thank you!

It should be obvious when ERROR nodes are present in a buffer so users aren't surprised that editing operations don't work.

hey! great presentation at emacsconf - thanks for pouring time into this project :)
i'd love to try it for my daily work, but i use mainly golang. i'd like to add support but it doesn't seem as straight-forward. would you like me to collect questions here or do you prefer another channel?

(Elisp)-tree-sitter represents sections of the code it cannot parse as ERRORsymbol tokens. Currently the parser will fail as if a transformation is invalid if any ERROR tokens are present. Instead, we should check if the tokens in an operation contain ERROR, and alert the user that their code is malformed if so.

New 'layered' package model I'm considering:

1. tree-edit-core: Core structural editing logic, what tree-edit.el is currently. To be used by refactoring packages or those who aren't sold on modal editing.
2. tree-edit: Movement layer on top of tree-edit-core, wrapped interactive editing commands which operate with a buffer-global current node, and other functions which are not strictly necessary for usage as a library. This would be extracted from evil-tree-edit. To be used by those who want an opinionated set of editing commands and are bought into modalism, but not the evil ecosystem. Same dependencies as tree-edit-core
3. evil-tree-edit: Defines evil state, specific keybindings, etc., with dependencies on evil and avy. For the evil among us... >:)

Unless we're testing formatting, we shouldn't be performing assertions about the text of the specific buffers, but their ASTs.

Due to Python's whitespace-based parsing, there are oftentimes nodes with identical boundaries. For example, {foo;} in Java would simply be foo in Python, but the structure still implicitly exists. The node in the hierarchy affects what editing operations are valid, so that's something to keenly be aware of working in Python.

TODO:

• Complete tree-edit-syntax-snippets for all nodes (d151e7f)
• Add keybindings in tree-edit-nodes for all nodes (d151e7f)
• Disallow empty blocks (ab07ec5)
• Fix tree-edit--parse-fragment parsing expressions as expression statements (deaac61)

The codebase uses user-error, but we should probably make a tree-edit-error in case anyone wants to catch it.

Currently attempting to avy jump to a call in Python in the following scenario will only yield one choice, due to the node layout:

[[foo()].baz()]

This is because the avy jump is based on the start point of node range. How can we address this?

Switch to the end point of the node.

This could work, but has two issues:

1. When do we decide if we should use the end node? If the no. unique start points < no. unique end points?
2. Behavior needs to not be surprising to users. Could be mitigated with a (message "Start points are not unique, ...")

Currently the tests use the 'production' language configurations, which means the tests will need to be adjusted if we change the whitespace formatting, etc. Instead we should have test language configurations.

Query bindings should be able to jump to abstract nodes (e.g. any binary expression). I propose abstract bindings should exist on the double keys, so bb would select any binary expression.

This repo would mirror tree-sitter-langs, parsing the grammar JSON files for usage. Not sure whether language customization would better fit in this repo, or there.

It would be cool and useful to integrate with tree-sitter-debug-mode to see exactly where the currently selected node exists in the AST.

The tree-edit API isn't specific to evil, so it would make sense to split that out. There is a global current node, though -- do we need to drop that as well? There also should be a way to disable the default keybinding if folks would like to set up their own.

There are many node types that are only valid in a specific context. For example, a dictionary pair (key : value) is only valid within a dictionary node. Sometimes the error recovery can handle these cases, but in other cases it can't.

Possible solutions

Use the outer node when parsing

We can try to somehow use the syntax snippets in order to create the proper context, i.e. put the pair in a {} if the outer node is a dictionary.

Custom parser

We can define a parser where all node types are valid at the top level. This would require a custom parser, which is not viable currently, but may be down the line.

Temporary solution: store the type of a fragment on copy

This would only work for nodes copied with a tree-edit function, but would be an easier temporary fix. Would be a good optimization as well

Tree-edit should be smart about the precedence of nodes, for example in a C-like language: Inserting an + into x * [y] should output x * (y + z), as due to the precedence rules x * y + z would modify the AST of y to place it under a new parent, or inserting * in [x + y] should produce (x + y) * z.

TODO:

• Complete tree-edit-syntax-snippets for all nodes
• Add keybindings in tree-edit-nodes for all nodes
• Address disabled tests in tests/test-c.el

There's a noticable delay once we hit ~10 statements in a block:

    private void foo(String args) {
        break;
        break;
        break;
        break;
        break;
        break;
        break;
        break;
        break;
        break;
    }

The easiest solution would likely be to special case specific node types, like REPEAT[CHOICE...] or other trivial grammar nodes.

A more likely better long-term solution would be to port the performance optimizations in faster-miniKanren to reazon.

Blocks provide the worst performance with the relational parser due to the amount of statements, and receive no benefit from it.

Editing features

• Copy
  Should we be storing the node type on copy, or inferring it on usage? If we store type on copy, where does that live?
• Paste
  New text-object/type should be added, so node in the clipboard can be replace, add, wrap, etc. If inferring on usage, each language could need to provide some wrapper string to parse correctly, i.e. 3 is not a valid C expression.
• #23
  Copy current node, replace with provided, avy select a node with current node's type, paste and remove from clipboard. It should fail if there are no nodes to replace.
• Undo
  Just needs to update the overlay afterwards.
• Change
  If the current node is one that can determined by a regex, delete node and drop into insert mode. On exit of insert mode, re-enter tree mode with same node selected.
• #41
  http://oremacs.com/lispy/#lispy-move-down
• #44
  http://oremacs.com/lispy/#lispy-raise-some
• Per-mode customization of formatting and indentation of inserted nodes

Language support

My thoughts are that at least 3 languages should be supported before the API is locked in, as it's likely that there's been some bias in the API.

Leaning towards Java, Python, and Bash, as that's what I'm familiar with.

Documentation

• Fully flesh out README documentation
• Add some SVGs?
• #28

Currently the relational parser accepts a nested grammar alist and recursively pattern matches on it in order to run. This is likely creating a moderate performance hit (need to measure this).

Instead it would be ideal if we could create a relation by initially feeding in the grammar alist, and remove the pattern matching afterwards completely; essentially moving the computation to 'compile time'.

tree-edit has configurable rules on whitespace formatting (see tree-edit-whitespace-rules), but it currently does not respect any pre-existing formatting that may be in place.

Currently the tree-edit syntax generation and rendering relies on the
assumption that all modifications of the syntax tree would operate on a
contiguous region (adjacent siblings).

For example, if we have ("(" identifier "," comment [identifier]) and perform
a deletion, we'd like the result to be ("(" identifier comment), and the
comment should be left unmodified.

Related to #18

Need to deal with inlining rules during parsing: https://tree-sitter.github.io/tree-sitter/creating-parsers#hiding-rules

Example: https://github.com/ethan-leba/tree-edit/blob/main/tree-edit-java.el#L95

These set of bindings should fall under an operator prefix map.

Copy current node, replace with provided, avy select a node with current node's type, paste and remove from clipboard. It should fail if there are no nodes to replace.

Let's say we want to turn this expression String input = null; into input = null; by deleting String. This seems reasonable, but would take us at the syntax-tree level from a local_variable_declaration to an (expression_statement (assignment_expression)). How can we support this?

This is because inline nodes are not included in node-types.json. node-types should be dropped, and if '(,subtype) parses for a given type, then it's a supertype of subtype.

http://oremacs.com/lispy/#lispy-raise-some

Tree-edit should validate at some point (during CI?) if the token sequences
defined for each type in tree-edit-semantic-snippets is actually a valid construction.

This should be fairly simple to implement, just take the text of the given node and insert it to it's left (or right) via tree-edit-insert-sibling.

!!!

Limit to the nearest sig. block? Or to grandparent?

Using helpful-key on edit operations won't provide a named function, since the
edits are defined as a lambda. This should be fixed. Maybe a tree-operator
state? Open to other (easier) ideas.

http://oremacs.com/lispy/#lispy-move-down

This should just be a pre-flight check before one of the parser operations (tree-edit--replacement-p, insertions, deletions) that throws an error if tree-edit-grammar is nil.

File explaining the usage of evil-tree-edit.

See http://www2.geog.ucl.ac.uk/~plewis/teaching/unix/vimtutor and https://github.com/abo-abo/lispy/blob/master/lispytutor/lispytutor.el

Frankly I don't use Java enough to really care about supporting it -- it just seemed like an easy grammar to start with. So help wanted!

TODO:

• Complete tree-edit-syntax-snippets for all nodes
• Add keybindings in tree-edit-nodes for all nodes
• Add sane whitespacing rules

Explain basics of tree-sitter API, and show how to use with tree-edit functions.

Would be interesting to add property testing to validate that tree-edit's editing operations are always correct, i.e. on some random correct syntax tree perform an abritrary action and assert the result is still valid.

A la vim, 2ae would append 2 expression statements, etc...

Currently just gives a message about a null pointer, should be something like tree-edit does not support {mode}.