[Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Matthew Brush]

On 2016-08-26 12:13 AM, Lex Trotman wrote:
> Not sure I agree that Github is bad for *development* discussions, for
> users, sure, the ML is likely to find the audience better, but most
> developers will also be githubians. Also github supports markup that
> mail doesn't.  But anyway lets try mailing it in for this issue, and
> see how it goes.
>

I just meant for that meta tracker issue. It gets too hard to keep track 
of what's going on when there's dozens and dozens of comments. I would 
expect code-related discussions to happen on the individual PRs or 
separate ML threads.

> But everybody, please DO NOT EDIT THE SUBJECT LINE IF ON THREAD some
> mail agents thread by subject, and DO NOT REPLY IF YOU WANT ANOTHER
> THREAD some mail agents thread by previous ID.  We should not dictate
> what sort of mail agent people must use to contribute, please respect
> individual or enforced choices and follow this procedure (codebrainz
> this should go on the issue guidelines).
>

That was the idea with the subject tag, in case there's multiple threads 
any mail client or ML archive can be searched by that, at least.

> I agree with the approach in general, but for some major items (about
> the process):
>
>> rather than endless discussions we let the code do a lot of the talking
>
> No, not yet, we need to agree what we are going to code.  This is a
> major change to Geany's design, and it should be designed, not just
> jump into coding it.  Geany suffers from too much "heres some code I
> made earlier".
>

I meant once we start implementing it, for the actual PRs. Like instead 
of saying "oh this is wrong" or "if you did it this way, ...", we could 
just provide a PR to fix it.

But just to clarify, when you say "design", can you elaborate concretely 
on what that means to you? What exact steps/process would consider that 
once complete would mean the design is done? This is a genuine question, 
since "design" is a wafty term that means different things concretely to 
different people (UML diagrams, flow charts, UI mockups, long design 
documents, a wiki page, etc).

> codebrainz, you clearly have some design in mind, please *describe*
> (not code) it to get the ball rolling.
>

I kind of did in the PR description, but will follow up with more 
specifics later.

>> Code reviews are always welcome but should be accompanied by the appropriate patches/PRs/commits
>
> Too draconian.  Just because someone has
> questions/doubts/misunderstandings about some proposed code or design
> doesn't mean they have the knowledge or time to immediately propose an
> alternative.  If comments that don't have corrections/alternatives
> proposed are ignored, nobody will review.
>

As above, I just want to avoid the PRs getting bogged down with all 
kinds of minor comments. It's a morale buster. I'm guilty of this on 
many occasions myself, which is why I put that. Mostly I just want to 
replace a comment like "you should do ..." with "if you do it like this 
patch ..." or "I've submitted a PR which does that better". Basically 
the idea I have is that anyone who is interested enough in contributing 
should be willing to contribute code/patches/examples/etc where 
appropriate rather than only ever putting comments in a text box on a 
webpage.

> Using a branch is good, but, as PRs cannot be layered on PRs, what
> process do you suggest for corrections to be proposed?  And how will
> alternatives be compared? More than one PR cannot be committed at the
> same time, and "first PR gets committed" is a bad recipe for new
> designs, the first is often the worst.  Having later PRs have to
> revert previous PRs just makes them more complex and harder to review
> so better proposals tend to be rejected.
>

You can submit PRs to people's PRs, it's easy. Alternatively, just 
providing a patch (gist, by email, or even inline in comments) would 
work too.

> On the requirements, not much to say, agree in principle.  Minor
> comments/suggestions:
>
>> Allow plugins to provide syntax highlight.
>
> Probably sufficient for Geany to support "container lexers" and
> flick-pass it to plugins.  But then the plugins probably have to have
> a way to define styles similar to how `highlightmappings.h` is used
> for included lexers.
>

It might be better to provide some kind of interface for this if we go 
the container lexer route to make it less crazy to implement. The 
dynamic lexer way is perhaps more work, but it's also more structured 
and one can use all of Scintilla's lexers as examples. Needs more research.

>> Allow plugins to provide the symbols for the tagbar tree...
>
> Do you mean the symbols pane? Or do you mean to inject symbols into
> tagmanager so all existing functionality also sees them?
>

I mean something more like where Geany tells the plugin it wants to 
update the symbol tree and so asks the plugins for the symbols to show. 
It's sounding (from Jiří and Thomas) that using TM as a conveyance 
mechanism for this may make some sense.

>> provide the auto-complete list, given the current location in the document and the part of the word already typed.
>
> Location in document is probably enough, the plugin probably has to
> check for preceeding context `aaa.bbb.ccc` anyway, so the partially
> typed name is no issue, and it can then be language specific, like
> lisp can include *s and -s and other things that C doesn't allow in
> names.
>

Small potatoes. If the partial word is not given, many plugins will have 
to get it each themselves. It's not a big deal to do but maybe at least 
a helper function or something would be useful to avoid redundant code.

>> plugins to hook into the build system runner
>
> Plugins can now get and set any build command, not sure what else is
> needed, except maybe a way of telling Geany to not save the plugin set
> values, since the plugin is handling them.
>

That's good then, I haven't looked at that API much yet.

>> plugins to provide diagnostics when build commands are run.
>
> Allowing the plugin to parse the command response *before* it goes in
> the message window would be good.
>

At least for the CDK (libclang) plugin I was working on, there's no 
requirement to actually run any external commands, you just call a 
libclang API function to re-compile and then use its API to extract 
diagnostics information programmatically. It would be a similar case for 
Python also. That being said, it's probably beneficial to still allow 
more generic compiler output parsing in case such nice support libraries 
are not available.

> General:
>
> I used to have a prototype of a change to load filetype specific
> plugins specified in the filetype file.  I can't find it now (backups,
> whats that?) but it actually was so simple that it doesn't matter.
>

I remember that. Most likely something along those lines will be a good 
way to load the plugins, though it might require to be a bit more 
advanced to deal with plugin lifetimes and other stuff.


Cheers,
Matthew Brush