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

Matthew Brush mbrush at xxxxx
Sat Aug 27 05:00:13 UTC 2016


On 2016-08-26 09:17 PM, Lex Trotman wrote:
> [...]
>> 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.
>
> I was thinking of the design discussion (see below) but I guess you
> could make another issue for that if you want #1195 to just be a
> management issue.
>

Yeah, I propose the meta issue be used for tracking the overall progress 
and such, leaving hammering out design discussions to the ML and 
specific code discussions to their relevant PRs.

>>
>>> 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.
>
> Yeah, but the mailers that thread on subject use the whole subject
> line, not just a tag, so the whole subject needs to be maintained.
>

Yeah, I assumed that is the default for non-broken mail clients.

>>
>>> 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
>>>
> [...]
>> 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.
>
> Well, like I said, that assumes the commenter has the time and
> knowledge to do so, banning comments on the basis that the commenter
> hasn't provided an alternative doesn't sound like a good idea.
>

My proposition is that people without time or knowledge not contribute 
to the development of this enhancement. Of course everyone would be able 
to comment on stuff as it is merged back into master, but only those 
willing to actively develop the solutions have any kind of strong voice 
during the actual development.

>>
>> 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).
>
> Not this formal, see below.
>

OK, so more like a wiki page describing the plan.

>>
>>> 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.
>
> Thats what I mean, the sort of thing as discussed in IRC is a start,
> then API examples and examples of how the plugins would look in
> different languages (again as discussed on IRC).  If you want to keep
> #1195 pristine, maybe you should copy the design stuff to another
> issue then.
>

Probably opening specific Issues and linking back to #1195 would suffice.

>>
>>>> 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.
>
> "Willing" and "able" are two different things.
>

Yes, but I propose only those willing (interested in the improvement) 
and able (able to read and write C code and make patches/PRs against 
various forks/branches) should be included in at least the earlier 
stages. Of course it doesn't have to be hard and fast, and it's always 
useful to have a sharp eye pointing out fundamental issues, but it's 
counter-productive to debate which colour the bike shed should be while 
the structure is being built.

> Sure but many comments will be minor, and I don't think its a good use
> of either the commenter or the PR owners effort when you compare:
>
> 1) the time and effort required to make a comment "typo" and the OP
> making the change as they do other stuff vs
>
> 2) the commenter making another PR and the OP having to then combine those.
>

That's an example of the kind of comments I was hoping to avoid. Either 
the person can wait until the changes are committed and then add a 
commit that fixes such trivial errors, send a general cleanup patch to 
pull requester, or they can wait until the changes are being merged into 
the master branch to raise such minor issues (eg. during some kind of 
code review). The goal is that if someone makes some large and/or 
complicated improvement towards the end goal on a non-master branch, not 
to bog them down with silly stuff anyone can fix or mention later when 
it actually matters.

To give an example, it's not uncommon for Columban to do a review and 
then provide a link to his working branch implementing the changes 
mentioned, the way he thinks are best. This is a goal, IMO.

>
>>
> [...]
>> You can submit PRs to people's PRs, it's easy.
>
> I didn't know you could do that, how?
>
> [...]
>>> 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.
>
> Yes, don't know which is better.
>
>>
>>>> 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.
>
> Possibly, so long as its flexible enough to be able to support the
> particular language symbol and scope structures, then allowing
> existing code to keep accessing the symbols in the same manner has
> advantages.  But, ATM it doesn't support lexical scope IIUC, the TM
> experts should comment.
>
> One very important use-case for this is in type inferred languages
> which are becoming more common (Julia, rust, go, ocaml, haskell, even
> C++ auto), no ctags parser is going to get types for declarations in
> those (and may not even recognise `a=b` as a declaration of a) so some
> external method is gonna be needed.
>

I also have doubts whether TagManager/CTags is up to the task, but I'd 
like to be proven wrong (would save a lot of work/breakage).

>>
> [...]
>>
>> 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.
>
> Yeah, just so long as it doesn't assume C name rules :)
>
> [...]
>> 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.
>
> Yes, thats the idea.
>
>>
>>> 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.
>
> Yes, and might be even simpler if it can take advantage of any of the
> new plugin capabilities.  IIRC filetypes are never unloaded after
> loading, so the plugins would have to be the same.  Possibly they
> shouldn't even show in the PM, or show as not user removable.
>

Probably, yeah.

Cheers,
Matthew Brush



More information about the Devel mailing list