Consider to add a plugin to support Asciidoctor

[manueljordan]

I installed Geany on Linux Peppermint OS based on 32 bits for a very old notebook, it works fine, really huge thanks for this editor.

About the plugins, at the https://plugins.geany.org page does not appear nothing about https://asciidoctor.org. I did realize exists a plugin for Markdown to support its syntax and with the respective preview tab.

Pls, could you consider in add a plugin for Asciidoctor?

Thanks for your understanding.

[elextr]

Geany has some support for asciidoc built in.

If "somebody" was willing to contribute a plugin for Geany to provide a preview it would probably be accepted.

Note that the plugin for Vscode is provided by asciidoctor.org so maybe you could ask there.

[manueljordan]

Thanks for the reply. I will try with them too. Thank You.

[xiota]

I have a plugin that shows a preview of several lightweight markup types... It needs refactoring... but works well enough.

[manueljordan]

Sounds great and thanks for your efforts. I am not sure what is the procedure of the official project about this specific situation

[elextr]

As @xiota says, the plugin is still a work in progress, but I'm sure they would be happy to have someone testing it.

When it is complete they may wish to add it to the plugins collection, in which case they need to raise a PR to add it, like #1331 or #1337, or they may decide to keep it separate and arrange for distro packaging and updating themselves.

[xiota]

@manueljordan The procedure would be... to build and install it yourself. It uses webkit2gtk-4.0 or webkit2gtk-4.1. If you use 4.1, it will conflict with some other plugins: webhelper, markdown, updatechecker, geniuspaste. They are being updated, but I wouldn't expect rebuilds on most distros until the next release.

Looks like Peppermint is based on Debian Bookworm, so I'd expect the build instructions to work with minimal changes. If not, feel free to open a new issue on the project page.

In terms of features, it's basically complete. I don't intend to turn it into a general web browser. The problem is the code isn't very maintainable.

[xiota]

Submitting a plugin to the geany-plugins collection would require freezing the code, even for bug fixes. I'm not willing to do that for a plugin I actively use, so never submitted it.

Consider this bug #936 for the markdown plugin from 2019. I submitted a fix #1128 in 2021. Closed it in 2022 because took too long to be reviewed and merged. Opened a new request #1232 in 2023 because open bugs bug me. Merged recently in 2024. So about five years before the bug could be fixed.

[elextr]

Geany plugins doesn't "freeze" changes, but yes it does slow them down with reviews etc.

The benefit though is that it gets access to the Geany packagers to put it in distros if its part of the plugins collection.

The real problem is plugins where there is no maintainer for the plugin to create or review the bugfixes, other people who are not really invested in the plugin may eventually make or review minimal fixes to keep it alive, but grudgingly and slowly. That is the case with the markdown plugin.

Only the collection infrastructure is meant to be supported by the Geany-plugins devs, the plugins are the work of individuals or small groups so if they disappear everything grinds to a halt for that plugin.

[xiota]

The "freeze" isn't by explicit policy, but is what has effectively happened to plugins that aren't of primary interest to developers with commit privileges. If it helps facilitate bug fixes and minor improvements, I'm willing to be (interim) maintainer for the Markdown and GeanyLua plugins. I don't actively use them, but am interested in keeping them functional.

In terms of collection infrastructure, autotools is very slow. I noticed that geany supports building with meson. Has similar work been done for geany plugins?

[elextr]

@xiota it would be great if you are willing to be maintainer for those plugins, in that case simply make a PR changing the MAINTAINERS file with your details for them. Geanylua is orphaned so thats no problem, and codebrainz has not contributed to Geany or Geany-plugins for many years so @frlan the plugins collection maintainer will probably let you take over (putting words in his mouth :-).

As for Geany-plugins autotools build, yeah the infrastructure is "complex" and only a few people are good at it. I am not aware of any attempts to make a meson build for plugins, the guy who made it for Geany (and insists its "experimental" despite several distros and msys using it ;-) has stated that he will not be doing it for plugins. The Geany meson build is sort of a translation of the autotools build and still uses a few autotools, so trying to do that for plugins would be likely to be a horror. And again the problem is who changes the builds for plugins that have no maintainers.

[xiota]

I'm new to meson, but switched my preview plugin over to it. One way it could be done...

• Each plugin would have its own meson.build and meson.options that can be built independently.
  • The files should require minimal changes between plugins.
  • Building and testing individual plugins would become easier.
• Each plugin folder would be symlinked or moved to a subprojects folder. This is a meson specified folder that cannot be renamed.
• The main plugins folder would have a meson.build that imports subprojects based on whether the feature is enabled.
• For convenience and compatibility, meson can be wrapped with makefiles.

If there's interest, I can set up a trial with a few plugins.

[elextr]

Lets move the build tool discussion elsewhere rather than polluting this FR which has pointed to your plugin, but users have to compile it themselves.