Setting home to Ctrl-Home might stop working after some shortcuts get pressed

Question

Setting home to Ctrl-Home might stop working after some shortcuts get pressed

Closed this issue 9 months ago · 9 comments

After adding an emoji (Ctrl-S) or opening the contact list search (Ctrl-N), my Ctrl-Home (home=\33\133\61\73\65\110) bind to home (beginning of history) stops working, and it doesn't work anymore until I quit nchat and open it again. The character that appears when I hit Ctrl-Home (after the issue starts) is: 􏌓

The same applies to end (end of history) associated to Ctrl-End (end=\33\133\61\73\65\106), and the character that appears instead is: 􏌒

It applies to both Telegram and WhatsApp contacts.

No other shortcut has this issue.

Answer 1 · 2024-03-06T13:48:15.000Z

Hi @fulalas - thanks for reporting. Could you please share a copy of your ~/.nchat/key.conf? Either copy and paste the content in a comment here, or attach it as-is (might require making a copy of the file with a .txt suffix for Github to accept it).

Answer 2 · 2024-03-06T13:53:56.000Z

Sure!

key.conf.txt

Answer 3 · 2024-03-22T14:10:42.000Z

Thanks @fulalas - I can reproduce the bug here too. I'm preparing a fix, hope to get it tested and push it this weekend.

Answer 4 · 2024-03-24T07:38:25.000Z

Hi @fulalas - the above commit should fix the reported issue. Please let me know if you still encounter problems.

Answer 5 · 2024-03-24T22:44:30.000Z

Yes, it works. Thanks a lot!

I have 2 questions though:

is there a way to make -DCMAKE_INSTALL_LIBDIR=lib64 work? On some distros we don't want 64-bit libs to go into /usr/lib, but /usr/lib64 instead. I tried to use it on your project, but it seems it doesn't have any effect.
the nchat version I was using before was built on Arch, and magically libwmchat.so didn't depend on libgo, but now that I'm building on PorteuX (Slackware current based), it's depending on libgo, which is a big showstopper for me. Do you know how to workaround that?

Answer 6 · 2024-03-25T10:50:59.000Z

OK, for the question 2 I found the answer: we need to compile using golang instead of gcc-go.

Answer 7 · 2024-03-29T07:47:00.000Z

Hi @fulalas - for question 1 - I will look into preparing a fix for this, I can see that it's currently hardcoded to lib.

Answer 8 · 2024-03-30T13:25:55.000Z

Hi again - in 59afacd support for custom CMAKE_INSTALL_LIBDIR has been added. Please try it out and let me know if you encounter any issues (ideally by reporting a new bug). Thanks!

Answer 9 · 2024-03-30T19:53:12.000Z

It's working perfectly! Thanks a lot!