* Add `--enable-html-docs` and `--enable-pdf-docs` arguments
(off by default)
* Add `RST2HTML`, `RST2LATEX` and `PDFLATEX` to override path to these
tools.
* Add HTML and PDF doc status messages to configure summary
I went through each link from the API docs and everything seems fine
since the extra leading whitespaces were removed in commits
`edaa6f713f1b8e037a56652da15032aac56e2227` and
`67ae7707364ecc09da8675803b48575d61b82fcf`.
* Add `m4/geany-doxygen.m4` file
* Support `DOXYGEN` environment variable setting which Doxygen to use
* Support `--enable-api-docs` to activate building Doxygen docs
(off by default)
At least the "Plugin Writing Guidelines" and "Plugin HowTo" sections
are displaying undesirable side effects of Markdown support, so disable
it at least for now.
We don't actually detect from file extension only, and other references
of the feature always use "Detect from file", so use it also in the
open dialog.
The "View" button string is the same as the View menu one, but one is
an action (verb) and the other a noun, and as such might need to be
translated differently.
Display the filetypes in the Open dialog filetype combo box grouped,
as they are in the filetypes menu.
This makes it easier to select a filetype, because they are better
sorted and follows the filetypes menu layout.
Make all encoding combo box display a list with encodings grouped by
categories into sub-menus, making it easier to find the appropriate
encoding than in a big single-level list.
This is what was used in the Open dialog, but not in the Preferences
dialog or the Find in Files dialog. This also makes the encoding
combo boxes behave more like the encoding menus.
Don't use wildcards to select files to install, nor manually perform
the installation when Automake could do it for us.
Using wildcards makes it hard to know what will really be installed,
and may results in installing files not part of the distribution.
Watch the lifetime of objects referenced in plugin->signal_ids and
remove our references to them if they get destroyed. This avoids
possibly trying to disconnect signals on destroyed objects when the
plugin is unloaded.
Supporting this case is safer, and is useful for objects that may or
may not outlive the plugin (like ScintillaObjects), because in such
cases plugin_signal_connect() is handy to make sure the signals are
disconnected if the object is still alive, but used to crash if the
object was destroyed.
