Default Mac key bindings for ctrl-p/n not going up/down items

Steps to reproduce

Use ctrl-p and ctrl-n to move up and down a line respectively. These are default mac os x bindings. See

Expected result

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.


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 :arrow_up:.
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 :arrow_up: 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 :arrow_down: is control+N? Why isn’t it something below P like ; or L? :thinking: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…

Control-F: →
Control-B: ←
Control-P: ↑
Control-N: ↓

I think I finally found a clue :male_detective:‍♂ those letters come up on 60% keyboard forums

It seems there is a small subculture, using very custom mechanical keyboards with 40% of the keys missing, so they have to use very obscure combos

But it’s funny that the even smaller keyboards do have arrows

I am going down a web hole.

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.

Thank you.

oooh its an emacs vim thing

maybe you can code a chrome extension to add your features like this person

or learn vim and vote for this one

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.

Remap command N P to the arrow keys for with BetterTouchTool
Anything can be remapped

I know such a makeshift approach.
But there are problems with it, so I would like to encourage further fundamental improvements.