- 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.
We can now use @array and @arraylen{param} annotations for arrays that
will make it to the generated gtkdoc header.
g-ir-scanner cannot properly parse 'gchar **' parameters without this.
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.
The previous code would skip parsing with sub-parsers so these would not
work. Running full createTagsWithFallback1() in this case would cause
two problems:
1. We would have to propagate the extra callback arguments to
runParserInNarrowedInputStream()
2. And the callbacks after each pass should not actually be called in this
case because the caller expects these are called for the master parser,
not the sub-parsers.
So instead just do simple parsing without re-tries which are used only in
the C and Fortran parsers which lack sub-parser capability anyway.