input.conf: navigate the playlist with n N p and P

[guidocella]

Because:

• No need to hold shift for a fundamental feature when intuitive keys are available
• Space is already easier to press than p to pause
• Consistent with VLC key bindings, which was the main reason for rebinding the wheel to change volume
• n and p can be bound with shift to navigate sub-playlists as a variation of the same feature
• o is already easier to press than shift+p to show the playback position, I didn't even remember this binding exists
• If we add key bindings optimized for images it is worth having these to navigate the playlist without shift regardless because you do it much more often, so if these also works for videos, that makes mpv easier to use

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[na-na-hi]

• No need to hold shift for a fundamental feature when intuitive keys are available

This is not a goal of mpv, and in fact it's discouraged in 496b132. It adds notes like the following to the documentation of several keybinds: The x key does the same as Z currently, but use is discouraged., so the encouraged way for increase/decrease values is to use a letter and shift-letter instead of using 2 different letter keys, at least for letter key bindings.

[guidocella]

What does that have to do with navigating the playlist? That clearly referred specifically to the paired add key bindings r t z x and w e where wm4 wanted to encourage using 1 key for each for unknown reasons. Also that discouraged note in the docs could just be removed, number key bindings work the same way and are arbitrarily not discouraged instead.

[llyyr]

the encouraged way for increase/decrease values is to use a letter and shift-letter

To preface, if we could start over with no disruption of existing workflows, I'd also support using 1 key for increase/decrease.

But we aren't going to go around changing all the default bindings are we? There are far more usage of separate keys for increase/decrease values than there is for using 1 key for both and we realistically are never changing them to be consistent one way or another, so with that in mind I believe new key bindings should use the layout that's the majority instead of adding to the problem and making keybindings needlessly hard for users to learn.

Also note that the linked issue doesn't mention anything about discouraging decrease/increase being on separate bindings, but both of us have more important things to do than guess what wm4's intention was with a random change 6 years ago.

[na-na-hi]

What does that have to do with navigating the playlist?

Semantically it does the same thing by adding/decreasing current item index.

wm4 wanted to encourage using 1 key for each for unknown reasons

The reason is that these keys can be apart from each on some keyboard layouts, so that w/e, z/x, r/t won't be adjacent to each other. This issue was repeatedly mentioned in #973. Quoting #973 (comment):

x/z make no sense on QWERTZ keyboards. The new bindings would make sense on all QWERT keyboads.

To make it worse the purposed n and p keybind aren't even adjacent to each other in the first place on English keyboards, which is the opposite to the existing convention of w/e, z/x, r/t, and number keybinds.

Using n and N for next/prev item on the other hand won't have keyboard layout problem. Using enter/alt+enter (purposed in #973 (comment)) also doesn't have this problem.

number key bindings work the same way and are arbitrarily not discouraged instead.

Number keys don't have the keyboard layout problem, and using shift is worse instead.

[na-na-hi]

To preface, if we could start over with no disruption of existing workflows, I'd also support using 1 key for increase/decrease.

n/N and enter/alt+enter I mentioned don't cause any disruption of existing workflows because they don't change existing key bindings, unlike this PR.

But we aren't going to go around changing all the default bindings are we?
so with that in mind I believe new key bindings should use the layout that's the majority instead of adding to the problem and making keybindings needlessly hard for users to learn.

Right. So this means new keybinds need to adhere to existing convention. n and p are anything but that.

but both of us have more important things to do than guess what wm4's intention was with a random change 6 years ago.

The intention was clearly stated in #973 (comment). No need to guess.

[llyyr]

Right. So this means new keybinds need to adhere to existing convention. n and p are anything but that.

I agree, existing convention is keys next to each other on the same row on a QWERTY layout functioning as decrease/increase. These bindings don't fit that, but this can be solved by suggesting to change them to different bindings that are next to each other rather than talking about how using two different keys is discouraged.

Even if every new binding from this point onwards adheres to n/N bindings, any user using a non-QWERTY layout is going to have to edit input.conf anyway to get keybindings that make any sense. Half-assedly preferring n/N just makes the bindings more confusing for QWERTY layout users, and doesn't solve any problems for non-QWERTY users. The worst of both worlds.

[guidocella]

Semantically it does the same thing by adding/decreasing current item index.

It is an implementation detail that it increases the current item index, from the user's point of view changing file is a completely different operation than incrementing the sub-delay or panscan. We even have different commands than add for it.

The reason is that these keys can be apart from each on some keyboard layouts, so that w/e, z/x, r/t won't be adjacent to each other. This issue was repeatedly mentioned in #973. Quoting #973 (comment):

Ok, but that's not a problem here since n and p and not adjacent.

To make it worse the purposed n and p keybind aren't even adjacent to each other in the first place on English keyboards, which is the opposite to the existing convention of w/e, z/x, r/t, and number keybinds.

