Felix S.

Finally committed as https://github.com/fstirlitz/luaparse/compare/fstirlitz:2b04739...fstirlitz:10666c7. Leaving out UTF-8 modes for the moment; I may add them later. I’m leaving this issue open until I make a decision, but either way it...

Pretty slim, unfortunately. It’s not that I don’t recognise this as useful; in fact, I did consider migrating the project to TypeScript at one point, but one of the reasons...

PUC Lua doesn't accept this code: ``` $ lua5.3 Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio > function 中文函数名(参数1,参数2) end stdin:1: expected near '' ``` ``` $ lua5.2 Lua 5.2.4...

Implemented in 71729404772a771e588a6c0ca2c70d3db7f9f254. Consider it unstable, however. I might still revisit the encoding issue.

I already wrote this is unnecessary. There's no need to check category codes at all; the LuaJIT parser doesn't work with Unicode characters anyway. The real issue is that luaparse...

> I read your post and I didn't try to help you, was just showing you I've done it and I'm able to. Well, good for you. But with respect...

I filed the encoding issue as #68. Another question that remains is whether to integrate this feature into the feature flags framework (i.e. the `features` object) and expose the latter...

Apparently Lua 5.4 will add this feature behind a compile-time flag: https://github.com/lua/lua/commit/e0ab13c62f2c1af0af955f173beb3ea6473e8064. Although it seems that unlike LuaJIT only (modern) UTF-8 names will be supported.

There's also [fatcat](https://github.com/Gregwar/fatcat). Though personally, I just use a quick and dirty tool I've written myself. (With an emphasis on quick and dirty.) Maybe it would have helped with #59…

~~Fields converted in this commit not are aligned at a 16-bit boundary, so it will make code not portable to architectures which disallow unaligned memory accesses.~~ Honestly, if anything, everything...