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

Improve cursor location when manually deleting a node #5

Closed
taramk opened this issue Feb 13, 2023 · 4 comments
Closed

Improve cursor location when manually deleting a node #5

taramk opened this issue Feb 13, 2023 · 4 comments

Comments

@taramk
Copy link
Contributor

taramk commented Feb 13, 2023

If I backspace through a node to delete it, put the cursor at the end of the node above. Right now, it seems to put it at the beginning of the previous node.

To reproduce:

Find a node somewhere in the middle of your doc, and backspace through the entire thing to delete it
Note where the cursor is

https://recordit.co/cKUpFtIyMQ

@progrium
Copy link
Contributor

also fixed by #6 commit

@taramk
Copy link
Contributor Author

taramk commented Feb 14, 2023

doesn't seem to be quite right. it should put the cursor at the end of the node that's immediately above it.

putting the cursor below in a new empty node:
https://recordit.co/FXoAZqFBaT

putting the cursor at the end of the previous top level node:
https://recordit.co/feQu3tf3Zb

@progrium
Copy link
Contributor

in the first case it's because we decided to make backspace un-indent. this is a case for why we probably shouldn't do that because in pretty much all cases i think you'd expect it to go to the end of the immediately above node. let me know if you think we can remove that or if you have an alternative scheme in mind. shift-tab to unindent isn't "natural" compared to outlines in word processors, but they are full of all kinds of weird contextual behaviors that imo are hard to reason about (i blame microsoft for years of layering stuff into microsoft word and everybody copying them)

the second case is because it's not considering expanded previous nodes, so i'll need to determine the immediately above node by traversing the tree given its current expanded state.

@progrium progrium reopened this Feb 15, 2023
@taramk
Copy link
Contributor Author

taramk commented Feb 15, 2023

we decided that deleting will not outdent because it creates weird scenarios like my first gif above. it'll just delete the node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants