Bug: line breaks added when copying text

[Caled]

H:4557|5071 B:100% Exp:28 [kcsdb eb] [0] (rmhstfe)
You are surrounded by a shining corona of blinding light as your soul is transformed by metamorphosis.
Images of cold, unseen lands drift before your mind's eye as the mysterious spirit of the Icewyrm dwells
within your uneasy soul.
H:4557|4991 B:100% Exp:28 [kcsdb eb] [0] (rmhstfe)

The lines marked green are actually one single line received from my mud. There is no server side wrapping done - mudlet does it. So I copy/paste the whole green section to a trigger pattern, and select "exact match".

The trigger never fires. So I go back to the trigger pattern, place the cursor exactly at the end of "dwells" and delete the space. I then hit the space bar a second time, save the pattern, and from here on the trigger works as expected.

It seems that when I copy soft line wraps, hard line breaks are added to what I have copied. This is even noticed above, where I have copied the lines to this forum. The exact same line break is preserved in the above quote, when in fact it should be a single line with its wrapping (if any) decided by my browser display.

[Heiko]

This behaviour is indeed intentional and I don't have a good idea how to add a feature that would get you what you are after. For the time being you'll have to manually edit the linebreaks. What I could add is a copy-as-one-line sort of menu action. This wouldn't tell hard or soft linebreak apart, however, as there is no way to do this as Mudlet doesn't use linebreaks at all internally to maximize speed.

[Caled]

Might I ask why this is intentional? I can't see it as ever being useful.

If I copy what is a single line, surely it should paste as a single line?

[Vadi]

Copy & pasting a wrapped tell removes the pain of deleting the linebreaks manually is one example.

[Heiko]

Might I ask why this is intentional? I can't see it as ever being useful.

If I copy what is a single line, surely it should paste as a single line?

It's intentional as it is one of the consequences of underlying design decisions in Mudlet - and it's also one of the reasons for Mudlet's high speed. Without getting too much into the technical details: Mudlet recieves a line of text from the MUD and writes it into the buffer as a single line. This line is then processed by the trigger unit and broken down in lines (e.g. if you have echos with lots of \n etc.) and wrapped. After this point a line in the buffer is just a line in the buffer and there is no more information as to wheather it's a soft line break or a hard line break. Consequently, when you highlight a series of lines Mudlet simply does not know if they are individual lines or wrapped lines - they are just the lines you see on the screen. The same goes for buffer manipulation outside of the current trigger line. If you move the cursor a couple of lines up in the buffer and select a line in the buffer in order to do something with it, the line you select will represent the line you see on the screen unlike in the context of the current trigger line where a line of text may in reality correspond to many lines after it has been wrapped. The design goals for this were both efficiency and usability. I had to make choices and I opted for speed and efficiency and scriptability. Of course I could attach information about soft and hard line breaks to each line and thus get what you are looking for, but this cannot be done easily and I would have to run test series on how much performance would be affected by this kind of feature. This would definitely be a feature for after our stable release. The paste as a single line idea I've alluded to above would be doable, but it wouldn't be exactly what you want.

However, there is a simple workaround to get what you want: For most cases the debug console will be a good enough tool as it quotes verbatim what line is currently being processed in the trigger engine at the moment. Thus you can copy and paste the original line from the MUD from the debug console. If you use the split screen mode before text selection there will be no more issues that new arriving text will highlight the entire screen.

[Caled]

Fair enough, and thank you for the explanation.