At the moment undo of line end type change only undos the changes made
in the document but the different line ending settings remains active.
This patch fixes the issue by combining the line end scintilla undo action
with a new UNDO_EOL action responsible for updating the line ending
settings.
Fixes#409
geanyobject can be used by plugins to connect to plugin signals directly
(required for GI-based plugins). Access through GeanyData::object. The related
doxygen comments are @gironly for now, since plugin_signal_connect() is still
preferred.
Finally, the useless function pointer prototypes are removed from the
GeanyObjectClass structure as they became useless (they have been unused and
generally wrong since ever).
Since the original include list is already reordered by the hash table,
it makes no sense to reverse the resulting list as it's in a different
order anyway.
Even when we know when should be searching for definition (or declaration),
we can keep searching for the opposite type too when we didn't find
anything with the "correct" def/decl type. So at least we find "something"
of that name.
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.
