I have file open in KDevelop (nepomuk/core/services/fileindexer/indexscheduler.cpp). On pressing the 'j' button in order to move down one line it crashes. This seems to happen on any part of the file. Reproducible: Always Steps to Reproduce: 1. Open the nepomuk-core project in Kdevelop 2. Go to the indexscheduler file 3. Press 'j' when in normal mode Actual Results: Does not crash Expected Results: It crashed! Surprisingly, the crash window doesn't seem to open up. I had to run this in gdb manually. Kate git head: - commit 42e0ada05d4cb50f765c3093a1a6ee97fd511530 Author: T.C. Hollingsworth <tchollingsworth@gmail.com> Date: Mon Feb 4 02:04:01 2013 -0700 give KatePart plugin docs a new home
Created attachment 76902 [details] Backtrace Gdb backtrace.
Not being able to use 'j' or 'k' was super annoying, so I decided to debug this a little. I apparently added custom mappings j -> gj k -> gk last night. Those seem to be causing the problem. Removing them fixes it. I'm guessing that it keeps expanding j -> gj -> ggj -> gggj ... Cause the backtrace seems fairly large and repeating.
Yes, there obviously is a recursion.
I suggest to change this bug in a feature request for nonrecursive mappings then. Also adding some check to prevent a crash due to endless recursion might make sense.
@Simon: if you have any ideas how to easily fix that, go ahead :-)
What would be the preferred solution, here? Disallowing a recursive mapping to be defined in the first place, or not expanding further mappings when executing a mapping?
(In reply to comment #6) > What would be the preferred solution, here? Disallowing a recursive mapping > to be defined in the first place, or not expanding further mappings when > executing a mapping? Since vim allows recursive mapping, I think it would be best if we also allow recursive mapping.
Does vim somehow guard against infinite recursion?
(In reply to comment #8) > Does vim somehow guard against infinite recursion? No, vim doesn't guard against it. Nevertheless, I don't think that this is an argument against doing so, at least as long nobody provides a usecase against doing so.
(In reply to comment #9) > > (In reply to comment #8) > > Does vim somehow guard against infinite recursion? > > No, vim doesn't guard against it. Nevertheless, I don't think that this is > an argument against doing so, at least as long nobody provides a usecase > against doing so. I'm not sure what you mean by this. The mappings in the bug report - j -> gj k -> gk were imported from my vimrc file and they work perfectly in vim. The use case is to be able to move up / down long lines which have become wrapped. Almost all vim users have this in their .vimrc file. They should be supported in our vim mode.
(In reply to comment #10) > I'm not sure what you mean by this. The mappings in the bug report - > j -> gj > k -> gk > > were imported from my vimrc file and they work perfectly in vim. The use > case is to be able to move up / down long lines which have become wrapped. > Almost all vim users have this in their .vimrc file. They should be > supported in our vim mode. Ah, no that wasn't what I meant exactly. That is supported by vim I meant rather what happens when you use: 1) :map x y :map y x and 2) :map g wg However, vim is smarter then vi (whose behaviour I remembered regarding this) and throws E223 in case of 1). 2) is still not handled.
I'd like some more clarification on what people would consider to be an acceptable solution, here. For example, if I had, say, x -> gj a -> x what would you expect the result of typing "a" to be? Move down a visible line? Delete the current character under the cursor? If the former, why would j -> gj be treated differently - because an infinite recursion can be detected?
(In reply to comment #12) > x -> gj > a -> x > > what would you expect the result of typing "a" to be? Move down a visible > line? Delete the current character under the cursor? If the former, why > would j -> gj be treated differently - because an infinite recursion can be > detected? I think both make sense, but vim's standard behaviour for map would be the first one. The second one would be the behaviour of noremap in vim. I can only specualate why j -> gj is handled the way it is, e.g. using j -> jj will move down to the bottom in vim (instead of two lines down).
So perhaps adding a "Recursive" checkbox column to the table (and the ability to distinguish between recursive and non-recursive mappings in the vimrc importer) and respecting this when executing a mapping is the way forward, here?
Generally that would help. I still don't know how vim handles j -> gj, though.
Let's take the discussion to here: https://git.reviewboard.kde.org/r/109962/
*** Bug 318781 has been marked as a duplicate of this bug. ***
Git commit 738f125aa6dc26fcb8f5c77e90ecd7d9660b11a0 by Simon St James. Committed on 04/04/2013 at 18:52. Pushed by sstjames into branch 'master'. Distinguish between recursive and non-recursive mappings: user can choose whether a mapping is recursive or not via the new "Recursive?" column added to the mappings table. Mappings are recursive by default. Mappings from configs before the introduction of this distinction are treated as recursive. The main motivator for this change is so that the mapping of gj -> j - very commonly used by Vim users - can be used without a stack overflow :) REVIEW:109962 M +30 -6 part/dialogs/katedialogs.cpp M +6 -1 part/dialogs/viinputmodeconfigwidget.ui M +4 -3 part/utils/katecmds.cpp M +26 -2 part/vimode/kateviglobal.cpp M +4 -1 part/vimode/kateviglobal.h M +2 -1 part/vimode/kateviinsertmode.h M +3 -1 part/vimode/katevimodebase.h M +18 -7 part/vimode/katevinormalmode.cpp M +4 -2 part/vimode/katevinormalmode.h M +2 -1 part/vimode/katevireplacemode.h M +72 -16 tests/vimode_test.cpp http://commits.kde.org/kate/738f125aa6dc26fcb8f5c77e90ecd7d9660b11a0
Simon: From the commit above, can this report be closed?
Dominik: I think so - if anyone disagrees, please re-open, explaining reasons :)