[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.technology.dltk] Re: Encoding issues 
Hi Alex,

Since 3.4 (Ganymede) the default encoding is inherited from the resource (project) associated with the launch configuration. If encoding is not specified for the project - encoding configured for the workspace or system default encoding is used.

So for the Run configurations you should specify encoding for the project - and it should work ok.

It's important to notice that the first setting to verify however is the encoding of the file itself, prior to project encoding, because you could need to have a project with files on multiple encodings. In fact it's possible to do, you just have to set encodings at file level instead of project or workbench level.

But regardless of this, the problem remains. I set project's encoding manually to UTF-8, and even files being really UTF-8, their outputs aren't. I've noticed that the Run configuration is generated with ISO-8859-1, even if the project is manually set to UTF-8.

I've got to change console's output for the Run configuration on an Europa on another machine. But still, you need to do this manually instead of the software getting it from file/project/workbench.

Maybe you're not reproducing this problem because your workspace is set to UTF-8, but I'm on Windows which doesn't use UTF-8 by default, but Cp 1252 (I guess this maps to ISO-8859-1). Therefore your output woudn't change encoding.



I can't reproduce this issue.

I also couldn't do it on another machine. I'm gonna try to reinstall DLTK again at home and see how it goes :)



3) Mainly, Java project wether are UTF-8 or ISO-8859-1, for example, automatically gives us output according to the project encoding, but Ruby project doesn't. For example, my UTF-8 project has its console's output as ISO-8859-1 (puts "ã"-like stuff changes into a character mess).

As a workaround I'll have to change EACH of my files to ISO-8859-1 (I use notepad++ for that). Please, correct these bugs!!!

As I mentioned above, this is the remaining problem that persists even on a clean install on another machine. On this another machine at least I can change encoding for the specific run configuration, but we shoudn't need to do this.

I'm using Windows XP Pro. Regards.