Emacs style not working

[elig0n]

Describe the bug
Emacs navigation style does not seem to work.
Ctrl+N opens a new item in the builtin editor.
Ctrl+P open preferences.
Neither n alone p alone works, they just get added to the search query string.
Vi mode does.

Expected behavior
Navigating the item list up & down same like VI mode with j and k.

Version, OS and Environment
CopyQ Clipboard Manager 10.0.0
Qt: 5.15.16
KNotifications: 5.116.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Manjaro Linux

[hluk]

@janmejay Can you help with this issue? I do not use the Emacs navigation in CopyQ.

[janmejay]

@elig0n can you please share config (copyq.conf) and a screenshot of the General tab in Preferences? I don't really have a hypothesis, I plan to use the config locally or diff it with my local config to spot differences.

If you'd like to do that, here is my config: https://github.com/janmejay/nixos.d/blob/master/dots/dot_config/copyq/copyq.conf

[hluk]

@janmejay It seems the problem is that the default shortcuts conflict with how the Emacs mode works. I think these shortcuts have priority before any custom keyPressEvent() code, and I don't see any code that would override the shortcuts when switching the navigation mode.

[janmejay]

@hluk but that should break it for me too right? It seems to work for me locally. Do I need to set some config that would engage the default-shortcuts to repro this?

[janmejay]

@hluk does the window-manager matter (I use i3 locally)? Also I'll try to pull the latest master to see if that gives me a repro. What I run locally is an old build (I think pulled shortly after PR merged).

[hluk]

To test this, you can start a new session:

copyq -s test --start-server

# configure Emacs navigation
copyq -s test config navigation_style 2

# show the main window and pass CTRL+N
copyq -s test 'show(); keys("CTRL+N")'

This causes the default shortcut to be invoked.

Not sure how to fix this. Vi mode also depends on the default shortcuts not to conflict (but it is not a problem there).

[hluk]

@janmejay I'm adding some tests in #3023 - but it includes a workaround (after the FIXME comment) that unsets the default conflicting shortcuts.

EDIT: I have problem running the tests in CI (thought they work for me locally) - it is mainly because there is no proper interface to change the shortcuts via scripting/CLI.

[hluk]

I'm fixing some key handling in #3023.

I think we can add a code into MainWindow::eventFilter and handle some QEvent::Shortcut and QEvent::ShortcutOverride events to fix this issue.

[janmejay]

test session does repro it, I figured out why it works for me. I had very old CopyQ config that had the conflicting shortcuts unbound.

@elig0n one way to work-around and use emacs-keybinding for now is to just unbind shortcut to preferences etc (similar to https://github.com/janmejay/nixos.d/blob/master/dots/dot_config/copyq/copyq.conf).