RE: [cdt-dev] Red Hat's Text Hover work.

[Thomas Fletcher <ThomasF@xxxxxxx>]

> -----Original Message-----
> From: Chris Moller [mailto:cmoller@xxxxxxxxxx]
> Sent: January 8, 2004 2:52 PM
> To: cdt-dev@xxxxxxxxxxx; John Healy
> Subject: [cdt-dev] Red Hat's Text Hover work.

Thanks for the information Chris, comments below:

[Inner workings of RH Hover help snipped]

> This HoverHelp capability was developed to be invoked in
> DefaultCEditorTextHover.getHoverInfo().  This, however, appears to 
> present a problem as, historically, getHoverInfo() appears to 
> have been used to provide text completion instead of, or in addition 
> to, hover text.  This ambiguity will require resolution.

[More usefull stuff snipped]

Historically is the reason =;-)

When the original code completion was implemented, it was based on two
"databases".  The first database was the index generated by the ctags
utility and the second database was an extension point which allowed
us (QNX) to plug in code which provided completion on our documented API.
This was for functions only, which is why the whole hover documentation
is so C centric (and doesn't cover structures, defines etc).

The documention of course had other handy information in it such as
which includes are required, which libraries are needed, function 
synopsis and description.  It made sense (since the database was 
being generated from the documentation) to extract that information
as well and then offer it to the user as "hover help" and it was 
anticipated that eventually we would also do live "hover help" based
on the actual JavaDoc in a projects headers.

Personally, while a little rough around the edges, it seems to work
quite well.  I think that for 2.0 we are certainly going to want to
be able to have:
- Hover help which doesn't provide IFunction* information, but
  documents other potentially "non-completable" events.  This 
  would represent a change to the extension point/API likely.
- Tunable hover help (as Dave Inglis mentioned) which the user
  can decide to activate with different key modifiers, and/or
  a project preference to decide which hover help they want to
  include (for example a QNX project and Linux project in the
  same workspace should use different hover help).
- Of course we all want to see the JavaDoc/Doxygen "live" 
  documentation support too =;-)

I'm hoping to get some cycles to contribute a bit more on this (some
of the _easy_ stuff like selection of which hovers to enable for
example) in the next few months.

Thanks,
  Thomas