33dafac8f0713de79f04e2ebce2399fb914d6792 restored the pre-Scintilla
3.10 default on non-Windows, but also changed the Windows one. Fix
this so the modifier keeps its historical value on Windows as well.
Fix document_account_for_unsaved() so it does not alter the `changed`
flag on documents, in order for plugins to have a reliable value there
at all times.
Patch by @chrontec with small additional tidying up.
Closes#1857.
- Notably the utils_strv_{find_common_prefix,find_lcs,shorten_file_list}
now take -1 for num to mean to compute the array length.
- utils_strv_find_common_prefix implementation simplified.
- if num == 0 is passed to the above functions the passed strv is not
dereferenced (so could be NULL).
- Fix lots of compiler warnings
- Fix a bug where a long base name would prevent ellipsizing the longest
common substring
- rewrite utils_strv_shorten_file_list to be more clear (hopefully)
- use g_strlcpy
- optimize case where the longest common substring need not be searched for
The array annotation has many possible parameters, this avoids having a Doxygen
command for each one.
Luckily you can define Doxygen commands multiple times with different a number
of parameters each.
Since I based the algorithm of the above function on code in one of my python
plugins, I would like to remove the implementation in my plugin and call
Geany's function.
From #1069:
> At the moment if symbols of the same name are defined in identically named
> files, it's hard to distinguish which file is which because there's no path
> in the popup.
> The popup should show part of the path until a directory where the paths
> differ so it's possible to distinguish the different files. At the same time
> there should probably be some top limit for the length of the paths as they
> can make the popup too wide.
This addresses the above by showing more of the file's paths but still try
to make it as short as possible. The file list is processed by the new
utils_strv_shorten_file_list(), as a result the popup will list files with
the common prefix stripped and the longest common sub-path ellipsized.
As a result, the file list shows enough of the path to make them unique but
still is still very short and doesn't make the dialog too wide.
Fixes#1069.
1) utils_strv_find_common_prefix
Locates the common prefix.
2) utils_strv_find_lcs
Finds the longest common substring.
3) utils_strv_shorten_file_list
Transforms the file list by removing the common prefix and ellipsizing
the longest common substring. This is intended to be used for fixing #1069.
Although only 3 will be used immediately, I separated the functionality, so
that the other two function can be used on their own.
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.
Since 320e4b9d762e0bd7d550c62be614873db5a04ac4 the "smart line
indentation" explicitly doesn't restore cursor position, and doesn't
make use of the position parameter, which no caller really use anyway.
Remove it altogether to avoid confusion.
Add a defensive check to make sure to catch the unlikely but maybe
theoretically possible case where the document last document is closed
while the Save As dialog is running.
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.
Make the brief text be distinct between msgwin_*_add and msgwin_*_add_string().
Also add @see directives where appropriate. Lastly, add @since to
msgwin_status_add() for completeness.
The variadic variants cannot be gobject-introspected, i.e. are not available
in Peasy.
In fact, msgwin_compiler_add_string() and msgwin_msg_add_string() already
existed and have just been exported. msgwin_status_add_string() is new but
msgwin_status_add() becaume a wrapper around it in the same fashion as the
other two pairs.
This prevents loading a spurious tag for the format specifier line, as
well as fixing loading of CTags format with a format specifier line.
Before this change, the file pointer was rewound after reading a format
specifier line; but this had various unwanted side effects depending on
the recognized format:
* For TagManager and Pipe formats, it led to loading a tag named after
the format specifier (e.g. a literal "# format=tagmanager"). This
was fairly harmless and only introduced a spurious tag seldom even
used because "#" isn't usually considered for looking up completions.
* For CTags format, having an explicit specifier led to failure to load
the file in most cases because the specifier line would be parsed but
doesn't usually follow the format's requirements, leading to early
abortion loading that file. On some very specific specifier lines
actually following CTags format, it could have led to loading a
spurious tag instead.
Fixes#1814 and closes#1816.
