From kdevelop-devel  Tue Jan 17 11:28:32 2006
From: Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date: Tue, 17 Jan 2006 11:28:32 +0000
To: kdevelop-devel
Subject: Re: Attempted to improve python support
Message-Id: <200601171211.28537.Richard_Dale () tipitina ! demon ! co ! uk>
X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=113749731226914

On Tuesday 17 January 2006 10:10, Satoshi Kinebuchi wrote:
> Hi list,
>
> This is my first post.
>
> I would like to add more power of python support to KDevelop.
> First of all I attempt to add code completion feature to it
> (and later I'm planning to add debugging feature).
Sounds good, but is it possible to add code completion for a dynamic language 
like python which doesn't have any static type tags? For ruby there is no 
code completion, although I do add instance variables to the class browser 
with the line number where they were first initialised as the place where 
they are 'declared'. 

Instead of the bash shell running in the konsole window I have the ruby 'irb' 
as a shell instead, so you could start a python shell by setting the 'SHELL' 
variable to python. A python debugger would be really good, and you might be 
able to adapt the ruby one (it should be closer to what you need than the C++ 
gdb debugger).

> Please give me some comments or advise about these:
>
> 1) What branch should I work for from point of now?
>    3.4, 3.5 or HEAD?
Put it in branches/kdevelop/3.4

> 2) What a reason or discussion made them decide to create hand-written
> parsers?
>
>    For python, interpreter already has well defined interface to parse and
>    translate python codes to AST. At first I planned to create a wrapper
> fit them to KDevelop's programming scheme.
>
>    Language parsers bundled with KDevelop are all written by hand.
>
>    There are already some nice parser/compiler for almost all of the
> language supported by KDevelop. I suppose it can be created by borrowing
> such parser's source code rather than from scratch, for example, gcc for
> C/C++ parser.
>
>    Was there any reason or discussion to be decided to do so? I mean,
>    I expect to decide which way (borrowed from python interpreter or
>    written by hand) is better to create python parser, including code
>    completion feature.
You can write the parser any way you like as long as you use the kdevelop 
methods to insert a node for a method or a class into the code model. I think 
there is a simple regular expression based parser for python at the moment, 
and so you can look at the methods it uses to build the class browser info. 
But it will be nice for kdevelop 4 to use a uniform framework based on 
Roberto's parser generator. That will make adding refactoring support easier 
for instance.

> 3) In case it would be better to create a parser by hand,
>    what is the best way to create it?
>
>    This is involved in Q1 and Q2.
>
>    Now there is Roberto's brand new parser generator, kdevelop-pg.
>    I'm heavily interested in it. But it seems like to
>    intend to be bundled to KDevelop4 (it does?). Is there a plan of
>    including his work to KDevelop's next 3.4 release? If so,
>    I'd like to take advantage of his excellent work to create python
> parser.
It would certainly be nice to have python parser based on Roberto's one for 
kdevelop 4, but I don't think anyone has thought about using it for kdevelop 
3.4 yet. That's because there hasn't really been much activity yet in the 3.4 
branch, but I can't see any reason why it couldn't be used.

-- Richard

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