- User Since
- Apr 20 2015, 7:20 AM (242 w, 4 d)
Wed, Dec 11
Tue, Dec 10
Was anything of the previously commented issues addressed?
Sun, Dec 8
Doesn't this patch imply we have the same action twice now? Once provided by Konsole, and once by katemdi via View > Tool Views > Show Terminal?
Fri, Dec 6
Thu, Dec 5
Do we dislike iterators now?
We don't, and they still make sense for when you need the key, but range for is just much nier to look at :)
I'm fine with that statement. But are we going to be reviewing changing all the KDE code from iterators to range for? Feels like an overkill to me.
Looks good. But does the highlighting work for RW+CD? I am wondering whether + needs to be added to the weakDeliminator list?
Wed, Dec 4
You can achieve Dolphin's behavior by reassigning the F4 shortcut to View > Tool Views > Show/Hide Konsole. That's what I do since > 10 years, and it works perfectly. Why is it not the default? Maybe because this action does not exist by default (i.e. when the Konsole plugin is not loaded). But the right fix is to reassign the F4 shortcut to this action.
Tue, Dec 3
Mon, Dec 2
Tue, Nov 26
@jhayes Do you have commit access, or shall I commit this for you?
Any news here?
I think we should decide what to do with this patch, as over time it will get merge conflicts.
Sun, Nov 24
I think this is ok.
Sat, Nov 23
Makes sense, thanks.
Fri, Nov 22
Tue, Nov 19
Sat, Nov 16
Can't you call rehighlight() yourself after calling setDefinition()?
You can force the current clang format to keep the multi-line if as follows:
Nov 11 2019
Nov 10 2019
@hein: Could you add a commit that relicenses all code to MIT? We switched to MIT for entire KSyntaxHighlighting. This will ease integration later.
Thanks, please commit! PS: Kate is also on gitlab: When pushing your branch to KDE's kate.git, the git push output will tell you how to create the merge request. But you can push directly as well, if you want.
Oct 31 2019
Also can't make it.
Oct 29 2019
Looks good to me.
Oct 28 2019
Hm right... too bad. I was hoping to find an automated way to detect this. Since relying on the user to optimize the RegExps will always be suboptimal. @cullmann Do you have any ideas?
Good, fine with me.
One option would be to add a capture or dontCapture attribute to enable or disable captures for RegExpr rules. Also, captures could be enabled or disabled in all RegExpr rules using the <general> group, adding an element for that.
Oct 27 2019
It's hard to review all the pixel changes with no screenshots. It's even unclear to me what problem exactly is fixed at hand. Given it's all your code, I trust you know what you are doing...
I wonder if the ?: optimizations make sense. QRegularExpression has the option QRegularExpression::DontCaptureOption to not capture anything. Looking into our code we have:
Oct 25 2019
Looks good to me, thanks!
Oct 20 2019
Imo we should simply try: We have another two weeks for testing.
Oct 19 2019
Oct 12 2019
@kossebau Just tried Okteta on Windows that is available on https://binary-factory.kde.org/job/Okteta_Nightly_win64/ and it works really well, out of the box. I believe it really has a lot of value making Okteta more visible, especially since users on Windows would also use it on Linux.
I'm all for it. This would unify how we can reformat any KDE module, which is very much desirable.
Please increase the version number and commit.
Thanks for the quick update.
Oct 10 2019
The External Tools plugin is done for now. I would like to wait a bit to get feedback, and over time we can certainly add more default tools, or even extend the plugin with additional functionality.
I believe work should be invested into the LSP client, since it provides an outline as well. Over time, the language servers will get better and better, so you'll get all this for free.
Oct 8 2019
Oct 7 2019
I'd go for a QVector for now. Arguing with Qt6 doesn't sound convincing to me, since Qt6 will take another>=1 year(s). So why try this experiment in public API now? :)
Oct 6 2019
Oct 4 2019
I also think it's fine. A next patch could convert the QRegExp to a QRegularExpression.
Oct 3 2019
@graesslin pong? One year passed.
I think it's fine as is. The docbook says:
This looks good to me and as mentioned in D24354 WordDetect is better than RegExpr.
Thanks a lot!
Makes a lot of sense and looks visually good in the screenshot. I'm taking the liberty to give a +2.
+1. This is also in line with typical zoom factors in other applications such as Okular, which also use percent values.
Oct 2 2019
Hm, would it make sense to change this? I.e. if the word itself has a word boundary, also use this?
Would it also be an option to fix WordDetect? I always thought WordDetect ignores the string contents, it should only check on the boundaries left and right
Thanks Nate for the update, I think this is very transparent to users and makes using bad values by default a bit harder.
Oct 1 2019
As far as I understand, the reasoning of @cullmann is that 0.1 cannot be accurately be represented by a computer. Following this discussion, the number 0.1 will turn into either 0.09999999999999999167332731531132594682276248931884765625 or 0.1000000000000000055511151231257827021181583404541015625.
Sep 30 2019
Sep 29 2019
Sep 28 2019
Sep 27 2019
Sep 26 2019
Sep 25 2019
I'd indeed prefer another/separate diff. :)
There are also changes in other xml files. Are these intentional? E.g. the changes from WordDetect to RegExpr seem suspicious.