None of these are actually bugs. All of your reports seem to stem from your lack of understanding of what the log viewer is. The log viewer is nothing but a Notepad.exe with control code support. It does not specially handle lines-- it does not understand timestamps, it does not understand wrapping, etc. It is just a custom window that is /loadbuf'd with the contents of a .log file. You should be comparing the behaviour to a custom window, not to the original channel buffer.
(1) A default window behaviour is not a bug. Given the functionality of the log window, a desktop window makes sense-- "on top" might not be a sensible default *to you*, but that does not make it a bug.
(1b) Similar to ^. This is not a bug. The log viewer is a desktop window, period. This is intentional.
(2) This is not a bug. Again, you are loading/viewing a text file, you are not reloading the text into a channel buffer. The log viewer is just a simple "notepad" style log file viewer, it treats everything as regular plain text.
(3) This is how ctrl+o works, it is not a bug. //echo -a <ctrl+k>4hello <ctrl+o> world will get you the same result.
(4) Wrapping behaves as it does in any custom window without using default echo switches: //window @test | echo @test $str(x x, 100)
(5) The log file dialog is not remembered at all here, regardless of how you close it. Open the dialog, drag it over to the right side of your screen and close it any way you want. The next time it opens it will be in its default location again. This seems intentional to me, and not a bug. Most option/setting dialogs are not remembered anyway, so I'd be surprised if this dialog was.
(6) Again, the log viewer is
a custom window. It behaves as a custom window, including font selection. You cannot save fonts for any custom window: /window @test, and look at the font dialog. This isn't a bug.
(7) Again, custom window, so it behaves like one and inherits all of the functionality of a custom window, including logging.
(8) I can confirm this, but minor flickering is fairly normal when things open and close
To summarize: all of the log viewer functionality is equivalent to the following script:
//window -dk0 @logviewer | loadbuf @logviewer FILE.LOG
Therefore, the viewer is functioning as intended. Perhaps you were intending the viewer to be a more complete recreation of your channel buffer, but this is not the case. In the future, that might happen-- but that is not what it is currently doing. Khaled might take note of this post for improvements to the log viewer, though he probably already knows how basic it is, and I don't think he ever intended it to be a full log viewer implementation (it was only added as a replacement to running notepad.exe as was done in previous versions).
