ransome1
Better input sanification
Bug Report
Today, using sleek, I had the nasty surprise that it was misbehaving in weird ways. Operating on some entries was just fine, but for others. Marking the entry as completed, caused the entry not to disappear from the pending lists, rather being duplicated.
Thanks to the fact that the todo files are text, I looked into my todo, with emacs and discovered that one of the entries had a control char in it (^P). Removed it, and apparently sleek is doing its job properly again.
My question is how the ^P managed entering the file in first place. I only use sleek to edit my todos. Maybe I pressed something on the keyboard during the input. Stil I wonder if some better input sanification could help.
App Version:
2.0.19
Platform: Windows / macOS / Linux
Linux (manjaro)
Installation Method: App Store / Direct Download / Other
Appimage
Expected Behavior:
Sleek avoids letting the user enter in the todos special chars or constructs that may then confuse it.
Actual Behavior:
Sleek permitted a control char (^P) to enter the todos and then started misbehaving.
Steps to Reproduce:
How the issue was triggered is unknown
@sergiocallegari Hi there. Is it possible for you to share an example file, that contains this character and that does provoke this behavior on your side?
I found how to reproduce it:
- Disable setting "Multi-line text creates separate todos"
- Create a multi-line todo
- Enable the setting again
- Mark todo as completed
The result is this:
Similar thing happens when editing a multiline todo after the setting was enabled.
This happens because Sleek uses ^P (char code 16, "Data Link Escape") for encoding newlines into the todo.txt. When writing to the file, we don't actually know if a todo is new or a modified existing one.
Here in Write.ts every ^P gets replaced with a "real" \n again, resulting in two separate todos. To fix it, we should probably handle the bulk creation feature in a higher level before writing to the file.
https://github.com/ransome1/sleek/blob/8ca4b3ead8d0144a883804525cf6c2cf4224facd/src/main/File/Write.ts#L33-L37
@sergiocallegari Could you please confirm if this matches your observations?
