D17932: Improvements to completion

Thomas Schöps noreply at phabricator.kde.org
Sat Jan 12 18:04:04 GMT 2019

thomassc marked 4 inline comments as done.
thomassc added a comment.

  Thanks for reviewing. Regarding the question about which models would have an insensitive exact match, and which ones have sensitive exact matches:
  - An example for case-insensitive exact matches might be plain text, or a hypothetical case-insensitive programming language. For example for plain text, one might want to treat words like "Question" and "question" as exact matches, which will make the completion widget close itself when it shows one of them and the user types the other. This is the current behavior for the word completion in KWrite / Kate.
  - An example for case-sensitive exact matches would be a case-sensitive programming language like C++. If the user typed "m_var" but the variable is actually called "m_Var", then the completion widget should not hide itself, since it might still be useful to replace the typed text with the completion item that has different case.


> mwolff wrote in katecompletionmodel.cpp:2026
> maybe simplify this to:
> if (matchCompletion && m_nameColumn.startsWith(match, model->exactMatchCaseSensitivity())) {
>   matchCompletion = PerfectMatch;
>   m_haveExactMatch = true;
> }

Hmm, I guess the current version might be a tiny bit faster in general since it only does another startsWith() check if this would be a stricter check than the one done before ...

> mwolff wrote in katecompletionmodel.h:394
> should this comment be asserted in the setters or is it handled gracefully in the logic below?

I added asserts to the setters. One should be aware then though that it restricts the order in which these must be called. For example, if both settings are case-insensitive at first and both should be changed to case-sensitive, then the exact-match-sensitivity must be changed before the match-sensitivity. Alternatively, one could make a single setter function that changes both properties.

  R39 KTextEditor


To: thomassc, #ktexteditor, #kdevelop, mwolff
Cc: mwolff, cullmann, kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, bruns, demsking, head7, kfunk, sars, dhaumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20190112/ed22a826/attachment-0001.html>

More information about the KWrite-Devel mailing list