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

[Matthew Brush]

On 2016-09-01 01:55 AM, Thomas Martitz wrote:
> Am 01.09.2016 um 07:47 schrieb Matthew Brush:
>> On 2016-08-31 10:08 PM, Thomas Martitz wrote:
>>> Am 31.08.2016 um 17:26 schrieb Lex Trotman:
>>>>> I think we all agree that help of language-specific plugins is
>>>>> desired/required. No need to restate "we need language specific
>>>>> support" all
>>>>> the time.
>>>>>
>>>>> We just disagree on how the language-specific knowledge is
>>>>> transported to
>>>>> Geany, other plugins and the user.
>>>>>
>>>> Well, I read your previous comments such as "But *just* the data,
>>>> don't offload very specific use cases onto them" (and to some extent
>>>> this one too) as saying that all the plugin has to do is return some
>>>> data (tags) and Geany will take it from there and all I was doing was
>>>> making sure it was clear that its unlikely that Geany will be able to
>>>> "take it from there" in any meaningful way, based purely on data,
>>>> without filetype specific knowledge inside Geany.
>>>
>>> Here we disagree. I think it is possible to extent TM/Geany sufficiently
>>> to encode this information in generic ways. As an example, template
>>> instantiation yields different types. TM could tread them as different
>>> types. Any variable will be of one of the types, so calltips would just
>>> work.
>>>
>>
>> Let's use the simplest C example:
>>
>>     gint x = g_...
>>
>> Please describe the algorithm (just in prose) that would give only the
>> valid completions (ie. would compile in a C compiler) for `g_...`
>> without providing any impossible completions, and without knowing
>> anything about C/C++/Obj-C.
>
> Do you suggest the completion list would only contain function that
> return gint?
>

Could be that, or it could be as simple as not listing things which 
aren't in scope or visible (say an #include is missing). What I was 
getting at is that unless you describe Geany's current algorithm, you'll 
almost surely start describing C/C++/Obj-specific semantics encoded 
inside Geany.

> [...]
>
> So, as for the algorithm, I'd really stick to prefix matching, as done
> currently. Everything else assumes that I coded everything correctly
> which is not always the case. I don't want to be auto completion to be
> too smart and hide wanted functions.
>

Ok, I see where the problem is. You seem to only want the current 
functionality while I want to enhance it to be more in-line with the 
type of smarts you get in real IDEs that have deep knowledge of your 
code and programming language. So if this is the case you're 
fundamentally not going to like any features ft-plugins provide, and I 
suggest that you just not use them. The point of adding all this in 
plugins is specifically so you don't have to :)

Cheers,
Matthew Brush