-
Oswald Buddenhagen authored
use local8bit instead of latin1 resp. 8bit-passthrough, after all. the situation was as follows: - if the pro files and file names were all ascii, everything just worked - if either contained non-ascii: - on unix, the evaluator would work as long as the file content encoding matched the file name encoding, and the ui would work as long as the file name encoding was latin1 (i.e., on no modern system) - on windows, both would work only if the ansi code page was latin1/cp1252 (i.e., on western systems) i.e., even in the low-level evaluator, only native latin1 systems with actual latin1 files worked consistently. given this situation, it makes little sense to make an encoding adapter between the evaluator and the ui as originally planned. instead, take the easy way out and use local8bit - this continues to work for native latin1 systems+files in the backend, and makes the ui work for everything the backend groks and some more. Reviewed-by: dt Task-number: QTCREATORBUG-930
1dc99e8f