Originally Posted By: pishposh
(Because presumably he wouldn't waste time making a log viewer for showing logs in color yet which couldn't show them in color correctly, right?)


Sigh. The colours are displaying correctly. What you see in the window of your screenshot is the expected output for that line of text. Again, comparing what you see to your channel buffer is completely invalid and useless, because the log viewer is NOT a replacement for your channel buffer.

The problem here is not that "loadbuf has no awareness of the "alternate default line color" signaling method mIRC's logfiles employ" (I never stated that), it's that there is no such thing as an "alternate default line color". You're making this concept up.

As I've pointed out a few times now, mIRC is displaying the text in the file as it should display if it were a plaintext file. Like if it were your grandma's muffin recipes, or a text file or Yo Mama jokes. The "log file" viewed by the log file viewer doesn't even *need* to be a log file-- it could just as easily be your 3rd grade book report. There's no concept of "parsing as log file" here- it's just text. You claim to understand this, but you don't really.

The color code you're seeing at the starting column of some lines is not some magical "alternate line color" marker.. it's simply written by mIRC when running /savebuf on a window. Once it is written to the text file is becomes nothing more than a regular control code. mIRC does not have a "log file format", and does not write out enough information to .log files to be able to recreate them exactly as they were displayed in your window.

Specifically, mIRC can't differentiate between the following scripts:

Code:
on ^*:TEXT:*:#:echo 4 -t # $nick says $1- | haltdef


And:

Code:
on ^*:TEXT:*:#:echo # <ctrl+k>4 $+ $timestamp $nick says $1- | haltdef


(<ctrl+k> and <ctrl+o> are the control codes)

Both of these scripts will log as the following:

Code:
<ctrl+k>4[00:00] foo says hello <ctrl+o> world


However, the second script will show up in the log viewer exactly as it looks in the channel buffer-- that is, the ctrl+o WILL override the "line colour" in the case of script #2. mIRC, however, will still log them both the same, because there is no way to log it any other way. The only way to preserve information of a "default line color" (as passed in by /echo N ...) would be to create some alternate log format using XML or something more involved than a simple line-by-line text file. Until that is done, the only way to properly parse the text in the file is to not parse any codes as "default line colours".

Another way to solve this problem would be if mIRC did more than just put a <ctrl+k>N at the start of a line that had a specific line colour attached to it. It would have to also look for any ctrl+o or ctrl+k's in the line and insert a <ctrl+k>N to restart the colour if it was ever stopped midline. For instance, with the above script #1, the above text would have to be saved as:

Code:
<ctrl+k>4[00:00] foo says hello <ctrl+o><ctrl+k>4 world


Note that this still means the viewer would not need to change, because it is doing the right thing already (ie. the viewer is not buggy)-- the log writing would have to be improved. You can feel free to suggest that this be improved. Of course, this adds plenty of parsing complexities that don't really make it worth it and would probably slow down logging performance a fair bit. It would also bring in the issue of messing with the integrity of the original message, since you could no longer tell if the user added those control codes, or if they were added by mIRC. That might in fact be important for debugging. And it would of course not apply retroactively-- the logs mIRC already wrote with this old format would still display as you see it now (and that's how they should display).