[vi-mode] mapping ctrl+{j,k} to next/previous is buggy in search mode

[laur89]

Clarification
The goal of using next & previous commands is to move the selection in clipboard elements in the same manner as arrow Down & Up are behaving by default.

Reproduction:

• Make sure vi mode is enabled (unsure if necessary)
• Map ctrl+{j,k} to next/previous, in parallel to default Up/Down arrow.
• toggle copyq
• verify new mapping works as expected (it does, ie exactly the same behaviour as using arrow up&down)
• enter search mode via / and filter your clipboard down to smaller number of elements
• try said mappings again

Expected result:
ctrl+{j,k} should behave the same as Up/Down arrow in this filtered search mode

Actual result:
Looks like ctrl+{j,k} are still working against the full list of elements, although filtered list of elements is shown.

copyq-commands.ini contents defining the mappings:

[Commands]
1\Command=copyq: next()
1\GlobalShortcut=ctrl+j
1\Icon=\xf063
1\IsGlobalShortcut=true
1\Name=Copy next item
2\Command=copyq: previous()
2\GlobalShortcut=ctrl+k
2\Icon=\xf062
2\IsGlobalShortcut=true
2\Name=Copy previous item

Version, OS and Environment

CopyQ Clipboard Manager v3.13.0
Qt: 5.14.2
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Debian GNU/Linux bullseye/sid

[hluk]

The "Copy next/previous item" predefined commands are used to copy the following item.

You probably want this command:

[Command]
Command="
    copyq:
    var shortcut = str(data(mimeShortcut))
    var row = selectedItems()[0]
    if (shortcut == 'ctrl+j')
        selectItems(row + 1)
    else
        selectItems(row - 1)"
Icon=\xf338
InMenu=true
Name=Up/Down
Shortcut=ctrl+j, ctrl+k

[laur89]

That's just amazing. Thanks!

[laur89]

Just noticed it's not quite same as moving by arrows.

A

1. toggle clipboard
2. filter items by searching for keyword
3. move by the ctrl + {j,k} keys as defined above
4. try to edit selected/highlighted item by F2 - note nothing happens

Now if user had used arrow keys in step 3., then F2 would open the editor as expected.

B
Additionally, we also break the cursor in this mode if we try to move up when first element is selected, or move down if last element is selected.

What's up with these cases?

Am on same copyq & qt ver as in the original post.

[hluk]

F2 shortcut works only if the item list has keyboard focus. When you search, it is the filter text box that is focused. You may need to override the shortcut so it works when filtering:

[Command]
Command="
    copyq:
    edit(currentItem())"
Icon=\xf044
InMenu=true
Name=Edit Current
Shortcut=f2

In the B case, using currentItem() would work a bit better - the current item is still deselected but is marked as current.

[Command]
Command="
    copyq:
    var shortcut = str(data(mimeShortcut))
    var row = currentItem()
    if (shortcut == 'ctrl+j')
        selectItems(row + 1)
    else
        selectItems(row - 1)"
Icon=\xf338
InMenu=true
Name=Up/Down
Shortcut=ctrl+j, ctrl+k

[laur89]

All valid solutions, awesome!
Only issue with A case is that F2 now causes error message to pop up:

CopyQ Error
Editor command: execvp: No such file or directory

Note functionally everything works, just the (think it's qt's?) error is shown.

Copyq commands.ini

[hluk]

My guess is that External editor command in configuration (History tab) is not configured correctly (the editor program is not found).

The edit() in the F2 command opens an external editor if configured, otherwise it opens the internal editor.