Jackmcbarn wrote:
Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised.
As long as false positives are low, this is probably fine. It'd be nice to get rid of the checkbox as it's user interface clutter.
That said, a hard block is still pretty potent... I wonder whether simply warning the user and auto-categorizing the pages as likely broken on page save would be adequate.
MZMcBride
There are no false positives at all, since it tests it by actually loading it into Lua.
I think a total disallow is warranted because letting the page be saved with such an error means that the entire module is 100% useless (and will break every page that uses it) until someone fixes it.
Jackmcbarn
On Mon, Sep 29, 2014 at 9:53 PM, MZMcBride z@mzmcbride.com wrote:
Jackmcbarn wrote:
Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised.
As long as false positives are low, this is probably fine. It'd be nice to get rid of the checkbox as it's user interface clutter.
That said, a hard block is still pretty potent... I wonder whether simply warning the user and auto-categorizing the pages as likely broken on page save would be adequate.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Jackmcbarn wrote:
There are no false positives at all, since it tests it by actually loading it into Lua.
Does the checkbox currently only allow overriding the type of error that would completely prevent execution of a module? I encounter a lot of code linters and syntax highlighters that mess up or get confused. It's difficult for me to understand what exactly "with errors" means here.
I don't know Lua well enough to use it as an example, but as James mentioned CSS, using the example of ".foo { -moz-colour: red;", to me there's probably a distinction to be made between the invalid "-moz-colour" property and the lack of a "}". Though perhaps certain clients wouldn't mind either, which brings us back to the meaning of error.
I think a total disallow is warranted because letting the page be saved with such an error means that the entire module is 100% useless (and will break every page that uses it) until someone fixes it.
This kind of assumes a bad scenario (breaking pages), which doesn't really apply to making a new module or improving an existing module in a sandbox page. For me, it doesn't seem very difficult to envision a scenario in which not being able to save currently broken code would be annoying, though it's quite possible my concern about this is simply overblown.
MZMcBride
wikitech-l@lists.wikimedia.org