No worries, we shouldāve updated here, somehow missed it. It was a real bug before, itās just that we patched it very recently. We should feel sorry.
Let us know if thereās still something wrong! If you find other bugs, feel free to start a new post about it.
The use-case so far, works like a charm now. Thank you!
But itās not over yet.
It works perfectly if the displayed second line is actually a ārealā second line by having a newline character before it.
But if the displayed second line is a soft wrap of a long first line, this bug is still there. Curiously: depending on the windows width, this bug occurs now on more than the first cursor position:
In this example, I narrowed the window just enough that the word ājumpsā was barely soft-wrapped into the second line.
I think itās actually arguable whether a soft wrap up arrow is a bug. But comparing behavior to TextMate, a long wrapped line there does respond to up arrow, so I guess so (FWIW, Workflowy also correctly handles wrapped lines and up arrow key). It seems like a different issue though.
Well, it feels and looks exactly like the bug we were discussing here; though it very well might have a different cause. Personally, I do have a lot of soft-wrapped lines.
If the cursor jumped from the whole soft-wrapped first line to the heading node, it would be still annoying but at least consistent; but it is not. In the gif above, the first newline character is just behind "<newline>".
Iām interested what @Erica has to say about this.
If this is a feature, someone has to explain to me how I can use this productively.
I got a fix for this, will deploy this soon. I actually fixed a different bug thatās very similar to this! That one is already out, but I will be fixing this soon!
The navigation within a note seems to work now. At least for the web version using Chrome and Firefox. I expect my standalone Dynalist app will update itself soon enough; although Iām using the web version more often.
