Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undo tree UI #1075

Open
NNBnh opened this issue Nov 11, 2021 · 14 comments
Open

Undo tree UI #1075

NNBnh opened this issue Nov 11, 2021 · 14 comments
Labels
A-helix-term Area: Helix term improvements A-plugin Area: Plugin system C-enhancement Category: Improvements

Comments

@NNBnh
Copy link
Contributor

NNBnh commented Nov 11, 2021

Come from Kakoune, one of the feature that many feel missing is Undo tree, from Kakoune wiki:

Kakoune keeps track of every modification you make to a buffer.

It does this bookkeeping in a non linear way: it means that if you undo a few changes and then decide to make a new one, it will create a branch in the history tree.

Let's see how it works through a concrete example.

... (Read more)

This seem kinda hard, maybe implement this in the far future.

@NNBnh NNBnh added the C-enhancement Category: Improvements label Nov 11, 2021
@archseer
Copy link
Member

We have an undo tree internally with support for :earlier :later. We just don't have a good way to visualize the tree

@NNBnh NNBnh closed this as completed Nov 11, 2021
@sudormrfbin
Copy link
Member

Can we keep this issue open for implementing a UI for it ?

@pickfire
Copy link
Contributor

pickfire commented Nov 11, 2021

But I think we don't have a shortcut for it. Like g- and g+ in vim. Would be good to have something easily accessible.

@NNBnh NNBnh reopened this Nov 11, 2021
@NNBnh NNBnh changed the title Support undo tree Undo tree UI Nov 11, 2021
@NNBnh
Copy link
Contributor Author

NNBnh commented Nov 11, 2021

But I think we don't have a shortcut for it. Like g- and g+ in vim. Would be good to have something easily accessible.

We could map it to gu undo_tree and gU redo_tree to be more consistent with u undo and U redo

But should we do it like Vim/Kakoune or should we make something like Spaceu undotree_picker ?

@kirawi kirawi added A-helix-term Area: Helix term improvements E-easy Call for participation: Experience needed to fix: Easy / not much labels Nov 11, 2021
@heliostatic
Copy link
Contributor

Could we use the infobox to display the tree? e.g. #980

It would require making the infobox interactable, however...

@sudormrfbin
Copy link
Member

