To move up/down line within a multi-line item. To move to previous/next item, once youāre at the first/last line of an item.
This behavior is respected by WorkFlowy on both web and desktop.
Actual result
Moving up/down a line within an item works, but once youāre at the edge of an item youāre stuck, and donāt move to previous/next item.
Environment
Mac, both desktop and web.
Additional comments
Thank you for not overwriting any of the ctrl bindings (at least from what Iāve seen)! Not being to move up/down freely is a deal breaker for me though.
Itās probably safe to map ctrl-p and ctrl-n to whatever up arrow and down arrow are doing.
How long is it going to take to fix something like this?
We have decided not to adopt Dynalist as a standard document tool in our company if this problem is not fixed.
Iām not being helpful with this comment I just want to say I am genuinely perplexed that multiple people out there prefer pressing control+P rather than .
4 hearts too, and one finds it a dealbreaker for a whole company.
I am suspecting there is something I am not aware of, like japanese keyboards donāt have a key, or itās a VIM thing, or something. I am curious. control+P seems awfully hard to press, they couldnāt be further apart. And is control+N? Why isnāt it something below P like ; or L? What about when you use a Windows computer, do you accidentally send the document to the printer when you mean to move the cursor up?
Oh wow thereās F and B tooā¦such random spots on the keyboard
I wonder when apple added these bindings. Didnāt the Apple I and Apple II have arrows? Arrows were like the first keys added to early computers after the letters and numbers. So I wonder what provoked Apple to add alternate combosā¦
Itās not a matter of personal preference.
This is the standard keybinding that macOS has been using since OS X, and other applications have been using it to increase efficiency.
But, for example, Microsoft Office stubbornly ignores its key bindings, so the more efficient you are at your job, the more frustrating it is.
Note that the assignment of cursor movements such as n, b, p, and f, which seem unrelated to the direction of movement, is based on the key bindings of the engineerās favorite editor GNU Emacs (born in 1970).
When an engineer wants fast editing, they canāt waste their time reaching for the cursor key.
Thatās not the case with Windows, so even a Dynalist in a Windows environment would be wrong to adopt this key binding.
The issue raised by this bug report is this:
Please donāt kill standard measures that can increase efficiency for those who can work by the lack of understanding of those who cannot do fast key typing.
Iām not interested in which one I like. Both Vim and Emacs are great editors, and I use both.
I simply want Dynalist on macOS to adopt macOS standard key bindings.
And the current Dynalist is not like that, so it is useless. Thatās all.