Version: (using KDE 3.5.9) Installed from: SuSE RPMs Implementation: int foo() { int x;| } I switch to interface: |int foo(); and back to impl. |int foo() { int x; } My wish is -- be less agressive, the cursor is already within the function pointed out, so maintain the position of the cursor. Of course if it is not --> then search it and place the cursor like shown above.
Yeap, that would be really cool. Unfortunately its not quite easy I think, but I'm pretty sure our C++ expert will find a way :)
No, it wouldn't be cool, it would be inconsistent: If you ask the IDE to take you to the implementation, it should put you in a predictable place (the first line), not put you (for example) 400 lines into the function just because that's where you happened to be last time you visited it 8 days earlier. (Extreme example, but I hope it puts the point across.) This would be completely unexpected and seem like a bug to the user. If you want to go back to where you were, use 'back'. Adding code to introduce unpredictable and inconsistent behaviour is a bad idea, IMHO. This is a WONTFIX in my mind.
Jens, you have pretty good point instead those 8 days. I was already there (today, now). And! Think what is is much easier: a) jump to function header b) swift through all the code to find the place you were ad.a) int foo() // go here { 400 lines of code | } This is easy (there is not automatic function in KDevelop, yet :-) ). ad.b) |int foo() { 400 lines of code // go here } This is extremely hard, because you have to memorize all the functions body. So, if user dislike it she/he can correct the jump right away, otherwise (in today implementation) it is not trivial to go back to the line you were.
PS. Function body _is_ implementation, and this place is predictable because you (user/developer) set the cursor today after launching KDevelop.
The problem is that you would never know whether the jump succeeded or not, I think storing the position would be quite annoying, especially storing multiple positions within a single document. We have navigation history for that. A compromise that would not be too annoying, and very easy to implement, is this: - When jumping to a definition, and the cursor within that editor view is already within the body, leave the cursor alone. Then you could switch to the header and back, and still be in the same position.
> The problem is that you would never > know whether the jump succeeded or not, David, I don't see it. > I think storing the > position would be quite annoying, especially storing multiple > positions within a single document. We have navigation history for > that. You have to store only one position. Btw. it is already stored (in case of .cpp/.h files). In case of one file -- only one position more -- but again, it is also stored already, in history. > A compromise that would not be too annoying, and very easy to > implement, is this: - When jumping to a definition, and the cursor > within that editor view is already within the body, leave the > cursor alone. Good, but would not solve .cpp/.h case.
> When jumping to a definition, and the cursor within that editor > view is already within the body, leave the cursor alone. This is what I thought Maciej meant, but this would still (potentially) create unexpected results. While KDevelop might remember where I was in a file, I might not. Assume I have a few dozen files open, some I might not have visited for weeks. Maybe KDevelop was open for that long, or (at least this would happen in KDev3) they were opened _and the cursor placed_ as part of the session. Either way, weeks ago, the cursor happened to be left somewhere 400 lines down in a huge function I don't remember visiting and when I ask KDevelop to take me to this particular function's implementation, I will NOT expect to find myself 400 lines down! Maciej is looking for "focus follows mind". Unfortunately, it hasn't been invented yet.
I completely agree with David, having Switch Header/Implementation not change the cursor position if it already is inside the implementation is what I had in mind. I never thought of storing this across kdevelop starts, or even after closing the editor view. That part is a wontfix, but not having the cursor jump to the start of the implementation if it is already inside the function body would be cool.
Jens, I think this is useful for the "normal" users of KDevelop (such as myself, David and a few others I met recently ;). BTW: All this is KDevelop4 material and you probably don't want to have 400 files open for half a year in that version anyway ;)
If I might... Jens, let's focus on most disastrous scenario -- you are running Kdevelop for 8 days, you switched to implementation and you are in the middle of some horrible 4000-lines function. Fact -- you are inside implementation -- that's a guarantee (by KDevelop, because switch was made). Now -- I cannot see why header function (which I already saw, it is a interface after all) is better than function. But let assume your point of view that it is better to start from, well, the start. Then -- press ctrl+win+up (*) and voila you are at the beginning. (*) let's ignore the fact that this feature is missing, but it is useful anyway to have it, so it will happen sooner or later :-) So... I agree that "focus follows mind" is great :-) but I see nothing wrong with the behaviour I described above. a) no surprises b) ability to mimic current behaviour c) advantage of smart switch -- almost focus follows mind, when it is correct, you are not distracted at all, the work is fluent, if it is not right, there is no saving, but there is no loss either Summing up -- in some cases there is no difference, in some there is advantage.
Right. I tend to focus on worst case scenario, and the problem I see is that I will find myself placed in potentially unfamiliar code, not knowing it is infact the body of the function I sought. Andreas, I agree that is useful. In fact, I think I would prefer to have it too. But this doesn't change that the result can be unexpected, which is never a good thinkg. Anyway.. I think you are right, it might be more good than bad. > Then -- press ctrl+win+up (*) and voila you are at the beginning. > (*) let's ignore the fact that this feature is missing, but it is > useful anyway to have it, so it will happen sooner or later :-) It isn't missing in KDevelop3. (I know, I implemented it.) The actions are called "jump to next/previous function" and have default shortcuts Ctrl+Alt+PgUp/PgDown. :)
I have done this now in KDevelop-4. When the cursor is already in the target function, it is not moved.