[Geany-Devel] [FT-plugins] Proposed "Features"

[Matthew Brush]

On 2016-08-31 11:42 PM, Thomas Martitz wrote:
> Am 01.09.2016 um 07:17 schrieb Matthew Brush:
>> On 2016-08-31 09:57 PM, Thomas Martitz wrote:
>>> Am 01.09.2016 um 02:50 schrieb Matthew Brush:
>>>>
>>>> I don't think they'll usually require a "build system" per se, but
>>>> they definitively need to be told how to compile the code where
>>>> applicable.
>>>>
>>>> For libpython, I don't think it needs any flags. For libvala IIRC and
>>>> libclang (if not using compile_commands.json) they require the `argv`
>>>> you'd pass to the compiler itself. It may very well be possible for
>>>> ft-plugins using libraries with the `argv` approach to just grab the
>>>> compile command from Geany's build commands and convert it back into
>>>> an `argv` array or something.
>>>
>>> Not sure how you use Geany, but I never set the cc command line for
>>> individual files. I never type CFLAGS or CXXFLAGS into Geany's build
>>> settings.
>>>
>>
>> Yeah, that's why the absolute base functionality provided must always
>> exist. I'd probably be more willing to do a little setup for actual
>> projects if there was a benefit though.
>>
>>> Actually most of the time I don't set up the build system at all and
>>> alt-tab to a terminal where I use my employers crazy build system which
>>> uses make under the hood but can't be used from within Geany properly.
>>>
>>
>> This use-case should continue to be the default supported one.
>
> But this can't be supported by a libclang ft-plugin, can it? Are you
> suggesting the default use-case bypasses the ft-plugin? That seems weird
> to begin with.
>

It could fall-back to the default functionality if no ft-plugin performs 
a given feature.

>>
>>> Then, some other time (e.g. for compiling Geany) I sometimes use the
>>> make command. But obviously Geany only knows that running "make" builds
>>> something. It doesn't have enough information to construct a compiler
>>> command line.
>>>
>>
>> Indeed. To provide "real IDE" features and project requires more than
>> what Geany provides out of the box. I haven't really proposed a design
>> for this, so as it stands ft-plugins would have to provide some means
>> (ex. advanced project support, compile_commands.json, custom GUI, etc)
>> to get this info from the user.
>
> A solution for this should be part of the discussion, otherwise we're
> going end up with a dozen completely ways and UIs configure ft-plugins.
> Which is going to be a PITA for users if the ft-plugins have to be
> regularly reconfigured on a per-project basis.
>

It's going to be plugin/language specific anyways. I agree it should be 
considered eventually, but it's not required to provide basic hooks for 
ft-plugins to start providing some features.

>>
>>> Some other time again I'm working on cross compiled projects. Here I
>>> again don't usually use Geany's build system support, but if I would it
>>> would run (e.g.) avr-gcc, with avr-gcc specific compiler flags, not
>>> known to clang (is there even a clang port for avr? I don't think so).
>>>
>>
>> For an example libclang plugin, clang would have to be able to parse
>> the source. It would require valid C/C++/Obj-C code for sure (though
>> IIRC some of the helper functions for IDEs/tools handle partial source
>> files or simple lexing to handle on-the-fly IDE highlighting and such).
>>
>>> So a ft-plugin that only works if a file can be compiled is likely to be
>>> unworkable for me. It needs to deal with when it can't build the source
>>> files (either because of lacking *FLAGS or because the target isn't
>>> supported by the compiler). Likewise, if a ft-plugin only supports x86
>>> (i.e. is arch dependent) it's not interesting to me.
>>>

If your code can't be (cross) compiled, I'm afraid you're screwed anyway :)

For some stuff, like partial code (ex. you're still typing it) or 
guarded out by platform macros, I'd expect some some reduced 
functionality, or different behaviour, at least.

To test it out, just try a competent full-fledge IDE such as QtCreator, 
Visual Studio, XCode, or Eclipse (among many others) and see what it does.

>>
>> For actual projects you would work on for a while, it would be worth
>> setting up some meta-stuff.
>
> I'm afraid I won't be able. The CFLAGS depend on the source file I edit.
> There are multiple projects involved (e.g. Linux kernel and user space),
> there is not just the One Project.
>

If you can't describe your build, yeah it's not so useful.

> The more I'm thinking about it...if key functionality depends on being
> able to compile the file, I won't be able to use a libclang based
> ft-plugin.
>

In order to provide "smart" features requires to understand the code. If 
you can't describe your build and make a regular c/c++/obj-c (cross) 
compiler able to handle your code, I'm afraid at least my CDK/libclang 
ft-plugin indeed wouldn't be of use to you. Doesn't mean others used to 
normal IDEs with describable builds won't benefit though.

> Really, this is one reason why I use Geany in the first place. Other
> IDEs such as eclipse require extensive, per-project build setup, to give
> even basic symbol parsing support. Such IDEs are generally limited to
> select work flows, such as Makefile-based, which are often incompatible
> with mine e.g. the work flow at my workplace. I hugely appreciate that
> Geany gives actually (IMO) decent auto-completion and calltips out of
> the box (and can be improved with just setting a few file patterns with
> ProjectOrganizer), for any file I throw at it.
>

There is no desire to remove this base functionality, only to enhance it 
for people who want more than you from Geany without bloating the core.

> I do see that this is valuable for other people and languages so I'm not
> fundamentally opposed to do actual compiling (if done right). But there
> needs to be a decent fallback when this is not possible, even if it just
> means to fallback to Geany's builtin support (so I'd likely always fall
> back).
>

That would be ideal.

Cheers,
Matthew Brush