It seems to cause some compatibility issues with some current compilers
and we don't use it nor need it for extended regex support, so stay on
the safe side at least for the moment.
To detect the change of typename list since the last time the colourisation
happened, we could store the complete typename string used during the
last colourization and compare it with the current string. For lots of
typenames this might be quite a huge string stored for every opened tab
(well, it's also stored in Scintilla already for every document but better
not to have it twice). Instead, we can store an uint hash of the string.
We could also use a better hash function with longer hash value but
uint size should be enough for this case (and in the case of a collision
nothing terrible happens).
Properly handle discarding the dialog asking whether to override a
keybinding as canceling it rather than as allowing multiple identical
keybindings.
In the way, simplify and fix dialogs_show_prompt() not to perform odd
and useless response mapping that effectively go round back, and that
don't handle what the comment above it suggests. Simply document it
can return GTK_RESPONSE_DELETE_EVENT and handle it in the caller side,
as it's a possibly valuable information. Only one current caller is
affected, and it doesn't change anything as it doesn't change behavior
but only documents it.
Closes#714.
The idle callback removal clause in the ScintillaGTK destructor got
broken in the last Scintilla update [1], leading to the callback not
being removed thus possibly running after the instance destruction.
Indeed, gdk_threads_add_idle() wraps g_idle_add() with a custom user
data, thus making the g_source_remove_by_user_data() call in the
destructor incorrect, as we give it our own user data, not GDK's
wrapper one.
Fix the callback removal not to use user data matching to avoid this.
Closes#1033.
[1] 4e5c321dda/
X-Scintilla-Bug-URL: https://sourceforge.net/p/scintilla/bugs/1827/
X-Scintilla-Commit-ID: d889200cd9de032e278745f48b9c3108ccfa5984
If we were strict, we should check every single fprintf() int write_tag()
but it's highly improbable that some of the middle fprintf()s fail and
the last one doesn't so the current implementation of write_tag() is
probably sufficient.
* Use a streamlined name for each map, `map_LANGUAGE`, where `LANGUAGE`
is the CTags parser name from tm_parser.h. This allows some further
automation.
* Make sure the maps are referenced at the correct index in
`parser_map`, even if they were not in the same order as in the
`TMParserType` enumeration by using explicit sub-object initializers.
* As explicit sub-object initialization might lead to a missing
initializer for a non-last index going unnoticed, add a check for
uninitialized entries to properly reject them even for regex parsers.
Haskell single line comments consist of at least two dashes "--",
not followed by special symbol.
So in practice everywhere in code you will see a space following "--".
Reference: Haskell 2010 Language Report -> Chapter 2 -> Lexical Structure
Make each convenience library depend on the ones it requires, which is
pretty straightforward for us as they each only depend on a single
other one, avoiding any worry about double linking of static objects.
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
