Nitpicking that for the hell of it: reflowing like that would lose the time information of when the original lines came in! That's like the most important line data other than the actual line!
Oh yeah. I guess we'd also need to be able to fake timestamps somehow.
I am totally against it, by the by. It would kill the speed
That's ridiculous. It wouldn't have any effect on speed at all except for during the second that it takes to resize the window. You don't need to do anything special when not resizing, so nothing gets slowed down.
and second, telnet was never something meant to...
Some games have ASCII maps, others use simply ASCII art to put down tables or other framed information. Once you start reflowing, that stuff starts breaking into total ugliness...
However many, many MUDs assume 80 characters (who lists, scores, maps, even room descriptions)...
Why do you two keep saying that MUDs assume 80 characters? MUDs don't assume 80 characters. They assume AT LEAST 80 characters. Aardwolf channel output very regularly extends beyond your mythical 80 character boundary. Imagine that the user isn't a complete idiot and wants to resize between 90 and 85 characters instead of between 80 and 10.
Another issue is the buffer size. Say you had the buffer full (to whatever your limit was, say 10,000 lines). Then you make the borders narrower, so it becomes 12,000 lines. Do 2,000 lines get discarded? What if you wrap back to a wider width? Do they somehow magically come back?
I think that's a negligible concern. Considering that resizing the main output is unlikely to be a common event, I think it's ok for the user to in the absolute worst case lose the very oldest lines in the buffer, which would be no different than if the user had received more lines. I believe this is what the chat capture plugin does.
One viable option for MUD plugin developers is to consider actually making everything a miniwindow. That is, omit absolutely everything from output, and funnel it into different streams
I think that's difficult for a number of reasons. The first one I can think of is that you can't easily select arbitrary text in a miniwindow, because miniwindows don't really have text. I suppose it'd be an interesting exercise to add that to the chat capture plugin, though. Hmm...
Selecting text that runs off the screen would be tricky...
Then the behaviour of the default output window becomes irrelevant.
An interesting suggestion. Completely replace the main display mechanism with one home-grown in Lua, which probably wouldn't work very well without adding significantly more complicated interaction behaviors for selecting text to the output scripts already available.
Or have the ability to fake some of the metadata in the main output window, which doesn't require most of the extra work that would otherwise be necessary to get up to the same level of functionality that the main window already has.
Note that I'm not actually dismissing that idea. I think it's definitely possible to implement arbitrary text selection in a miniwindow, and when I do (or someone else does), I'd like to add it to the chat capture plugin along with line timestamps, and rewrappable hyperlinks, and bookmarks, and whatever else isn't in there yet. But it isn't in there yet, and if I had to choose at this moment which would be less work to add, I have to go with new methods for faking metadata in the main output.