[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] [cdt-patch] TextHover patch - version 2 (fwd)
|
FYI,
for folks not following the cdt-patch list. Until we find a way
to absorb this in the main stream, Chris work is available here:
http://people.redhat.com/cmoller/TextHoverPatch/
in org.eclipse.cdt.ui.libhover-fragment.zip
Full message below.
Forwarded message:
> From cdt-patch-admin@xxxxxxxxxxx Fri Jul 23 13:06:11 2004
> From: Chris Moller <cmoller@xxxxxxxxxx>
> Date: Fri, 23 Jul 2004 12:58:36 -0400
>
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enig7352DD4097578904973B9C35
> Content-Type: multipart/alternative;
> boundary="------------030006090601030506070104"
>
> This is a multi-part message in MIME format.
> --------------030006090601030506070104
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
>
> A new verion of patch to provide TextHover capability to CDT is
> available at
>
> http://people.redhat.com/cmoller/TextHoverPatch/
>
> in org.eclipse.cdt.ui.libhover-fragment.zip
>
>
>
> What it Does:
>
> If a user leaves the pointer on a text string for a couple of seconds,
> TextHover tries to look up that string in a database of known C/C++
> library functions. If the string is found, information pertaining to
> that function is displayed in a popup until the pointer is moved. This
> initial release contains databases for the standard C library, glibc, as
> well as for the GTK+ libraries: GTK, GDK, and GDK-pixbuf; other
> databases can be easily added.
>
> [New version: the GTK+, et. al., libes aren't included right now.
> They'll be along as soon as I re-write the gtk-doc parser in Java.]
>
>
> How it Works:
>
> When the fragment is first invoked, one or more provided library
> description XML files is parsed and a search is made for the supplied
> target string. If the string is found, relevant data is retrived and
> formatted for display; the XML files can contain encoded
> representation of library API information such as function, struct,
> enum, typedef, etc., descriptions. The parsed versions of the XML files
> are retained, accelerating subsequent accesses of the fragment.
>
>
> Patch Details:
>
> The patch is a sef-contained fragment that resides in
> org.eclipse.cdt.ui.libhover and plugs into
> org.eclipse.cdt.ui.CCompletionContributor. It contains a file
> glibc.xml, by default in org.eclipse.cdt.ui.libhover/libhoverdocs but
> which can be located anywhere, even outside of the Eclipse structure,
> with no more than slight modifications to the project fragment.xml
> file. Future descriptor XML files can also be put in the same
> directory, or in other directories along a defined search path.
>
> TODOs:
>
> * Add the code to handle multiple descriptor XML files.
> * Add additional descriptor XML files.
> * Add a means of allowing the user to (re)define the default search
> path.
> * Add a means of allowing the user to select from the available
> descriptor files.
> * Add a means of allowing the user to access whatever documentation
> parsers are available. (The only parser available at the present
> is the one that abstracts Texinfo files into the appropriate XML
> structure. It's not included in this package (yet.))
>
> Known problems:
>
> * The first access of the extension is slow due to the time it takes
> to parse the XML file(s).
>
>
> Chris Moller
> Senior Hacker
> Red Hat, Inc.
>
> --------------030006090601030506070104
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> <title></title>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> <title></title>
> A new verion of patch to provide TextHover capability to CDT is
> available at<br>
> <br>
> <a href="http://people.redhat.com/cmoller/TextHoverPatch/";>http://people.redhat.com/cmoller/TextHoverPatch/</a><br>
> <br>
> in org.eclipse.cdt.ui.libhover-fragment.zip<br>
> <br>
> <br>
> <br>
> What it Does:<br>
> <br>
> If a user leaves the pointer on a text string for a couple of seconds,
> TextHover tries to look up that string in a database of known C/C++
> library functions. If the string is found, information pertaining to
> that function is displayed in a popup until the pointer is
> moved. This initial release contains databases for the standard C
> library, glibc, as well as for the GTK+ libraries: GTK, GDK, and
> GDK-pixbuf; other databases can be easily added.<br>
> <br>
> [New version: the GTK+, et. al., libes aren't included right now.
> They'll be along as soon as I re-write the gtk-doc parser in Java.]<br>
> <br>
> <br>
> How it Works:<br>
> <br>
> When the fragment is first invoked, one or more provided library
> description XML files is parsed and a search is made for the supplied
> target string. If the string is found, relevant
> data is retrived and formatted for display; the XML files can contain
> encoded representation of library API information such as function,
> struct, enum, typedef, etc., descriptions. The parsed versions of the
> XML files are retained, accelerating subsequent accesses of the
> fragment.<br>
> <br>
> <br>
> Patch Details:<br>
> <br>
> The patch is a sef-contained fragment that resides in
> org.eclipse.cdt.ui.libhover and plugs into
> org.eclipse.cdt.ui.CCompletionContributor. It contains a file
> glibc.xml, by default in org.eclipse.cdt.ui.libhover/libhoverdocs but
> which can be located anywhere, even outside of the Eclipse structure,
> with no more than slight modifications to the project fragment.xml
> file. Future descriptor XML files can also be put in the same
> directory, or in other directories along a defined search path.<br>
> <br>
> TODOs:<br>
> <ul>
> <li>Add the code to handle multiple descriptor XML files.</li>
> <li>Add additional descriptor XML files.<br>
> </li>
> <li>Add a means of allowing the user to (re)define the default search
> path.</li>
> <li>Add a means of allowing the user to select from the available
> descriptor files.</li>
> <li>Add a means of allowing the user to access whatever documentation
> parsers are available. (The only parser available at the present is
> the one that abstracts Texinfo files into the appropriate XML
> structure. It's not included in this package (yet.))<br>
> </li>
> </ul>
> Known problems:<br>
> <ul>
> <li>The first access of the extension is slow due to the time it
> takes to parse the XML file(s).</li>
> </ul>
> <br>
> Chris Moller<br>
> Senior Hacker<br>
> Red Hat, Inc.<br>
> </body>
> </html>
>
> --------------030006090601030506070104--
>
> --------------enig7352DD4097578904973B9C35
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFBAUPHLIWS6c1JuYMRAkmIAJ9trOGhBg7JErP7rMfdG8fjnTWpMwCglap0
> tNoACYPjhiHrT03Xpe2DaeQ=
> =nkVz
> -----END PGP SIGNATURE-----
>
> --------------enig7352DD4097578904973B9C35--
> _______________________________________________
> cdt-patch mailing list
> cdt-patch@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-patch
>
