- User Since
- Apr 20 2015, 7:20 AM (234 w, 5 d)
Sat, Oct 12
@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.
Thu, Oct 10
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.
Tue, Oct 8
Mon, Oct 7
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? :)
Sun, Oct 6
Fri, Oct 4
I also think it's fine. A next patch could convert the QRegExp to a QRegularExpression.
Thu, Oct 3
@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.
Wed, Oct 2
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 hardet.
Tue, Oct 1
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.
Mon, Sep 30
Sun, Sep 29
Sat, Sep 28
Fri, Sep 27
Thu, Sep 26
Wed, Sep 25
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.
Tue, Sep 24
Mon, Sep 23
Sep 16 2019
What happens if e.g. vi or another text editor is open? Do we send the cd... command then to the editor?
Sep 15 2019
Yes, forgot to accept, sorry.
Ok, let's try this.