- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 24 2020
May 23 2020
May 17 2020
Hmm, consider though that a configuration option should be something that gives a choice to the user. It shouldn't be necessary to set a config option in order to make the program behave correctly.
May 5 2020
In D25339#663915, @fakefred wrote:I second the as-an-option proposal. Hey, why not automatically increase the line height when CJK characters are detected?
Apr 3 2020
Patches naturally get more attention than feature requests in bug reports, because even if in the feature request everyone agrees it's a nice idea you still have to find somebody to actually do it -- which is often not the case ;) and then it's just wasted time to discuss it in the first place.
Mar 25 2020
The 10 line limit also seems kind of arbitrary to me. KDevelop has a similar navigation feature and navigates by "contexts". A similar concept exists in KTextEditor in terms of the folding ranges; maybe that could be used to classify "meaningful" cursor moves to navigate between?
Mar 7 2020
I also don't understand this. Even if the painting somehow changes, e.g. because some painter state is set which wasnt set before (which I do not see to be the case here), that should not affect the line layout, as that is computed separately.
Looks good, thanks! Yes, it's an improvement.
Jan 25 2020
Ok, done ;)
If you want I can integrate these changes and submit your patch, should I? Thanks a lot for your contribution.
Jan 24 2020
I'm sorry, updateView is the wrong function to call, you need updateDirty. I tried it out, like this it works:
Jan 23 2020
Then it seems like the line is not tagged correctly. Maybe try tagLines(note.position.line(), note.position.line())? I think the column being the same is not what the function being called expects.
Jan 22 2020
My guess is right now the view updates when the cursor blinks, so that's why it updates after a short moment (of varying length, though, if you look at the video). Since the line is tagged dirty, it gets repainted correctly, but too late.
Hm, yeah, looking at the code I think you might need to call updateView() in case a focus in or out happened. Can you try if that makes a difference?
Is the video the new behaviour? It still looks a bit weird to me, there is a slight delay between the mouse entering the area and the highlight changing.
Jul 21 2019
In D22595#499060, @dhaumann wrote:They have some more sophisticated tooltip that may be of interest in case the tooltip is not nice/good enough over time.
Jul 17 2019
LGTM, thank you!
Jul 16 2019
Also here, looks good to me, but I would wait for feedback from somebody else in addition. Thank you for working on this!
Independent of anything else I think this is a very sensible change, and seems like an oversight / bug.
I'm not sure if this solves the right problem.
Jun 10 2019
Why did you replace the registry query by a fixed path?
May 30 2019
Great to have this fixed, thank you!
Apr 26 2019
I guess the intention of the highlight delay is that when you move your mouse across the border, the view doesn't flicker. The 150ms does this well enough for me, I never see a flicker at least ;)
Mar 30 2019
Looks sensible, and I think I've even seen this bug already somewhere.
Mar 9 2019
Sorry, yeah, I misunderstood!
Hm, so shift-selecting with Shift+Left 5 times, then pressing Shift+Right once clears the selection? Just for the statistics, deselecting one character is a feature I use all the time.
Mar 6 2019
FWIW kdev-java was to my knowledge never really working. I think at some point a lot of the code started as effectively a fork of the old C++ plugin, which was then gradually (but not thoroughly) adapted to java ...
Thanks, certainly better than bitrot. I can't really imagine it won't crash with any non-trivial project though :/
Feb 13 2019
This is not something that should be configurable. The follow-up to hard-to-understand options shouldn't be to add more of them.
Jan 29 2019
To clarify, the patch back then was less about the first-time delay, and more about the delay being there *every* time because of wrong usage of the API. Whether the delay occurs once is arguably a bit less important.
Jan 9 2019
Thanks for working on this!
Something which would be quite powerful too would be to execute a tool on saving a file. This would e.g. allow integrating formatting tools such as golang's very easily.
@pprkut can you look at this? I have not used PHP or its tooling for more than 10 years ...
Jan 2 2019
Hmm, maybe the better way to achieve this effect would be to disable *automatic* invocation of completion after numbers? I already noticed that this is mostly undesirable, too. This is probably something you don't want to fix in the Clang plugin, but in KTextEditor instead ...
Dec 22 2018
Looks ok to me! Maybe put it into master?
Dec 10 2018
I would also advise against calling processEvents() to keep UIs responsive in all cases. It's tempting, but it is near impossible to get it right. What about conflicting actions, close/resize events, dbus calls, etc etc that are handled here?
Dec 7 2018
Dec 6 2018
Dec 2 2018
On Linux quite possibly too, I think many packaging systems install into some temporary dir and then copy the deployment out of there for archiving.
Nov 29 2018
Shouldn't this change simultaneously remove the line length limit ...?
Nov 25 2018
It has often been discussed whether bug 398525 is actually valid, without real conclusion. Since the tabs do not show all documents, but only the n most recently used ones, it to me makes a lot of sense that new documents are added at the left, and then "drop off the shelf" towards the right if they are not being used, into the dropdown-menu.
Nov 24 2018
Since it only touches a test, I don't see any issues with putting it into 5.3. Thanks!
Looks good, thanks!
Nov 21 2018
Nov 17 2018
Looks ok to me, thanks!
Nov 13 2018
Sorry, I don't see this going in in this or a similar form.
Nov 4 2018
A solution might be to extend KXmlGui to somehow support such situations,
and decide who owns the shortcut by looking at the focus.
Oct 31 2018
Oct 30 2018
Oct 29 2018
I'd have to use this for a while to see whether it works well in practice, but in general it seems like a cool idea.
Oct 25 2018
Any help on the Windows version is greatly appreciated, whenever you find the time for it. :)
Oct 23 2018
Well, I guess adding line offsets is just the level of abstraction our code gen works at, anyways. Which is good enough. In my opinion, go for it ;)
Is the opening brace always on its own line, independent of the formatter selected?
Oct 22 2018
I'm inclined to say this looks innocent enough to go into 5.3 ...
Oct 21 2018
Can go to 5.3 in my opinion. Thank you!
Oct 17 2018
I'm not a huge fan of tuples either, for the reason you mentioned; I usually just create a two-element struct instead. In this case I think it's fairly obvious what the elements do from the types, though; the QPair<int, int> is worse ;)
Up to you how you do this, I just wanted to point out that it is done differently in two similar places.
I think the change conceptually makes sense, and I am subconsciously aware of the bug it is trying to fix. If you say it works for you, it should be fine.
Oct 15 2018
If there is no solution which does not require two different code paths for handling this problem, I'm against merging this, non-conformant old behaviour or not, sorry.
Oct 12 2018
I also find this reasonably simple to read. The "type your compiler arch" thing is extremely 80s of course, but the whole concept is a hack :/
Oct 11 2018
Code-wise this looks fine to me otherwise.
I can try it out.
I think the main performance issue here was fixed in 90f51f5830e32998d41a710c448212e49e1be04a, in my profiles that took >95% of the time. It's still worth optimizing, but I think no matter what you do there should not be complaints like the one linked in the bug report any more ...
Oct 9 2018
Otherwise looks good! If you feel super ambitious you could add a test, should be very simple ;)
Oct 5 2018
Looks good to me, and with little risk ... on Linux nothing changes, on Windows we test it anyways before shipping.
Oct 3 2018
On Arch Linux, the latest version of the patch seems to work fine.
Sep 26 2018
Sep 23 2018
Sep 19 2018
Sep 5 2018
I'm not really capable of doing an in-depth review here, since I don't know enough details of PHP nowadays. Style-wise I think it could still profit from reducing the block size of un-named (i.e. not a function with a name), uncommented complex code a bit, since it often requires quite some thinking to grasp what a certain conditional actually checks for. A simple comment like "// not a function" or whatever can do wonders there.
Feel free to merge this as-is or with a bit more comments, better get it in before the beta and still have a fix window before the release than merge it after the beta. Thanks for keeping kdev-php alive!
I'm super confused by the diff phabricator shows below but the commited changes are correct (and different from the diff here) ... what's going on?
For the record, I tried writing a test for this but didn't succeed and eventually put it aside, although the difference is easily visible in a test application. There must be a reason why the naive test case behaves differently from an interactive application ... I could take another look, I guess.
Aug 21 2018
Aug 20 2018
Aug 19 2018
Aug 17 2018
Sorry, never mind -- that code I removed yesterday. All should be fine.
Looks ok to me, except one thing: the operator== is used to compare a note from the list to the "currently active" note in the view. If this compares also the "under mouse" state, this code might be broken now ...?
Good amount of tests :) For the actual implementation, I would suggest trying to make it a bit more readable by a) splitting it up into several functions and b) trying to reduce indent depth a bit by using continue instead of nested ifs.
Maybe you make the the visitAssignment code a bit more readable by breaking it up into 2-3 functions?
As I said at Akademy already, I am neither familiar with the code of the PHP plugin nor with the later developments in the language itself, so I'm not a good reviewer for these patches. But since you want to get them in and nobody else seems to have time, I have read through this and I can't spot anything obviously wrong or stupid. We'll have a beta to try it out :)
Thanks for the patch, the approach looks reasonable at a first glance. You might want to unite the up/down functions ...
It is too much of a WiP to merge it like this, though.
Aug 16 2018
commit 4ea5fee0afe5c76bbee07563c23ede808aa059de
Author: Sven Brauch <mail@svenbrauch.de>
Date: Tue Aug 14 12:31:31 2018 +0200
update license text
Implement Dominik's suggestions