Menu
▾
▴
#1025 Cut and Paste takes too long
None
closed
nobody
None
1
2014-11-07
2014-06-27
Anonymous
No
Cutting and pasting takes way too long compared to a usual editor (under Win x64 8.1 at least).
If I mark some line of code and cut it out it sometimes takes seconds until I see the marked code disappear.
When I paste it somewhere this mostly workes instantaniously.
It is really annoying, if you want to quickly cut&paste stuff and thereby reorder the document, that one always has this little showstopper in between.
Not reproducible here.
The parts are mostly just a bunch of words, even only single words.
I have several files open at the same time (5 to 10), I try to keep the filesize short using this approach. The largest files still have up to 500 lines.
I didn't experience any lags when deleting, as far as I can remember from the last weeks of usage.
Which version of TXS are you using?
How many lines are you cutting?
Is it faster, if you disable grammar or syntax checking?
I am using TeXstudio 2.8.0 (hg 4553+:dc1171a92ce0+)
Just right now, I had seven document open. Six of them are included in the also opened master document.
The selected document has 16 lines with 210 words.
I cut out a part of a line, which took a second or two; this was the cut text.
"\smalltodo{inline}{Erläuterung fehlt, andere dieser seite zu überprüfen}".
I switched off grammar checking.
This changed nothing.
Last edit: goeck 2014-06-29
Does it always happen or only in specific situations? In particular please test with a line only containing text and cut part of that.
I have two PCs with TXS on it. I only experience this with Win7 x64 1st Gen Intel i3, HDD, but then always and no matter if it's text or also latex commands or whether it's one word or a whole line.
On the other PC running Win8.1 x64 with a 4th Gen and SSD. i5 I almost never experience this issue.
Thanks for the patience and help while testing. Since it happens only on one system, can you please download the portable version and try it on both systems?
Well, I tried the portable version on both systems. The new 4th Gen i5 system was snappy as usual, no complaints. The old 1st Gen i3 system was snappy as well, though there was just a little lag, but not quit very obvious and disturbing. At the same time using the installed TXS was as snappy as the portable version on both systems.
I opened the same files in all 4 versions and cut different chunks of text. A bunch of lines, only some words, only some letters ... all worked pretty well.
Just now, I powered up my i3 system and opened installed TXS, loaded last session, cut something, takes a second. I don't get it. Yesterday I did the testing against the portable version. All was fine, as I stated. I reloaded the portable version and loaded the same files (closed installed TXS previously). It takes even almost two seconds to cut something.
I don't know what the clue is, but yesterday all versions worked fine. Today, all versions show this buggy behaviour
As long as we don't have a reproducible test case, there is litte we can do about it.
If I understand this correctly, it happens only on your i3 system and also there only sometimes. If the lag appears, does it at least appear constantly for a time (i.e. when doing cut-undo multiple times in sequence, does it happen for all cuts)?
It might also be related to the clipboard: If the lag appears, does it also appear if you copy instead of cutting.
Hm...I don't see a chance to really deliver some reproducable test settings.
I guess we leave this as "won't fix" for now....
Alright. Should you find out more, you can always come back.
OK, here is just a quick follow-up. I ramped my RAM on the machine from 5GB to 8GB and can't find this bug anymore using the same software setup as before.
I guess windows was using the pagefile all the time for RAM extension, which consequently lowered system performance that much, that I noticed those lags.
This is just an assumption together with what I observed though...
Hope this helps.
Keep up the good work!
Thanks for reporting back. Though I have not used Win8 myself so far, I would have thought that 4 GB should be sufficient. Anyway it's good to know that the amount of memory may play a role.
I'll change the status to closed.