Skip to content
Snippets Groups Projects
Commit 1dc99e8f authored by Oswald Buddenhagen's avatar Oswald Buddenhagen
Browse files

try to sort out the filename encoding mess

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
parent 6a6e0091
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment