I would normally whinge about screwing with peoples muscle memory if changing default keybindings, but the only two apps I have found that still use `<ctrl><shift>equals` (aka `<ctrl>plus`) are Geany and Eclipse, so those are the ones screwing the muscle memory.

Also personally I don't use zoom so I don't care either way.

No because <Primary>-<Equal> would be very uncomfortable on my German keyboard layout!

Seriously, I understand the point and that the equal sign is easier to type than the plus on a US keyboard layout. Interestingly, on a German layout it's vice versa.

Regardless, what I'm wondering about and what I don't understand is that the Gnome HIGs suggest <Primary>-<Plus> (https://developer.gnome.org/hig/reference/keyboard.html?highlight=zoom#view-...). And I guess this is also where the current default value in Geany has its source.

Until this PR I wasn't aware of <Primary>-<Equal> for zoom in. But just noticed Firefox (at least in my configuration) accepts <Primary>-<Equal> *and* <Primary>-<Plus> for zoom in.

That is what I was thinking about, to have both shortcuts by default and (probably) only one can be edited.

I guess this is not possible right now but a second hard-coded keybinding can be added easily probably. The more relevant question is - do we want this or is switching to `<Primary>-<Equal>` just the way to go?

I guess nobody else (chrome, firefox etc) read the Gnome HIG.

Probably best not to add a hard coded action for any keybinding, some user is guaranteed to have a problem with it on an Elbonian keyboard [Dilbert reference].

Instead add a second keybinding action defaulting to `<ctrl>equals` so that it can be unset, modified etc if some user has a problem with it. I think it just needs duplicating [this](https://github.com/geany/geany/blob/04566236d3f9811d55d6c7bcc492b3a60369fd20...) (plus the manual explaining why there are two zooms) :smile:

@xiota pushed 2 commits.

718a867514ef9968b8d451a3eaf49724cbc3d39d Change default zoom-in keybinding to <Primary>equal 24c9852df0fe871e2ba7d51a66c2c4843e0789fd Add secondary actions for cut, copy, paste, zoom in/out

@xiota pushed 1 commit.

0198ae0669ac8303c20d657c42bd01688ed5a059 Fix parameters to add_kb

Why cut copy paste? All discussion has been about zoom.

So I can assign both ctrl+c/v and ctrl+shift+c/v to copy/paste.

@xiota pushed 1 commit.

8177bb7278e8d3f54d4e8a92353eb0f0d3be2899 remove secondary cut/copy/paste actions

Keybindings are a linear search through the list, whilst adding each additional one is immaterial, if each one isn't actively challenged then they keep adding until keyboard operation becomes slow.

Since nobody has complained about zoom out lets leave it out for now.

because nano...

Geany isn't Nano, if a nanoist wants to change their keybinding thats fine, but its not up to Geany to provide equivalences for every editor out there, thats plugin territory, [see](https://plugins.geany.org/vimode.html)

@xiota pushed 1 commit.

497b171a7a6c063128cad2f5374dba4b49d8a0bb remove second zoom out action

every key goes through the search

So each key pressed to type a sentence in the editor has to go through the keybinding search?

Unicode code points

Keyboards don't create unicode code points. That's what the IME is for. Only keycodes that can actually be generated need to be checked. Most keyboards have fewer than 128 keys. The modifier keys could be checked separately. So you'd have have a jump plus a few comparisons to find the right response.

Keyboards don't create unicode code points.

You are right, keyval is not always a code point, although often coincidentally the value happens to be the same :smile:. But keyval does use at least 25 bits (see cyrillic or armenian in `gdkkeysyms.h`) so its worse than I thought. Also on some keyboards with "dead" keys GDK maps a multiple key sequences into one key event without IME. And IME still generates a keyevent IIUC with Unicode keyvals.

Most keyboards have fewer than 128 keys.

Not true, some non-asian keyboards have up to 4 values per keycap, see [French](https://en.wikipedia.org/wiki/File:Azerty_NFZ71-300.png) or probably @eht16's German keyboard. And also _which_ values? As you can see in `gdkkeysyms.h` keyval can cover a wide range of values. A simple table of all possible keyvalues from keyval to function address is far too big even if state is handled separately.

Thats why I suggest a hash table (or binary tree), key is combined `keyval` and `state` from the event and value is the function to call, the number of entries is related to the number of active keybindings, not the number of possible key values and the performance is constant for hash and O(ln(entries)) for tree (say 7 compares of a 64 bit value if 128 keybindings are set). Because keyvals from any one keyboard are likely to be close to sequential the combination and hash of `keyval` and `state` needs to ensure that performance does not approach linear worst case if hash is used, probably tree is safer because it doesn't have the bad worst case performance. Don't know which is easier to use/maintain.

Keyboards are a real pain, see also #1368 for another saga.

@xiota pushed 1 commit.

fb454d0ebd4da06351274332d6273dd4e1a5e4f1 update doxygen comment

@xiota pushed 1 commit.

28605870c6f2649291be7af92e5551b833fa7abe Update doxygen comment

Force push because confused branches/changes.