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

Notes get deleted by CTRL+Z #308

Closed
DriverXX opened this issue May 3, 2019 · 7 comments · Fixed by #825
Closed

Notes get deleted by CTRL+Z #308

DriverXX opened this issue May 3, 2019 · 7 comments · Fixed by #825
Labels
bug Something isn't working feature: EasyMDE Realted to the integrated EasyMDE editor
Milestone

Comments

@DriverXX
Copy link

DriverXX commented May 3, 2019

If I open an existing note with a text in it and I push CTRL+Z once it get immediately back to the "new" state. Of course I can undo this with a CTRL+Y, but I think it is better to avoid that the first CTRL+Z delete a note.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@korelstar
Copy link
Member

I was able to reproduce this, and I think that you're right!

If anybody knows how to fix this: a pull request is very welcome 😃

@stefan-niedermann
Copy link
Member

Well, we could listen to the keyevent and call preventDefault(), but the hard part is: when to prevent default...

@korelstar korelstar added bug Something isn't working feature: EasyMDE Realted to the integrated EasyMDE editor labels May 24, 2019
@korelstar korelstar added the help wanted Complex issue or we don't know how to fix it label Jun 15, 2019
@zeroepix
Copy link

A simple solution would be to have a flag that blocks ctrl-z until the file is edited. However, it then becomes a tricky problem of how to disable it again when the file is in the original condition. If it's possible to keep track of "edits" discretely, you could have a counter which increments for each edit event. When a ctrl-z happens, this counter is decremented until it hits 0 again, and ctrl-z is again disabled. I don't know how feasible this is, but it does look like the browser has some sort of timer to know how far to undo, rather than actual characters.

If you can figure out that part, disabling ctrl-z could be done like this:

// editCounter is defined and updated elsewhere

var ctrlDown = false;
var zKey = 90;

// track ctrl being pressed
$('body').keydown(function(e) {
  if (e.keyCode == 17 || e.keyCode == 91) {
    ctrlDown = true;
  }
}).keyup(function(e) {
  if (e.keyCode == 17 || e.keyCode == 91) {
    ctrlDown = false;
  }
});

// then block when the counter is 0
$("body").keydown(function(e) {
  if ((ctrlDown && e.keyCode == zKey) && (editCounter <= 0)) {
    e.preventDefault();
    return false;
  }
});

@Boki4d
Copy link

Boki4d commented Mar 19, 2020

Had the same issue today and wanted to open an issue here, but then I found this issue.
"Funny" thing is, that I worked on an older and rather big note and made some changes within the text. While I was trying to Change the headline I accidentally hit Ctrl-Z and the whole text was gone, not only the last part I changed. I immediately tried to get it back with *Ctrl-Y, but it was gone, no chance to restore it.
I get that it is hard to distinguish between an intentional Keyboard-Event and a unintentional one, but what about a version history for every note? 5 Version per note. I think that would be enough to retain this behaviour.

@korelstar
Copy link
Member

korelstar commented Mar 27, 2020

@Boki4d Nextcloud already saves a version history by default. You can restore old versions using the files app.

It looks that the Nextcloud Text app doesn't have this problem. So this issue will be fixed after implementing #331. But I appreciate any help on fixing this for the current app version.

@Boki4d
Copy link

Boki4d commented Mar 27, 2020

@korelstar
I guess you're right that the editor of the Text App might fix the issues in the future. But I still suggest to make the version history accessible from the Notes App without having to switch to the Files App.

@korelstar
Copy link
Member

I agree. We have already an issue for this: #144 ;-)
I hope, the implementation will be easier with #331, because the text app also shows the version history in it's sidebar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feature: EasyMDE Realted to the integrated EasyMDE editor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants