Unchecking 'wrap output at column number' in world prefs does not disable output window wrapping. The text continues to be wrapped at the value set by the numberpicker.
Auto-wrap also unchecked.
Auto-wrap also unchecked.
Can't disable output wrap
Posted by Smorly on Sat 09 Feb 2013 06:45 PM — 10 posts, 34,168 views.
That's actually not quite what that option means, and the option should be renamed to be more clear.
Increase the number instead.
Increase the number instead.
The maximum line length from the MUD exceeds 500 characters. I need to make it more than 500.
In this case I will suggest that you are probably wrong.
Disabling wrap entirely is unlikely to ever be the correct choice for usability. Set it to the width of your display so that you can actually read the game output.
Disabling wrap entirely is unlikely to ever be the correct choice for usability. Set it to the width of your display so that you can actually read the game output.
I'm capturing all window output to redirect to various other windows. Due to Python not being conveniently handed a table of colour styles, I have to capture that information myself. Here is my dilemma:
When a line is wrapped, the second argument of this function will not match any output lines.
Suggestions?
def ccopy(name, line, wildcards):
ln = world.GetLinesInBufferCount
while world.GetLineInfo(ln, 1) != line:
ln -= 1
if ln == 0:
world.Note('Error! Line not found!')
return
When a line is wrapped, the second argument of this function will not match any output lines.
Suggestions?
So I have everything else in place to do full colour line capture, except this.
It's unlikely that a player will encounter a line that is long enough to trigger this bug, but it's troubling to have to ship something with a known bug.
The script-side work-around to this is obviously to read how much of the line you got, and read lines forward, appending together the original string, but I'd prefer to run the leaner code. Also, I'm trying to avoid race conditions with the buffer cleanup, so the fewer instructions, the better. Unless MUSHclient guarantees atomicity of the output window while processing a trigger?
Maybe there's a way to do a raw capture, grabbing the line unmolested, ANSI intact?
It's unlikely that a player will encounter a line that is long enough to trigger this bug, but it's troubling to have to ship something with a known bug.
The script-side work-around to this is obviously to read how much of the line you got, and read lines forward, appending together the original string, but I'd prefer to run the leaner code. Also, I'm trying to avoid race conditions with the buffer cleanup, so the fewer instructions, the better. Unless MUSHclient guarantees atomicity of the output window while processing a trigger?
Maybe there's a way to do a raw capture, grabbing the line unmolested, ANSI intact?
When a trigger matches, it matches the entire line up to the newline. That is, the "line" may be more than one line in the output window.
If you used Lua, there is a 4th argument to the trigger match which is a table of style runs.
If you want to use Python, you are going to have to work backwards to reconstruct the "full" line.
You get use GetLineInfo to do this (read the comments in the help). Basically you read backwards checking the "newline" return (selector 3). That would give you the end of the previous line. Then step forwards one line. You now have the start of the current line. Then read forwards, assembling lines (and colour info) from GetStyleInfo.
OnPluginPacketReceived callback would do that, but that is rather fiddly.
If you used Lua, there is a 4th argument to the trigger match which is a table of style runs.
If you want to use Python, you are going to have to work backwards to reconstruct the "full" line.
You get use GetLineInfo to do this (read the comments in the help). Basically you read backwards checking the "newline" return (selector 3). That would give you the end of the previous line. Then step forwards one line. You now have the start of the current line. Then read forwards, assembling lines (and colour info) from GetStyleInfo.
Quote:
Maybe there's a way to do a raw capture, grabbing the line unmolested, ANSI intact?
Maybe there's a way to do a raw capture, grabbing the line unmolested, ANSI intact?
OnPluginPacketReceived callback would do that, but that is rather fiddly.
Right, so given that I have to do that (as I mentioned above), am I guaranteed atomicity of the output buffer while my trigger is processing?
If not, will there be a race condition to guard against, where the line numbers change in between capturing each line as the result of buffer trimming?
Would be nice if the 0th line was the most recent one, but I know that's not happening ;)
Alternately, could you make an option to disable output wrapping? Better yet, make the colour/style table available to external scripting languages?
Forgot to mention: I already am performing a full ANSI color/style copy to another window, this issue of output wrapping is the last remaining bug.
If not, will there be a race condition to guard against, where the line numbers change in between capturing each line as the result of buffer trimming?
Would be nice if the 0th line was the most recent one, but I know that's not happening ;)
Alternately, could you make an option to disable output wrapping? Better yet, make the colour/style table available to external scripting languages?
Forgot to mention: I already am performing a full ANSI color/style copy to another window, this issue of output wrapping is the last remaining bug.
There is no race condition. The trigger fires and handles the most recently received line before anything else is added.
Disabling output wrapping wouldn't be particularly useful for most people.
The method I described for obtaining the style information isn't that fiddly, the client does it itself to assemble the "full line of text" before calling a trigger (so it can pass down the full matching line).
Disabling output wrapping wouldn't be particularly useful for most people.
The method I described for obtaining the style information isn't that fiddly, the client does it itself to assemble the "full line of text" before calling a trigger (so it can pass down the full matching line).
Thanks, that answers it.