Re: IDE

[Eric Ludlam <eric@siege-engine.com>]

On 10/10/2015 07:20 PM, John Wiegley wrote:
>>>>>> Eric Ludlam <eric@siege-engine.com> writes:
>
>> In CEDET, the function / command `semantic-analyze-current-context' provides
>> an output that has lots of details about the buffer near point. Not just
>> what the cursor is on, but if it is a chain of symbols such as dereferencing
>> struct pointers, and in many cases, it figures out the data type of the
>> symbol the cursor is on. It also handles in-buffer caching, etc and plenty
>> of performance tweaking is available.
>
> My preference is for each core feature to have an extremely simple and light
> interface (taking indentation as an ideal), so that it can also be used for
> non-IDE tasks we haven't imagined yet. From what I know about CEDET to date,
> it is much more complex than this objective.

That is because the task is complex.

> When I squint, I see ctags, imenu, pcomplete, helm, company, hippie-expand,
> flycheck, and more, all starting to look somewhat alike: They each act upon
> information relevant to the buffer in some way. Where they differ is in how
> they derive this information, and how the user interacts with it. Can we
> provide a common, low-level interface for this style of functionality? A
> common API against which we can implement both data-gathering backends, and
> display front-ends? And with an emphasis on efficiency and low-latency!

The primary difference between your list and CEDET is that those other 
tools focus on picking up a current symbol, or perhaps a substring, and 
it is up to the next layer to figure out more about it.  I agree that 
that could be simplified across the variosu tools, but AFAIK the 
'thing-at-pt' stuff is that common interface.  IDEs know more about the 
buffer than just some symbol and the major-mode of the current buffer.

Things like dabbrev work pretty well finding similar strings that often 
have the feel of being 'smart', but that only works if you've typed it 
in before.

If you want a stronger set of smart behaviours at point, you will need 
to raise your standard to include more derived data.

> We need to harness the power of multiplication, so that every new backend
> makes every frontend automatically more powerful, and vice versa. This will
> also help us better leverage our existing base of contributors.

This I agree with.

Eric