This is a mega-commit - because most of it had to be done in one go
otherwise some commits would fail to compile - that attempts to fix a
few problems with Geany's includes as well as various other related
cleanups. After this change it's easier to use includes and there's
little worry about which order things are included in or who includes
what.
Overview of changes:
* Include config.h at the start of each source file if HAVE_CONFIG_H
is defined (and never in headers).
* Go through each source file and make the includes section generally
like this:
- Always config.h first as above
- Then if the file has a header with the same name, include that
- Then include in alphabetical order each other internal/geany header.
- Then include standard headers
- Then include non-standard system headers
- Then include GLib/GTK+ related stuff
* Doing as above makes it easier to find implicit header include
dependencies and it exposed quite a few weird problems with includes
or forward declarations, fix those.
* Make geany.h contain not much besides some defines.
- Add a little header file "app.h" for GeanyApp and move it there
- Move "app" global to new "app.h" file
- Move "ignore_callback" global to "callbacks.h"
- Move "geany_object" global to "geanyobject.h"
* Add an include in "geany.h" for "app.h" since GeanyApp used to be
defined there and some plugins included this header to access
GeanyApp.
* Include "gtkcompat.h" everywhere instead of gtk/gtk.h so that
everywhere sees the same definitions (not a problem in practice AFAIK
so this could be changed back if better that way.
* Remove forward declarations from previous commits as some people
apparently consider this bad style, despite that it reduces inter-
header dependencies.
TODO:
* As always, to test on win32
* As always, to test with not Autotools
* Test plugins better, both builtin and geany-plugins, likely API/ABI bump
* Test with various defines/flags that may change what is included
* win32.[ch] not really touched since I couldn't test
When quitting, we still have to destroy the Scintilla widget to avoid
any possibility for us to receive signals from it after we destroyed
the associated editor and/or document (used in signal handlers).
I myself don't suffer from the issue, but it is theoretically possible
for Scintilla to emit signals anytime before it is destroyed, so it is
safer like this anyway. And an user on IRC suffered from crashes on
quit because of this issue, so it seems to actually happen in some
situations.
C-style multiline comments, used among others in C, C++ and Java, are
often continued on next lines with an additional space followed by an
asterisk:
1. /* first comment line
2. * continuation line (asterisk is aligned with previous line)
3. * last line */
This fools the indentation with detection because lines 2 and 3 from
the above example have an extra space in what is considered being the
line indentation. In this example, the algorithm would detect an
indentation width of 5 rather than 4, because here most lines have an
indent of 5 -- although they actually have an indent of 4 plus a space
for alignment. This is not a problem in most situations because there
generally are fewer comment continuation lines than actual code lines
which have a indent multiple of the actual indent width, but with some
code with a lot of comments (e.g. short functions with verbose
documentation comments) this might start to fool the algorithm and
give wrong, annoying, results.
So, try to detect these continuation lines and avoid taking them into
account.
Remove most obvious calls to our very own deprecated Scintilla wrapper
functions sci_get_text(), sci_get_text_range() and
sci_get_selected_text().
Some calls are still left, but they either really benefit from these
functions or the fix would be more complex.
"regex_match_text" and "regex_matches" being globals, performing
several searches and then the replacements separately lead to them
having unexpected values, resulting in incorrect behavior and crash.
Fix this by removing the globals and instead make the search functions
return match details. Not only this fixes the issue, but also make the
code a lot more maintainable by not having globals introducing side
effects (proof of them being an issue is that c83a93e inadvertently
broke things bad).
The code used a Scintilla-specific regex escape (\<) which doesn't work
anymore since the time we switched to full PCRE (which uses \b). So,
update the regular expression to PCRE.
Also, properly escape the name to search in the unlikely case it has
regular expression escapes in it; and properly check for word
boundaries even when not searching with an extension.
This allows for users to change the colors if needed (may be useful
with some themes or color blind persons).
On the sidebar, only the color is applied for now. This is because
it is not possible to style cell renderers through RC files, all having
to be done in the code; so currently only the color is applied.
This copies the current document text and properties into a new
document, similar to the old Save As 'Open file in a new tab'
option, but easier to understand and decoupled from saving.
One notable difference is that the new document does not copy the
filename - the old behaviour was confusing and error-prone for the
user (e.g. editing two documents with the same filename).
This reverts commit 7cc443e1420b77d041815a464fe5b20bc62412f4.
Showing the truncation message only when the file exists doesn't work
when writing to a network file and the connection drops out (thanks to
Lex).
When switching between MRU documents, Geany pops up a dialog about
document change even for the intermediate non-final documents.
This leads to both reload dialog and document switch dialog displayed
at the same time and termination of document switching because the
newly displayed dialog takes focus.
This patch disables reload checks for the intermediate documents and
forces reload check for the final document.
Most noteworthy change is that all build commands IDs and groups are
now unsigned everywhere negative values aren't explicitly handled with
a special meaning. This should not change anything in behavior, only
makes clear the index won't underflow.
This adds a new commandline option --read-only (or -r). It's implemented
according to the behavior agreed on on the mailing list:
--read-only applies to all files on the command line
irrespective of positioning and has no effect on any other files
opened by session or menu (...)
Current behaviour on attempting to re-open a file with different
read-only status is that nothing happens, the already open
file is raised but not changed. (...)
* Add new function: document_update_tags().
* Refactor the various tag update functions into document_update_tags().
* Remove extra call to update the tags in document_new_file().
This prevents GTK of trying to fetch the necessary information like
MIME-type itself, which leads to a significant speedup (> 30%), as
well as using the real MIME-type we use rather than the GIO-guessed
one.