sile
sile copied to clipboard
Logic bug in languages/unicode
I have no idea what this bit of code was ever supposed to do. It's obviously been broken for a very long time.
https://github.com/sile-typesetter/sile/blob/69cfffb48898b26f65d786411f930244306f386f/languages/unicode.lua#L72-L80
I traced it back far enough in history to know my recent refactoring isn't the problem, this has had several kinds of logic issues for a long time. The variable scope is so wrong that Lua would never pass the value anyway, and even if it did the next if statement would obliterate it. I've hacked in a guess to keep the linter happy in #682 (143a3cc), but there is probably still a logic bug here. If not we need some way to test this to prove it breaks when the code is changed.
Oh yes. I was working on this yesterday but then my test rig wasn't working so I got distracted with #688 instead. Basically they were all locals originally but I thought it would be useful for subclassers to make them instance variables. I want to take another look, but now I have other stupid things happening to deal with. (luarocks dying with File already exists
errors on files it only just copied)
You're right about the concept of instance variables. In spite of the way we bill SILE I'm noticing that there is actually a lot of stuff that could never by touched by and end user. Some of it they would be unlikely to want to, but some interesting parts would actually be really hard to tweak.
I'm gradually swapping out the way even core parts are loaded to be more modular, themselves instances of classes that can be tweaked without needing to replace the entire code base for the module.
Sorry I don't know what's up with your luarocks
, but if you run across anything that needs fixing for packaging purposes let me know.
Well, I dealt with the luarocks issue with an upgrade.
When I'm talking about subclassers here, I don't mean end users, but core developers who are using the unicode nodeMaker as a superclass to implement their own linguistic tokenizers. They need to have access to the last token type to decide whether or not to emit a token.
cf. #687