fgeller
commented
2 years ago :wave:
thought i'd add a PR to check if you want to pull this into tree-edit or a separate package. if you do, there's probably still some more tweaks i could do, but as time is scarce/valuable, here's a discussion starter grin
- if you'd integrate it into tree-edit, we could factor out the common functionality from evil-tree-edit
I'd definitely like to factor out the commonalities between the two.
do you want me to give this a go? haven't used evil in a while, but could start the process?
Things that should probably be common:
* Movement and editing functions * Hooks * Some of the overlay stuff? The hide current node overlay stuff wouldn't make sense in evil-tree-edit
agreed, would add the current node as a commonality
I'd really like the mode to have keybindings setup so those who are curious about tree-edit and don't use evil can have something running without any config, do you think you could add that in?
gave it a shot, let me know what you think
- added a notion of desired node types to more quickly travel upwards in the tree (i.e., i often want to jump up to the start of a for loop or func declaration)
An issue with an approach like that is that the lack of fine-grain control will limit what structural editing actions you can take. Maybe you can provide a separate set of functions for large scale vs small scale movement?
evil-tree-editdeals with the sometimes cumbersome node structure by allowing you to avy jump to any node with a certain type within the block, another approach to consider.
need to try / explore the avy-jump alternative, sounds good :) my use case is often somewhat different: some functions span multiple pages and jumping to the beginning or end wouldn't be feasible with avy. haven't used the editing functionality much, but i see your point. but, yes - it's additional behavior, just an analogue to the regular go to parent. or do you think skipping the nodes that share the same range is an issue? could add a bool flag to make it customizable?
- i didn't add all edit / refactoring commands, but doing so is simple as they're just wrappers to add (interactive). i simply added a suffix (-cmd) to the lib version, unsure if there's a downside to adding (interactive) to the lib version?
The downside isn't the
(interactive)part, but that we would need to hardcode the NODE parameter astree-edit--current-node.
that makes perfect sense :)
what do you think of the -cmd suffix?
- raise and other edit commands are fairly slow on my macbook, haven't used the profiler to figure out what's slow
Unfortunately the way tree-edit performs structural editing on nodes is not very optimized, so it starts slowing down once you hit ~20 nodes in a single block. This is something I'd like to work on addressing, but as a stopgap measure you can override how the editing works for certain nodes with large amounts of children: https://github.com/ethan-leba/tree-edit/blob/main/tree-edit-python.el#L120
still need to test this more, will add feedback if it remains an issue
Do you have any ideas about how you'll use commands that take a type? wrap/insert/ec.
not yet :)
ethan-leba
👋
thought i'd add a PR to check if you want to pull this into tree-edit or a separate package. if you do, there's probably still some more tweaks i could do, but as time is scarce/valuable, here's a discussion starter 😁
i use it for motion/movement 90% and then usually work on the selection/marked region, rather than use the structural editing commands. but that's mostly out of habit i believe, and motion works really well.
some changes since the last update on #40:
(interactive). i simply added a suffix (-cmd) to the lib version, unsure if there's a downside to adding(interactive)to the lib version?some open tasks: