GTK 3.20 doesn't like getting a style property for a non-current state,
unless the call is wrapped in a save()/restore() pair.
So, fix the code to either use the current state or temporarily save
the context.
gb.c now uses different states, but it shouldn't really matter given
how they are used, and even gives a native behavior when the window
loses focus, as it now properly reacts to BACKDROP state.
GTK 3.20 doesn't seem to like it so much when looking up details of a
non-exact current style context state, so use the current one.
This is GTK being really picky as in this case we are just missing the
`DIR_LTR` flag, which we definitely don't care about, but let's make it
happy.
X-Scintilla-Bug-URL: https://sourceforge.net/p/scintilla/bugs/1825/
X-Scintilla-Commit-ID: 9fc624da4a3d935633c45fb56d0e9a77ef9b5af1
GTK 3.20's GtkScrolledWinodw doesn't like having a too small allocation
and spews scary assertion failures. Fix that by requesting the real
size we'd like instead of hard-coding 1 as small-enough value in our
overriding height requisition method.
The actual value doesn't really matter so long as it's small enough
anyway, as we resize the popup to fit later on.
Note: this moves the actual implementation of ListBoxX::GetRowHeight()
to the new convenience function treeViewGetRowHeight(), with no changes
in implementation.
X-Scintilla-Bug-URL: https://sourceforge.net/p/scintilla/bugs/1825/
X-Scintilla-Commit-ID: 5a0afdd87d56d837dd8068e234aed8e2b6bdbe93
GTK 3.20 introduced a sub-node named "border" to the frame, requiring
to lookup the border on that sub-node rather than on the frame itself.
Unfortunately supporting this requires to be built against GTK 3.20, as
it requires API this version introduced. This means that a build
against an older version won't be able to get the popup sizing right if
running on 3.20. To mitigate this, add reasonable fallback defaults
when running 3.20 but built on an earlier version, to try and avoid
X-Scintilla-Bug-URL: https://sourceforge.net/p/scintilla/bugs/1825/
X-Scintilla-Commit-ID: 83d56b1fc63a206e4c1b776f5991b3b17ccb3473
2px-scrolling on GTK 3.20's default theme.
It's not really of any use as we do know any size would do as wText is
ours anyway, but GTK 3.20 doesn't like allocating without querying the
preferred size beforehand, so do it.
As wText has a size_request() of 100x100, this might change how we
allocate in case we used to underallocate it, but AFAIK we don't, and
it is the real minimum size expected.
X-Scintilla-Bug-URL: https://sourceforge.net/p/scintilla/bugs/1825/
X-Scintilla-Commit-ID: d06e3db3e26842cd136328df17eb6f864b3adc02
Normally menu items are updated only when adding or removing
them on osx. They are however not redrawn when just changing
keybindings so the old keybinding is displayed after the change.
Force the menu update to show the updated keybindings.
At the moment tag types are changed in ctags to match the types Geany
uses internally. This introduces differences between the parsers used
in ctags and the ones used in Geany.
Instead, perform the "ctags tag type"->"geany tag type" mapping explicitly
in TM and leave the tag types in individual parsers identical to ctags.
For parsers which are present in ctags (and which don't seem to be
completely different from the parsers used in Geany) revert the tag type
change in the parsers so the parser tag definitions match universal-ctags.
This patch doesn't do anything with the tag types of parsers not present
in universal-ctags and leaves them as they are.
Parsers which previously had a mapping to an non-existent Geany type have
now the mapping explicitly set to tm_tag_undef_t. Since the mapping is now
made through the one-letter type, some of the parsers had to be adjusted
because they used single letter for multiple tag types (probably by
mistake).
Because the whole mapping process might be a bit fragile and error-prone
to changes in ctags parsers, the patch also performs some consistency
checks:
* whether the parser number in ctags/TM matches
* whether for the given language the tag type number is identical in TM
mapping and ctags definition
* whether all tag types defined in ctags parser are mapped in TM and in
reverse, whether all mapped tags in TM are defined in ctags parser
* whether there aren't duplicate tag types
Unfortunately the checks are possible only for parsers not using regex
because regex definitions are not exposed by ctags (TODO).
A bonus side effect of the changes is we can now use real tag types defined
for each languages in ctags when parsing ctags tag files instead of
using the hard-coded static values which mostly work just for C/C++.
This adapts the paths in the installer for the tags and filedefs files
as changed in #485.
Also simply include everything in share/ when including a GTK3
runtime environment instead of a fixed list of subdirectories,
share/glib-2.0 doesn't exist anymore when using MSYS2 packages.
At the same time ignore tags of the type tm_tag_undef_t when parsing -
we cannot query them anyway and this eliminates the need to call
tm_tags_extract(source_file->tags_array, tm_tag_max_t);
when creating tags file.
At the moment it is a bit hard to distinguish which of the functions
we are using belong to ctags. To make more explicit what we need
from ctags, wrap all ctags-related code and access ctags only using
this layer.
The interface from tm_ctags_wrappers.h can serve as a base for
proper ctags interface if ctags becomes a library.
This patch moves code related to reading/writing various tag file formats
into form TMTag and TMWorkspace to TMSourceFile. The benefits of this
change are:
* only tm_source_file.c interfaces with ctags after this change
* tagEntryInfo is removed from headers, no redefinitions needed any more
* source code is more evenly distributed among tm_source_file.c,
tm_tag.c and tm_workspace.c after the change (tm_tag.c got smaller)
* all tag reading/writing is at a single place
Despite its size, this patch mostly just moves code. Notable changes are:
* tm_tag_new() now creates just an empty tag. The tag is filled by various
init_* functions inside tm_source_file.c
* there are new functions tm_source_file_read_tags_file() and
tm_source_file_write_tags_file() - these hide tags file
reading/writing details from tm_workspace.c
* tm_source_file_write() debugging function got removed -
tm_source_file_write_tags_file() does a similar thing and there's no
need to keep around two functions doing the same.
The direct python parser -> tagmanager callback is rather hacky
and unnecessary as we can do the same in the normal ctags callback
upon receiving a tag.
The Doxygen comments were on the non-public global filetypes_array and
filetypes_by_title variables instead of the GeanyData members which are
exposed to the plugin API and reference manual.
The global was never accessible to plugins on Windows and hasn't been
accessible to plugins on Linux and others since the linkage-cleanup
changes.
Move documentation from the global variable to the GeanyData member
of the same name.
Closes#964
Closeuniversal-ctags/ctags#453.
(This is about a bug spotted in universal-ctags/ctags#453 by @mislav and
in universal-ctags/ctags#11 by @NewAlexandria.)
Kinds C and d are for Rspec.
Parts of code related to above kinds assume a ruby string
comes after Rspec keywords (describe or context).
This is a wrong assumption. A class name can be used there.
It is nice if ctags can handle these rspec code well, but we
don't have enough resource to make it now.
So in this commit I delete rspec related code temporary. I
just reserve a kind letter 'd' for rspec for the future. 'C'
is completely deleted because (1) describe and context have
the same meaning in rspec, and (2) we would like to assign
'C' for Ruby constant as ripper-tags does.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
