Mudlet: Copy/paste of main text window stops working

Created on 22 Dec 2019  ·  24Comments  ·  Source: Mudlet/Mudlet

Brief summary of issue / Description of requested feature:

Mudlet 4.4.0 instead of crashing now copy/paste just doesn't work sometimes

  • i'm not sure exactly what causes this to start, but it feels like at some point copy/paste will just refuse to work anymore. cmd-c or right click copy, both will not work. copy as html works tho. which is interesting.

this is incredibly frustrating.

bug high

Most helpful comment

@njs50 @Ranfir I've discovered a way to fix this without having to restart your profile. Make an alias with this:

echo("\nJust fill up the line with random gibberish!")
echo("\nJust fill up the line with random gibberish!")
echo("\nJust fill up the line with random gibberish!")
---etc, up to 1000 lines of the above echo

Then hit your alias to send the 1000 lines of spam to your profile. One hit and you should be able to copy and paste again! I tried it with a 100 line alias and that wasn't enough, but 1000 lines did the trick.

All 24 comments

I am experiencing this issue on Windows 10. It will sporadically stop working, and then start working a few minutes later. Unclear on how to reproduce consistently, but happens frequently enough to be a major nuissance.

I am still seeing this issue under 4.5.1-de.

this is incredibly frustrating.

I can't agree more with this.

Confirmed that this issue still occurs in 4.6.2 on OSX. It's strange because it is profile specific as well. One profile will be able to copy and paste while another concurrently open profile will not be able to copy and paste.

It's tough to fix this because one can open up Mudlet and it's working fine, so how to find the problem then? A way to replicate the problem would advance this by heaps

fwiw, when it's broken the copy as html still works. maybe that might help narrow down where the issue is.

i also think it started around the time of this PR being merged: https://github.com/Mudlet/Mudlet/pull/3241 it fixed the crashing but then instead of crashing copy/paste stops working, so maybe something was not quite right there...

Hmm well we can test that theory, try the test build in https://github.com/Mudlet/Mudlet/pull/3688. Run Mudlet from the terminal - so in macOS it's inside the .app/Contents. It'll print a message when the check is not matching.

Noticed similar flaw on Win10 a few days ago.

Try the test build, run mudlet.exe and see if anything pops out in the terminal when the issue resurfaces.

Well, currently I am already running and trying the next version release candidate, so will do this later. Anyhow, it only happened once before (so that I noticed), and I was running Mudlet for quite a while at that point. Not sure how to replicate.

@njs50 @Ranfir I've discovered a way to fix this without having to restart your profile. Make an alias with this:

echo("\nJust fill up the line with random gibberish!")
echo("\nJust fill up the line with random gibberish!")
echo("\nJust fill up the line with random gibberish!")
---etc, up to 1000 lines of the above echo

Then hit your alias to send the 1000 lines of spam to your profile. One hit and you should be able to copy and paste again! I tried it with a 100 line alias and that wasn't enough, but 1000 lines did the trick.

For me, the bug didn't happen anymore in recent weeks, but we had the occasional player in Discord who reported similar. They seemed content with the above workaround, so this may help triangulate the bug.

In any case, instead of everybody putting 1000 lines of spam in their alias, you can use a lua loop:

 local repetitions = 1000
 local i = 1
 repeat
  echo("\nJust fill up the line with random gibberish!")
  i = i + 1
 until i > repetitions 

You can even experiment with the number of repetitions, maybe that will help even more? Currently 100 seems to few, and 1000 seems enough. Not sure, why and where it changes exactly.

:bulb: Um, IIRC the details of the current selection is stored in two QPoints TConsole::P_begin & P_end - however when (void) TBuffer::shrinkBuffer() kicks in to trim the oldest (lowest line numbers) from the start of the TBuffer's (std::deque<std::deque<TChar>>) buffer and (QStringList) lineBuffer and one or two other one-element-per-line containers: what steps are taken to adjust the y values of P_begin and P_end :question:

I've only noticed it happen after the buffer has gotten long enough to shrink. Additionally, when it's happening, it seems like it causes the highlight in the top and bottom buffer(when you've scrolled up in the console) to fall out of sync with each other. Making selections on the top and bottom seems to help get the copying functionality to work again, but I can't say it's entirely consistent because it doesn't happen often enough to test reliably.

it seems really odd the "copy as html" continues to work when the regular copy stops working. that seems to indicate maybe the selection isn't the problem but something that is in the selection?

The two of them use different algorithms I think. Which indicates that the simply copy one could learn a trick or two from copy to html.

copy as image also still copies the selection properly as well iirc

Is there a way to do the echo trick without filling my buffer with 1000 lines of garbage? I would like to try to get a workaround that does not include trashing a perfectly good gaming session that I also log.

Does clearWindow work?

looks like it just worked for me. i don't know if that was a coincidence. It looks suspiciously like copy/paste is going to continue working until stuff starts getting evicted from the end of my scrollback

i just repeated that again. copy/paste appeared good after doing clearWindow() until the buffer was full. as soon as it was full when i copied some text that was flying past it failed and stopped working. clearWindow fixed it again.

I as well have filled my game buffer until lines started to vanish at the top.
At that time, copy/paste still worked fine as expected.
How do you fill your buffer exactly?

I tried lowering the batch deletion number for my console buffer size down to 10, and while that does cause the side effect of strange text display when the batch delete happens, it seems to hasten the process of fixing the copy issue.

I as well have filled my game buffer until lines started to vanish at the top.
At that time, copy/paste still worked fine as expected.
How do you fill your buffer exactly?

I was testing it with a game running at the time. i filled most of it by going through a bunch of notes on a noteboard and when i noticed text was being deleted from the top of the buffer again i made a new selection.

There was defintely text coming in the entire time i was selecting to copy.

i was also definitely into the scroll back when i was copying. i.e I had dragged the selection far enough to get off the current page of text.

Using Ctrl-C (Copy) from the context menu:

  • (void) TTextEdit::slot_copySelectionToClipboard()
  • (QString) TTextEdit::getSelectedText(char newlineChar) - which uses the current values in (QPoint) TTextEdit::mPA & mpB and puts the text into the QApplication::clipboard()

Using Copy as HTML from the context menu:

  • (void) TTextEdit::slot_copySelectionToClipboardHTML() - uses (QPoint) TTextEdit::mDragStart and mDragSelectionEnd to SET TTextEdit::mPA & mpB as appropriate and then immediately uses the latter to copy the data of the TBuffer into the generated HTML.

It might be worth experimenting with copying the selection process from the latter to the former....

Was this page helpful?
0 / 5 - 0 ratings