Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use Unicode characters in method names #16

Closed
dram opened this issue May 2, 2022 · 5 comments
Closed

Unable to use Unicode characters in method names #16

dram opened this issue May 2, 2022 · 5 comments

Comments

@dram
Copy link

dram commented May 2, 2022

In Squeak 6.0 alpha, when I try to include Unicode characters in method name, following "Note" message will be popped up, and the name is disrupted after save.

There may be a problem with your sources file!

The source code for every method should (usually) start with the method selector but this is not the case with this method! You may proceed with caution but it is recommended that you get a new source file.

This can happen if you download the "SqueakV50.sources" file, or the ".changes" file you use, as TEXT. It must be transfered in BINARY mode, even if it looks like a text file, to preserve the CR line ends.

Mac users: This may have been caused by Stuffit Expander. To prevent the files above to be converted to Mac line ends when they are expanded, do this: Start the program, then from Preferences... in the File menu, choose the Cross Platform panel, then select "Never" and press OK. Then expand the compressed archive again.

(Occasionally, the source code for a method may legitimately start with a non-alphabetic character -- for example, Behavior
method #formalHeaderPartsFor:. In such rare cases, you can happily disregard this warning.)

@dram
Copy link
Author

dram commented May 2, 2022

Seems that even unicode characters in comment is not accepted, e.g.:

test
	"测试"

@dram
Copy link
Author

dram commented May 2, 2022

After some more investigation, I found that code written to .changes file is correctly encoded, so the problem is related to reading code back from .changes file.

For a quick test, I add theFile converter: UTF8TextConverter new before nextChunkText call in RemoteString>>text, the error does not occur anymore. Of course, there must be some other place which is better to do converter initialization.

@dram
Copy link
Author

dram commented May 3, 2022

The root cause of this issue: although converter of SourceFiles is correctly configured, but CurrentReadOnlySourceFiles is initialized based on SourceFiles using StandardFileStream>>readOnlyCopy, which does not copy converter configuration.

I think one way to fix this problem is to override readOnlyCopy in MultiByteFileStream, e.g.:

readOnlyCopy
	|copy|
	copy := super readOnlyCopy.
	converter ifNotNil: [copy converter: converter].
	^ copy.

@dram
Copy link
Author

dram commented May 3, 2022

@marceltaeumel
Copy link
Member

Merged. Thanks!!

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

No branches or pull requests

2 participants