It would be better to have a tree widget component which can properly handle the structure and associated keybinds, and plus it can be reused for a file tree (#200).

@archseer archseer removed the E-easy Call for participation: Experience needed to fix: Easy / not much label Nov 17, 2021
@NNBnh
Copy link
Contributor Author

NNBnh commented Nov 25, 2021

It would be better to have a tree widget component which can properly handle the structure and associated keybinds, and plus it can be reused for a file tree (#200).

Agree! i suggest we redesign the picker UI:

The current picker is pretty fancy, too fancy actually. Everything is contained inside a box in the center of the window which block the whole view of the buffer and also make the picker look clutter. We should expand the picker to the whole window:

from this:

Screenshot_2021-11-25_11-19-56

to this:

  ./           ┃ 1 ┃ print("Hello, World!")
  ├╴foo/       ┃ 2 ┃
> │ ├╴1.py     ┃ 3 ┃
  │ └╴2.py     ┃ 4 ┃
  ├╴bar/       ┃ 5 ┃
  └╴README.md  ┃ 6 ┃
               ┃ 7 ┃
               ┃ 8 ┃
░ NOR ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1:1 ░
file picker:▁                               [3/3]

by:

  1. Move the picker prompt to the bottom, reusing the original prompt and also display the picker name to the left.
  2. Also move the match counter to the right of the original prompt.
  3. Move the list to the left of the window (not buffer), took 1/3 or 1/4 space of the window.
  4. Move the whole preview to the current buffer.

Navigate the picker should be the same (using UP, DOWN and ENTER), if the pointer focus on a directory (e.g: dir/) user can press ENTER to expand/fold it back.

Bonus: The user could keep the picker on the screen all the time, this should close #200.

@NNBnh NNBnh changed the title Undo tree UI Picker UI redesign (and Undo tree UI) Nov 25, 2021
@archseer
Copy link
Member

I disagree with this / this should be split into two separate issues.

The current picker is pretty fancy, too fancy actually.

It's the most minimal UI we could implement without adding a full file explorer with lots of state (which is your proposal, essentially an embedded nnn -- we have to track multiple tree levels and there's different sets of behavior depending on if you're expanding a directory or opening a file).

I'd like to keep the default interface simple and clutter free and discourage using a file tree; helix is not vscode and it's best to pair it with a terminal file manager like nnn if a file tree hierarchy is desired.

I agree that we could visualize the undo tree though.

@NNBnh NNBnh changed the title Picker UI redesign (and Undo tree UI) and Undo tree UI Nov 25, 2021
@NNBnh NNBnh changed the title and Undo tree UI Undo tree UI Nov 25, 2021
@pickfire pickfire added the A-plugin Area: Plugin system label Dec 5, 2021
@matu3ba
Copy link

matu3ba commented Dec 18, 2021

Just adding my thoughts on undo files tree:
Unfortunately undo files dont track changes between files, ie if one function or code part is refactored to another file.

Do you believe this is feasible, ideally on treesitter-based level?
The configuration logic would look like this

  • if project not tracked by git break
  • get paths to not track from trackingignorefile (git syntax)
  • if needed, ajust filepath->increasing index as u32 table stored in file (index created by ascending newly created filepaths depending on git history)
  • load filepath->index into memory

Functionality could work like this

  • every change is annotated as something along u32:change or for movements of content between files u32->u32:change and stuff in buffer gets prefixed by path, line and column and a prefix indicating that we track this, ie ($T!)src/main.rs:20:20:fn void
  • pasting from buffer looks up 1. buffer content, 2.registers for identical content to adjust the undo history if we have a move or copy of content

From briefly thinking this through, this has no fundamental limitation that does not occur with the usual approach besides added complexity for copy-paste besides restricting content to occur exactly in one register or adding complexity to resolve what content moved into which register (think of inserting and copying into temporary buffers etc).
Unclear to me would be, how efficient and accurate tracking of changes from external refactoring tools could work.
Ideally, those tools can split their changes into diff files.

Do you happen to know, if pijul allows tracking changes at statement level or if anyone wrote a formalization on how this could work?
Ideally there would be tooling to encode commits per statement and group them, so the users dont have commit bloat.

Conflating and removing redundant editings to retrieve the relevant semantic changes can then be done in a separate pass.

@heliostatic
Copy link
Contributor

Could this use the tree work in #2377 ?

@matu3ba
Copy link

matu3ba commented Aug 14, 2022

The handmande networks wishlist has code-aware CVS HandmadeNetwork/wishlist#5, which is essentially structured editing (version control system), which is essentially a language-tailored form of ropes + tracking+resolving their changes.

See "Typed Image-based Programming with Structure Editing" by Edwards and Petricek linked on https://alarmingdevelopment.org/?p=1570 and the video presentation + this nice explanation what ropes are https://blog.jetbrains.com/fleet/2022/02/fleet-below-deck-part-ii-breaking-down-the-editor/ to connect the dots.

It would be obviously nice, if projects like https://www.shadaj.me/writing/introducing-rust-sitter/ come up with better performance of the parser, rather poorly scaling treesitter query system (qeries are rather dumb and dont utilize caching/previous qeries etc) and an API to combine semantic information.

@muja
Copy link

muja commented Jun 26, 2023

Until this is implemented for those that need very granular overview over their edit tree, could we add an option that undo's are memorized in the history so when making an edit after a few undos (creating a new branch), undoing will revert the edit and then the undos. I think here it's explained clearly: https://github.com/zaboople/klonk/blob/master/TheGURQ.md

Somebody also built a crate for that: https://docs.rs/undo_2

The option could be called something like recycleable_undos or whatever. The history "tree-editor" could be implemented independently of course and would be separate from this.

@hbuxiaofei
Copy link

hbuxiaofei commented Apr 28, 2024

I implemented tree-view with two solutions.

@Rossnkama
Copy link

Is this still a priority?

https://github.com/mbbill/undotree

I find this super useful, would be great to have a similar UI here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-helix-term Area: Helix term improvements A-plugin Area: Plugin system C-enhancement Category: Improvements
Projects
None yet
Development

No branches or pull requests

10 participants