Because they're chosen based on the initials of next and prev and have different functions than those key bindings. Changing file is not comparable to incrementing properties, they are different commands that do different things.

Using n and N for next/prev item on the other hand won't have keyboard layout problem. Using enter/alt+enter (purposed in #973 (comment)) also doesn't have this problem.

It is not optimal to use a modifier to go the next playlist entry when it is one of the most basic features.

[na-na-hi]

Even if every new binding from this point onwards adheres to n/N bindings, any user using a non-QWERTY layout is going to have to edit input.conf anyway to get keybindings that make any sense. Half-assedly preferring n/N just makes the bindings more confusing for QWERTY layout users, and doesn't solve any problems for non-QWERTY users. The worst of both worlds.

It's the current convention for letter keys (including j/J which don't use adjacent keys) so I don't think it's confusing or makes no sense.

from the user's point of view changing file is a completely different operation than incrementing the sub-delay or panscan
Changing file is not comparable to incrementing properties, they are different commands that do different things.

Changing to prev and to next item are definitely related operations, just like increase/decrease sub-delay or panscan.

Ok, but that's not a problem here since n and p and not adjacent.

What kind of circular reasoning is this? Non-adjacent keys are mentioned repeatedly as an issue in the issue I linked.

Because they're chosen based on the initials of next and prev

There is no such convention. Does "panscan" begin with w/e? Does "sub-delay" begin with z/x?

These bindings don't fit that, but this can be solved by suggesting to change them to different bindings that are next to each other rather than talking about how using two different keys is discouraged.
It is not optimal to use a modifier to go the next playlist entry when it is one of the most basic features.

There are no spaces for adjacent keys left right now. But if you don't mind changing g (only very recently added) I wouldn't mind using g/h, they are adjacent on most keyboard layouts.

[llyyr]

It's the current convention for letter keys (including j/J which don't use adjacent keys) so I don't think it's confusing or makes no sense.

I don't see why it matters if it's the convention for letter keys, most keyboard layouts shift the symbols on shift+numrow too. The convention is pointless if it makes no sense.

[na-na-hi]

I don't see why it matters if it's the convention for letter keys, most keyboard layouts shift the symbols on shift+numrow too. The convention is pointless if it makes no sense.

shift+j is always J no matter the keyboard layout. It's not comparable to shift+numbers, which aren't used for key bindings for the exact reason.

[llyyr]

Hi,

1. my original point was that we already use adjacent keys on the number row.

2. Your response was

It's the current convention for letter keys (including j/J which don't use adjacent keys) so I don't think it's confusing or makes no sense.

which I read to mean that it's only convention for letter keys to use n/N bindings.

3. My response was that the convention is pointless if the convention exists to not inconvenience non-QWERTY users but almost all layouts move where @ is for example anyway. I'd argue the convention is pointless because it's not solving the problem it was introduced to solve.

4. I don't see how your response sufficiently addresses anything I said.

[na-na-hi]

My response was that the convention is pointless if the convention exists to not inconvenience non-QWERTY users but almost all layouts move where @ is for example anyway. I'd argue the convention is pointless because it's not solving the problem it was introduced to solve.

This is a bad example, it's not a letter key and it's explicitly marked as "Legacy bindings (may or may not be removed in the future)" after discussion in #973. If any this only supports my point. The convention is for letter keys only, which solves the problem it intended to solve.

my original point was that we already use adjacent keys on the number row.

There is no such convention (using shift) for number keys in the first place especially after ! and @ were marked as legacy, so bringing up number keys in this discussion is pointless.

[llyyr]

The convention is for letter keys only, which solves the problem it intended to solve.

What problem is it solving?

[na-na-hi]

What problem is it solving?

The problem of two letter keys not being adjacent depending on keyboard layouts. By only using one key + shift the problem is avoided.

[llyyr]

The problem of two letter keys not being adjacent depending on keyboard layouts. By only using one key + shift the problem is avoided.

Why does the convention not include Shift+numrow keys then? They move around depending on the layout as well. Them being "marked" legacy is not an answer, are they realistically ever being changed or removed? The answer is no. All this convention achieves is use two different methods of laying out keybinds.

[na-na-hi]

Why does the convention not include Shift+numrow keys then?

You said it yourself:

most keyboard layouts shift the symbols on shift+numrow too.

Number keys and letter keys have different conventions, both due to the keyboard layout reason.

Them being "marked" legacy is not an answer, are they realistically ever being changed or removed?

It is an answer. It means new keybinds should not use them.

All this convention achieves is use two different methods of laying out keybinds.

And there is nothing wrong with that. The final goal is to avoid issues with keyboard layouts. Whatever means used to achieve that is less important. I have even purposed using g/h if you don't want to hold shift because they're stable across layouts.