What would break if we make conv_text() a null operation?

[sfeam (E. Merritt) <eam...@gm...>]

(NB: The example below won't make much sense if whatever program
 you are using to read this doesn't handle UTF-8 encoding)

Currently gnuplot+readline reads strings from the input stream 
without regard to what encoding they are in.  They are simply
passed through to the various plotting commands as-is.
It's up to you to give the output terminal a proper encoding and font.
But the "show" and "save" commands convert all non-ascii 
strings to a series of escaped octal bytes, which makes them
non-readable by mere humans.

I find the following really annoying:
gnuplot> set label 1 "Hélàs"
gnuplot> set label 2 "β ≦ ξ"
gnuplot> show label
         label 1 "H\303\251l\303\240s" at (0, 0, 0) left
         label 2 "\316\262 \342\211\246 \316\276" at (0, 0, 0) left

The same annoying thing happens if I do a "save";
the file that is created obscures the labels, titles, 
string variables, etc by replacing all non-ascii characters
with byte-by-byte octal representations.

Was there originally a good reason for this?
What would break if the routine conv_text() became a null operation?
  conv_text(const char *s) { return s; }

[1] I realize that if you save a file on a UTF-8 system and read
it back on some non-UTF system the contents of the string will
not make sense.  But they won't make any sense in their octal
representation either, so I can't see how it helps any.

[2] OK, I can see the rationale for escaping <tab>, <return>,
<linefeed>, and possibly <doublequote> in the output from "show" and "save".
But those are about the only exceptions I can think of.

[3] If getting rid of conv_text() altogether is too radical,
how about skipping it only if the current encoding is UTF-8?

	Ethan