[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: New parser branch (Was: Dumping the source DOM?)
From:       "Steven T. Hatton" <hattons () globalsymmetry ! com>
Date:       2005-07-13 19:49:12
Message-ID: 200507131549.12845.hattons () globalsymmetry ! com
[Download RAW message or body]

On Wednesday 13 July 2005 15:05, Daniel Franke wrote:
> Hi all.
>
> Since you guys flood my mailbox with this discussion of yours, I feel
> inclined to speak up also. It might be blasphemy to your eyes, but let me
> ask a question from the users point of view:
>
> 		Does kdevelop need a background parser at all?
>
> The benefits as I understand them:
>  - problem reporter (available)

Could probably be better.  More context sensitive.

>  - code completion (available - sometimes)

Better, more complete, more accurate code completion.  I don't use code 
completion very much to speed up my typing.  I believe KDevelop has been 
moving in this direction, but if you've ever used JBuilder, you will 
understand that accurate, context sensitive code completion is (sometimes) a 
very powerful tool.  It's like having summary documentation at the edit 
point.  If you're dealing with a new and/or complex library, code completion 
can show you all the member functions with all the signatures of a class 
(preferably with the base class's as well).  It would be nice to be able to 
distinguish between whether the member is available through `->' or '.'.

I don't know if background parsing plays into this, but the ability to have 
#include completion for the whole include path would be nice.  I'd also like 
to have member initialization block completion with an indication of whether 
the members are in declaration order.

Additionally, it should be possible to filter out all the classes which are 
not part of the translation unit defined by the current #includes.  If you 
type a class name, it should be possible to open a search dialog and locate 
all the candidate matches.  When you select the correct one, it should add 
both the header (if needed) and any namespace qualifiers needed.  

>  - refactoring (planned)
>  - (others?)
>
> The drawbacks as I know them:
>  - slowed down typing, the problem reporter reparses whatever I typed

I don't have much of a problem in that area.  Even if your computer is no top 
of the line this year, you will probably get a better one sometime, and when 
you do, what you suffer through now might pay off.

>  - I don't use the code completion, I'm typing faster than the code
> completion can show any hint (but typing faster is slowed down due to
> problem reporting)

You can also get code completion on demand with Ctl+Space (or something like 
that).  Can you adjust the timing on the background parser?

> - as I understand it: code-refactoring is a buzzword for 
> search-and-replace?!

In Java, it means taking an entire package (roughly equivalent to a namespace 
+ source file directory) and rename it.  All the code in the package, all the 
code referencing it, and all the relevant directories are renamed in one 
shot.)  But there is potentially far more to it than that, for example, it 
could manipulate header includes as needed.

> From my user's point of view: I KNOW my funtions, I KNOW the libraries I
> use, I KNOW what I've written before. 

I don't, and I never will know what's in all the libraries I use.  For one 
thing, they are continually growing, and another, I am always working with 
new ones.

> If there are any typos (e. g. a 
> missing ';'), my compiler will tell me, there's no need that the IDE does.

It saves time when errors are detected early. 

> The IDE shouldn't slow down my typing because it tries "to be smart". The
> IDE should ease my life by handling the autotools stuff, qmake, the
> compiler settings, keeping track what's part of my project, the build
> process, ease the access to any documentation that's around, packaging ...
> all that annoying stuff that stops me doing what I like, digging in the
> code. An IDE should be a silent, humble helping tool -- and not try to
> outsmart me.

Turn off the features.

> There are so many usability issues out there (e.g. "how to set up a
> compiler, I just love that question), maybe we should try to get THEM
> right. I feel that kdevelop has "featurities", as many features as possible
> - but only a few of them ever mature =(

Useful to you.  There are lots of features I wish KDevelop had, but it doesn't 
have. You named a few. Every week I take a few hours and try to get more 
familiar with the code base so that one day I might be able to contribute 
real code.

> One may reply, if you don't like it, don't use it. I like kdevelop very
> much - but I disable the "smart" features as completely as possible. In
> addition, I'm using vi sometimes ...

If you really are so skilled at programming that you don't need any of these 
features, and you know all your libraries by heart, why not take on a 
challenge and implement the features you want in KDevelop? 
-- 
Regards,
Steven

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]