Originally Posted By: argv0
You will see that it stops coloring both lines. This is the behaviour you should be expecting.

Again, the window is simply reloading lines of plain text. There is no difference between a control code at column 1 or column N, because they are just colour codes being applied to text. The log viewer has no understanding of the column difference because it has no understanding of a "log format"-- it's just loading plain text that happens to have control codes. In this case, the files it loads happen to be log files, but there's no such requirement. I'm not sure how I can make this any more clear.

And I'm not sure how I can make it any more clear than this:



1) CTRL-O in both the topic and action lines is broken in /logview but not in the channel window
2) CTRL-O only works properly in both windows on the line that features the red text.

All you seem to have made apparent in your response to me is that the origin of this bug lies in how loadbuf reads log files. That's fine, but even then, it's still a bug by virtue of the fact that loadbuf, then, isn't taking account of the rules of mIRC's logfile coloring system -- where if the first thing (excluding a timecode) mIRC sees on a line is a color code, then that color code shall not only affect any text following it but become the line's default color (the color CTRL-O produces on that line).

Which technically means this bug goes beyond /logview and affects any custom window /loadbuf loads color-coded logfiles into.

Please understand: I understand what your point technically is -- that loadbuf has no awareness of the "alternate default line color" signaling method mIRC's logfiles employ. My point however is that mIRC's author gave loadbuf the obligation to understand that signaling by virtue of choosing it to be what fills /logview windows with logfile text. (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?) And the very fact he overlooked modding /loadbuf to understand that signaling ... that oversight itself ... is a bug.

Quote:
(5) I looked at this behaviour again. It's popping up over your mouse (horizontally)-- it's not remembering a specific position. The only reason you're reproducing this is because you aren't moving your mouse. The popping up over your mouse thing is definitely intentional.

Ah, very well. I would never have noticed that. (5) is in deed obviously no bug then.

Quote:
Regarding your gripe about expectations: mIRC had no log viewer until ~7.11 (in 6.35 and earlier it was notepad.exe). Most users don't really have any specific expectations about the behaviour of a log viewer in mIRC, since it previously had no such functionality, so it really shouldn't throw anybody off. Regardless, the behaviour of a log viewer should not be compared to the regular channel buffer anyway, which is what you're doing. a "LOG VIEWER" is something that views text (go download any "log viewer" application and you'll see the same thing)-- it is not meant to accurately recreate your buffer. Colours, timestamps, etc., are simply displayed as logged in the file, and have no more special meaning as they did in your session. The log viewer is simply showing you the text that was written to the log-- exactly as it was written to the log. This is what anybody should expect a log viewer to display. I don't see any of this as "broken" even without the custom window script functionality. My expectation of a log viewer is just what Khaled implemented it as: notepad with control code parsing. I would expect this from a log viewer in mIRC just as I would expect this from a log viewer in MSN, or a log viewer in any other program that logs my interactions.

You're making this an issue of users' "expectations about the behaviour of a log viewer in mIRC", when I brought up (1), (1b), (2), and (6) in the context of their expectations of text windows in mIRC. And as for (3), I would think the expectation would be that colors not appear broken in /logview compared to how they originally appeared while chatting live. If logs reloaded in channel windows can appear exactly as they were colored while chatting live, there's no reason they shouldn't in /logview. If they are colored differently in /logview windows than they were colored while chatting live, that's what your average person (me) would submit as a "bug report" ... regardless of any the hair-splitting semantics pertaining to the ultimate cause and nature of it.