Skip to content
This repository has been archived by the owner on Aug 7, 2023. It is now read-only.

Set the file encoding correctly #112

Closed
wants to merge 1 commit into from
Closed

Set the file encoding correctly #112

wants to merge 1 commit into from

Conversation

wdspkr
Copy link

@wdspkr wdspkr commented Mar 21, 2017

This fixes end-of-input-errors that occur because of utf-8 characters in method arguments, as described here: #103 (comment)

This fixes end-of-input-errors that occur because of utf-8 characters in method arguments
@Arcanemagus
Copy link
Member

Arcanemagus commented Mar 21, 2017

What version of Ruby are you on, and what OS? The change this PR makes breaks setting the encoding properly on Windows at least, and doesn't match the documentation.

image
image

@Arcanemagus
Copy link
Member

The fact that every single CI build failed also doesn't speak well for this being a good PR 😛.

@wdspkr
Copy link
Author

wdspkr commented Mar 23, 2017

So, this was the first try to do the obvious thing. But I guess we have to dig a little deeper.
The thing is, that in MacOS (Sierra) the commandline options are set differently. Here comes an excerpt of the ruby manpage in MacOS for ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]:

     -E external[:internal]
     --encoding external[:internal]
                    Specifies the default value(s) for external encodings and internal encoding. Values should be separated with colon (:).

                    You can omit the one for internal encodings, then the value (Encoding.default_internal) will be nil.

     --external-encoding=encoding
     --internal-encoding=encoding
                    Specify the default external or internal character encoding

Note the space between the -E flag and the encoding. 😞
But my change also stops linter-ruby from working.

I tried around a little more, can't replicate the wrong behaviour in the test and might just refrain to always starting atom from the command line (as the encoding is set then correctly by the environment).

@wdspkr wdspkr closed this Mar 23, 2017
@Arcanemagus
Copy link
Member

Ah ha! It looks like the --external-encoding=encoding and --internal-encoding=encoding options are the same, and the -Eex (-E ex) option is just an alias to setting both to the specified value. So if we move to specifying them individually it should work everywhere!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants