This uses a menu and is thus subject to the menu icons visibility
setting, but here it should reflect the view from the symbols list,
and thus show the icon in all cases.
Don't use the files inode as the hash. Although it looks like a good
idea for de-duplicating links as well, it has several issues, including
non-uniqueness of inodes across file systems.
The way it was done hashing the inode but comparing the file name
string pointers also made the hash mostly irrelevant, as it just stored
filenames sharing the same inode in the same hash bucket but without
actually doing any de-duplication, making the whole thing a convoluted
way of converting to a list.
Instead, hash and compare the filenames themselves, which, even though
it doesn't handle links de-duplication, is better than the
non-functional previous code.
Also, directly build the list and only use the hash table as a way for
checking for duplicates, which is both faster and gives a stable
output.
Now the keybinding can be overridden (e.g. using Tab for it as well as
normal behavior), beeping when there is no next cursor is more annoying
than useful.
Part of #1554.
The new styles are for "diff of a diff", e.g. lines starting with `++`,
`+-`, `-+` and `--`. Those are currently mapped conservatively keeping
the previous display behavior, until we have good style matches for
them.
Scintilla 3.7.6/4.0.0 deprecated `SCE_*STYLEBITS*` and moved it to
deprecated features that require a build-time flag to be available.
Thus, drop use of those (as they are now no-ops anyway) and bump the
ABI (so plugins depending on those don't build mistakenly load) and API
(so a developer can guard use of those if wanted) version accordingly.
Before, **boldface** or *italics* (also _italics_) would not generally show as that, definitely not with the default color scheme. After this change, they appear with the same color as normal text but with that typography, in all color schemes.
Our custom scroll handler for horizontal (Shift+Scroll) and page
(Alt+Scroll) scroll didn't properly check the scroll direction and
assume that if it's not down it's up. This was mostly not a problem
because the other types only were left and right scroll events, which
are a lot less common.
However, it became a lot more problematic with GTK 3.4 that introduced
"smooth scrolling", and thus a new scroll type that can happen for
events in any direction. We then would scroll up (as we assume "not
down" is up) regardless of the actual direction of the event.
It's still not clear why we'd get smooth scroll events on X11 as no
code I can find asks for it and we generally don't get those, but
sometimes a Scintilla widget starts receiving them, leading to the bug.
On Wayland on the other hand, Scintilla asks for smooth scroll events,
so we need to have a fix for it in any case.
