New parser branch (Was: Dumping the source DOM?)
daniel.franke at imbs.uni-luebeck.de
Wed Jul 13 21:06:06 UTC 2005
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)
- code completion (available - sometimes)
- refactoring (planned)
The drawbacks as I know them:
- slowed down typing, the problem reporter reparses whatever I typed
- 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)
- as I understand it: code-refactoring is a buzzword for search-and-replace?!
From my user's point of view: I KNOW my funtions, I KNOW the libraries I use,
I KNOW what I've written before. If there are any typos (e. g. a missing
';'), my compiler will tell me, there's no need that the IDE does. 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.
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 =(
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 ...
Get yourself a cool drink and think about it - please.
More information about the KDevelop-devel