This function finally allows plugins to register themselves as a proxy
for one or more file extensions.
Lots of documentation is added to doc/plugins.dox, please refer to that for more
details.
Since geany_load_module() is called for non-enabled plugins you may not
use the plugin API here yet. The only exceptions to this rule are API functions
required for plugin registration.
This rule is hard to enforce (would need to g_return_if_val(PLUGIN_LOADED_OK(p))
for all API functions (well, those taking a plugin pointer anyway), so this
rule is only documented for now.
It was found that because geany_plugin_set_data() could be used by both
plugin's init() and geany_load_module(), that it introduced some uncertainty
as to when to call the free_func. init() callers might expect the call
around the same time as cleanup() is called, while geany_load_module()
callers expected the call at module unload time.
It was indeed called at module unload time. But that means that init() callers
cannot call it again reliably after in a init()->cleanup()->init() flow (when
toggling the plugin) without fully unloading the plugin (which is what we do
currently but that's we would want to change).
With the separation we can actually destroy the data depending on where
it was set and do everything unambigiously.
The documentation provides a quite detailed description of the new loader
In addition it adds a "how to transition" that briefly describes the old
loader (for curious newcomers) and lots of hints for porting legacy
plugins to the new loader.
We want it disabled by default in 1.25 for everyone, but want to be
able to get it back on by default later on when the UI is more
polished.
So we will need to have a way to tell whether the configuration comes
from 1.25 and should be upgraded or was willfully disabled by the user
in a later version. So, use a temporary setting name that defaults to
disabled for 1.25
See #553.
While the feature is nice, it might be unexpected and lacks user
feedback. This might lead to user thinking they lost their work
because they don't know they can undo the reload operation.
So, disable the feature by default until we introduce appropriate user
feedback allowing the user to learn about the feature and new behavior.
See http://lists.geany.org/pipermail/devel/2015-June/thread.html#9537
Add rest of headers needed for declarations of all public API
functions. Add HAVE_PLUGINS define to geanyplugins.h since some headers
need this and it should always be valid for this header.
geanyfunctions.h left for source-level backwards compatibility for
plugins which might `#include` this header directly. I don't know why
they do it, but some Geany-Plugins do this.
Under some conditions, geany_run_script.sh is not deleted and we
have no means to detect this in Geany (e.g. when the terminal emulator
is started correctly but it fails to execute the script for some reason).
In this case it is better to keep the garbage in /tmp than the working
directory. Apart from that, it eliminates potential transfer of the run script
over a NFS and eliminates the visibility of the script in working directory
on Windows.
Apart from that this patch fixes some locale/utf8 conversion problems
and other subtle problems with the previous implementation.
As discussed in SF bug #125, it might be dangerous to store backup
copies in a publicly accessable directory like /tmp with default
permissions, especially on multi-user systems.
So set the file permissions on non-Windows systems to 0600 by default.
Also improve the documentation of the save Actions plugin to reflect this
change.
This feature looks like a poorly implemented subset of "Complete word",
but lacks some important features like prefix filtering. It is also
misnamed as it shows not only macros, but also variables and enums.
It also only shows `editor_prefs.autocompletion_max_entries`, but does
so from *each* file, not as a whole.
So drop it altogether, as this feature doesn't really look useful and
the current implementation seem to suffer of too many shortcomings for
it to realistically be actually used.
In addition, rename all functions, parameters, comments etc. mentioning
work_object and remove unnecessary parameters of various functions.
Delete dead code paths.
Also move common functions like tm_get_real_path() from tm_work_object to
tm_source_file.
Only manually uninstall the files we manually installed, as
uninstall-local might be run in parallel to Automake's own uninstall
targets.
We don't uninstall the directories as some docs seems to suggest
`rmdir` isn't really portable. Anyway, Automake don't uninstall
directories either so it's not a real problem.
An alternative solution would be to keep the recursive removal of
`$(DOCDIR)` but move it to `uninstall-hook`, which is guaranteed to be
run after other uninstall rules. However, recursive deletion is not
always sensible as it might remove files we didn't install, e.g. if the
user added them manually.
Clean the HTML manual upon 'maintainer-clean' rather than 'clean' in
case it was not built by Make but rather part of the distribution.
This is fine even then, as configure will properly require what is
needed to build it again if it is missing.
Don't set clean-local and all-local dependencies all together at the
end and rather let each section add the appropriate dependencies.
This makes each conditional more self-contained, and is safe as Make
allows adding extra dependencies to existing targets.
As it is generated by the build system it doesn't have to be checked
in, and having it in became a whole lot more annoying since it started
being generated automatically on `make all` instead of specific (and
weird) `make doc`, as it means whenever the documentation changes the
HTML is re-generated on any make run. This is particularly problematic
if using a different Docutils version than the one used to generate the
checked-in version as it would create local noise that should not be
committed, yet keep being annoying.
This situation probably leads to most people disabling (or at least,
not enabling) the documentation generation on normal builds, itself
leading to more hassle updating of the documentation.
