- User Since
- Jul 30 2015, 8:46 PM (195 w, 1 h)
loh.tar, can you take a look?
If it is too complex to fix easily, we can still revert this and apply it again later together with a fix.
Thanks for pointing the CI fail out David!
:( Sorry, I didn't run them again, just tried out if it works in KDevelop.
Tue, Apr 23
This works for me fine with KDevelop.
I am not sure one can delay the updateGeometry stuff until one paints.
Unfortunately, the annotation stuff regressed.
I tried KDevelop, right click on text => Git -> Annotation...
See pre-patch and post-patch pictures below, the too small one is the post patch one.
I actually think the theme should contain all colors hard-coded and KTextEditor should properly use that instead of currently the mix of hardcoded/defaults.
The only automatism should be (in my eyes) to switch between a light/dark variant automatic depending on the base color of the current window.
But that is only my opinion.
I think the "we adapt to the color scheme" stuff is flawed.
Then we try that patch in master.
I think re-shuffling the indices there is no good idea.
Mon, Apr 22
Both diff + output change in the screenshot look reasonable for me.
We go with the minimal needed changes.
We go with the minimal invasive effort ATM: just remove F6.
As discussed in D17443.
We can introduce the CTRL-E... stuff later.
I would propose this fix:
Hmm, perhaps the restore view stuff does create the issues:
Hmm, the internal state is really broken if that doesn't work.
I don't think this check will really solve the issue.
Had you any chance to see a backtrace with e.g. the index?
Fri, Apr 19
You can submit that, perhaps with the discussed checks, thanks
And happy Easter ;=)
Given we have no actions and some more proper documentation, I am in favor of this.
Wed, Apr 17
The question is: with a context menu, isn't that then already too inconvenient?
At the moment we have no context menu for the bar at all.
I could live with the right click for the moment, we can still enhance that, if we add further "actions".
But I think we need at least an action in the "Code Foldings" sub-menu that does trigger this for the current active folding region.
If that is there, more can follow in extra changes, I think.
Tue, Apr 16
The build issue got fixed.
I think the feature is nice.
Mon, Apr 15
I like the idea, its nice for e.g. if then else cascades, you get then out of stuff like
Sun, Apr 14
Perhaps Nate has feedback, too.
I have no issues with this change.
Upsa, pushed it with my copyright update :/
:=) Nice that it helps.
Hmm, arc land didn't use the proper author :/
Guess I need to check that in the future more properly.
Ok with that?
Works ok for me.
Please try if my last commit fixed that:
Ok, I can reproduce the issue you mention.
I will take a look.
Didn't try folding :)
Sat, Apr 13
Ok, that sounds like a good justification ;=)
Nate, would you be ok with this, too?
You mean ALT-PgUp/Down, or?
Could live with moving that to ALT and the select to SHIFT-ALT.
But as "we are all here" anyways: Any ideas for better shortcuts in KTextEditor?
We have even "ctrl + shift + pageup" to select to top of the view :P
Just had not looked at this.
Looks reasonable, please push that.
Please submit a new request to make the existing analysis more clever for different languages.
What shall we do with this?
We close this in favor of the other patches.
5.57 released, should ne tried now.
Fri, Apr 12
I glanced at it, thought I have at home no Windows machine at hand to test if the command line works as planned.
I still think we should stay with status quo, can you drop this request?
Hi, if you have no update for this, could you close the request? Thanks.
I reconsider, I see no real value in removing the layout beside having a more densely populated toplevel menu.
Could we close this?
Please submit a new fix, if you have time.
I will close this.
The CI is a bit unhappy with the gzip depedency on Windows.
Might one just write a minimal KArchive based gzip'er for this? gzip isn't there on any normal Windows machine, even if you have libz.
Works for me, beside that the patch no longer cleanly applies.
But with some false removed and the later parts skipped, it did work as advertised.
I think this can go in as is, as long as the test works determinstically, which I assume it does.
Played a bit here with the new behavior, MUCH better than the old one.
I think this should go in.
The current implementation at least closes the file, in all applications.
It just doesn't remove in in all of them from the document list.
I think that is ok enough, more can't be done in KTextEditor.
Extra reviews for extending the applications are welcome.
I think the solution with the bool setting is good enough.
If nobody else disagrees, I would accept this later.
One could try to first do a closeUrl and just do the closeDocumentInApplication() in addition afterwards.
If you really want to close the document aka removing it from the application's document list, you need the interface.
If you just want to set it back to "untitled document" you can use closeUrl
That is because KWrite doesn't implement that interface function, unfortunately.
Thu, Apr 11
Wed, Apr 10
I think to not agonize MSVC it would be better to use the unicode code point for the QChar constructor.
After that is altered I think, too, this should go in, nice!
Ok, then we keep that license and push this as is.
Mon, Apr 8
Yes, I cherry-picked the change to 19.04, will mark bug as done.
Sun, Apr 7
See no obvious issues, please commit, thanks!
If you think you nearly changed everything, I guess MIT is ok.
If you think still too much is derived, I can live with LGPL ;=)
I let you decide.
Guess this makes sense.
The new functionality works ok enough for me.