--nextPart3628063.1jqFDVTuaf
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 20 April 2006 03:11, Alexander Neundorf wrote:
> On Wednesday 19 April 2006 10:55, Hamish Rodda wrote:
> > On Wednesday 19 April 2006 06:37, Alexander Neundorf wrote:
>
> ...
>
> > The approach being taken by active developers is our internal parser, a=
nd
> > we are confident that with time it will get up to scratch.  Currently I=
'm
> > refactoring it from stdlib to qt, to make it more accessibile to myself
> > and other developers for hacking.
> >
> > So unless there's someone willing to mentor a potentially competing
> > method for parsing support (and kdevelop-pg will cover not just c++ but
> > as many other languages as parser definitions are written) then the only
> > SoC project on parsing + related features that makes sense to me is
> > working on the internal stuff.
>
> I think the problem can be divided into at least two parts:
>
> 1) getting the information out of the code
> For this some kind of parser is needed.
>
> 2) Doing something useful with this information,
> like autocompletion, jump to declaration/definition, show all uses, rename
> function/member/variable etc.
>
> Part 2 is still more than enough work. I just wondered whether we really
> have to manpower to get both done.

It's more work to integrate something foreign than to continue with what we=
=20
have (imho).

Cheers,
Hamish.

--nextPart3628063.1jqFDVTuaf
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBERzkaH8BtnSmIlUYRAuJ7AKDcMM0eD8tSWfzMzEuvALsa5VmLnQCgjiIK
lBnvaCUGm1czVfb+DXqltQg=
=RO3e
-----END PGP SIGNATURE-----

--nextPart3628063.1jqFDVTuaf--

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel