Doomsday Engine

I agree this is a legitimate problem, however I have some thoughts about the appropriate way to handle this.

It is certainly true that interactive console output should be treated differently, however there is no need to bypass the usual logging mechanism. For every thread that submits log entries, there is a thread-specific Log object that maintains the "log section" context information (see LOG_AS macro). When executing a console command via the prompt widget, this thread-specific state should be used to flag all log entries as "interactive" — the reasoning being, any output generated as a result of an interactive command being executed should be shown to the user.

Another aspect to consider is that in a multiuser setup, where you have more than one client (i.e., shell) connected to a server, the interactive output of each client should not be seen by any other client. Currently the facilities for this exist only in partial form, for actual Shell users, but because the interactive output is not segregated, all command output is seen by all connected Shell users no matter who issues the commands. This could also be solved with thread-specific Log state, so that when executing interactive commands issued by a specific shell user, those would only be ultimately sent to the issuer.

Note that the current console backend (in libdoomsday) is considered obsolete and will be replaced with a Doomsday Script based solution. Also in the future, all interactive console sessions should be handled with libshell classes so there's no functional difference when accessing the console from the Shell utility or via the client itself.

I'm marking this issue as done because the basic mechanism has been implemented. Individual console commands whose output hasn't been updated to use SCR should still be updated later.