D17932: Improvements to completion
Milian Wolff
noreply at phabricator.kde.org
Sun Jan 13 13:18:35 GMT 2019
mwolff added subscribers: brauch, kfunk, apol.
mwolff added a comment.
In D17932#392060 <https://phabricator.kde.org/D17932#392060>, @thomassc wrote:
> 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.
please put that information into the commit message - I think it's valuable to have
overall, I think I'm in favor of getting this in - but I'd like to get input from others. @brauch , @kfunk, @apol what do you have to say to this?
INLINE COMMENTS
> thomassc wrote in katecompletionmodel.h:394
> 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.
either that, or handle it gracefully (with a warning?) wherever it's used?
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D17932
To: thomassc, #ktexteditor, #kdevelop, mwolff
Cc: apol, kfunk, brauch, mwolff, cullmann, kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, bruns, demsking, head7, sars, dhaumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20190113/d6ba9986/attachment.html>
More information about the KWrite-Devel
mailing list