loh.tar added a comment.
OK. I spend some time again, but give up now.
I've got the feeling that these key event handling is not very well
engineered.
May someone else take a closer look for some better solution, or at least try
this patch, if it breaks some other functionality.
REPOSIT
loh.tar added a comment.
hm, it may better to avoid to call that function at all in case of Ctrl-F (?)
Will take a look.
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D19408
To: loh.tar, #ktexteditor
Cc: dhaumann, cullmann, kwrite-devel, kde-frameworks-devel, #k
cullmann added a comment.
I am unsure about the toplevel &&, wouldn't one just want that for the return
case?
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D19408
To: loh.tar, #ktexteditor
Cc: dhaumann, cullmann, kwrite-devel, kde-frameworks-devel, #ktexteditor,
loh.tar added a comment.
- Assume you add "qDebug() << keyEvent;" on top of this function
- For whatever reason is by Ctrl-F this code running with
`KateVi::Completer::completerHandledKeypress: QKeyEvent(KeyPress, Key_Enter) `
- When you you hint return it looks like this...
`K
dhaumann added subscribers: cullmann, dhaumann.
dhaumann added a comment.
Hm, I currently cannot say anything to this patch. I wonder where the \r
comes from. And also, I wonder whether this if now is ever true? ...but if it
fixes the issue... @cullmann: objections to a blind commit?
REPOSI
loh.tar created this revision.
loh.tar added a reviewer: KTextEditor.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
loh.tar requested review of this revision.
REVISION SUMMARY
BUG:368130
TEST PLAN
I'm not a vi mode user, so I can't say
