[erlang-questions] erlang-questions Digest, Vol 24, Issue 20

[Andrew Thompson]

On Mon, May 04, 2009 at 08:17:45PM -0600, John Haugeland wrote:
> There are good reasons for this behavior.  Remember that this is a realtime
> protocol translation language, that it needs to be binary safe everywhere,
> and that it expects to dump horrible crashes to the console.  As such, the
> ability to print binary safely to the console and expect character output
> rather than interpreted output is important.
> 

If you know you're going to be dumping binary data to the console then, 
yes, I guess interpreting those escape codes is bad, but completely
removing your ability to use them at all? In some ways that's even worse
because when you *do* need them they're not there. And even if I *know* I
won't be dumping large amounts of binary to the console (or if I do I
don't care if they escape codes get interpreted), I'm still stuck with
the shell nursemaiding me. In addition, it could be argued that other
systems have the same concerns about dumping binary data, but I haven't
run across another one that eats my escape codes with no appeal.

> It is my opinion that it's important for you to ask yourself a question: do
> you want color and console control, or do you want specifically ANSI/VT
> codes?  If you just want color and console control, why stick to ANSI/VT
> codes, or indeed even formatting in-datastream?  They're limiting,
> inelegant, they make ugly code, they're not particularly pervasive these
> days, and they introduce significant problems for a language that wants
> binary safe dump to console.
> 

I don't see how exactly you propose to control an xterm with anything
but ANSI codes. As for being pervasive, I'm not aware of a terminal
emulator or a console in mainstream use that does not provide some form
of ANSI code handling (the xterm shipped with IRIX/Solaris is lacking,
but there's still some basic support). Also, I don't see the alternative
without becoming tied to some particular terminal emulator, as there's
no widespread alternative standard I'm aware of.

> How would you feel about the pen mechanism as described earlier, by
> contrast?  It would have the advantage of not affecting existing software,
> retaining the power to dump raw data to console without fear, would not
> limit you to what ANSI can do, and would end up with far more
> readable/maintainable code; at the same time it would not inject control
> codes into non-parsing interfaces, potentially breaking parsed upstream
> pipes and logging mechanisms.

I couldn't find this "pen" mechanism you mentioned earlier in the thread
so I can't really comment. I'll go try to find it again, but I still
don't understand how you propose to provide an alternative to ANSI
escape codes without patching every terminal emulator in common use.

Andrew