This is only a workaround to avoid cases where Kate can crash due to a
run out of memory.
CCBUG: 333517
Details
Details
- Reviewers
loh.tar - Group Reviewers
KTextEditor VDG
Search warning
Replace warning
Diff Detail
Diff Detail
- Repository
- R39 KTextEditor
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
Hmm, I don't like such hard limits.
e.g. in our company, more or less all machines have 32 or 64 GB of memory and that should work fine.
(not that I say we should use that much memory).
I would more like either a fix for the memory hogging or a soft-limit, like you report "oh, we already do xxxxxxxxx replacements, that might take a lot of memory, do you want to continue? x remember that choice..)
That will rescue people that replace stuff by accident and still let people with "a lot" memory use the tool like they want ;=)
Comment Actions
- The mentioned crash could I not reproduce, but after 5 million hits and a felt eternity I had killed Kate
- There is an issue now with the wrap message, where is now the same close button. Any ideas what's wrong?
- I like to suggest to get rid of most of that S&R code and use instead code from the Search plugin. There is the S&R done in an own thread and did not block the UI.
Comment Actions
For the: I like to suggest to get rid of most of that S&R code and use instead code from the Search plugin. There is the S&R done in an own thread and did not block the UI.
I would for sure like to have batched search/replace, e.g. that one does the stuff in chunks via single-shot timers and doesn't block the UI for e.g. incremental search that would be really nifty.
That would allow people to abort long running stuff, too.
(even no threads needed, just batch the stuff in e.g. 1000 line chunks)
I would really love to have this improved, I think there are some bugs around that wish for non-blocking search/replace, too, like other proper editors have (and we not, shame on us)
Comment Actions
Would be good you take the time and do that test @cullmann When you then think it is still useful to soften that limit let me know how.
To become that code more smart as you suggest I have right now not the mood, sorry.
I think this patch is good enough to avaoid the biggest trouble.
Comment Actions
I am still not that happy with a hard limit, I will first work a bit on the root causes: that the speed sucks ;=)
Comment Actions
I think the current state after the improvements in the other bug is good enough to avoid such a message.
Would it be ok for you to abandon this?
Comment Actions
In this state was this patch only a simple attempt to avoid the worst case.
With your new improvements is it much less likely to happen, but still possible. I do not like to insist of this patch it's only an offer, which could be improved.
BTW I'm working on your suggestion to add a (functioning) Cancel button. With that, this patch may become more obsolete ;-)
Comment Actions
Ok, I would prefer then if you retract that and submit the cancel thingy.
Btw., thanks for all the nice improvements that are submitted!
Such fixes are highly appreciated.
If you think a review is not done timely, no issue to e.g. poke me.