Extension:Scribunto/Brainstorming

Brainstorming!

 * add an alternative to such as  to run the code prioritized so that returned values can be substituted into pages. Example situation: you have a template with includeonly injecting an in  into a page. The code should not remain on the page to minimize the amount of text on the page (the result of the invoke is fewer characters than the invoke string; also, invoke strings make it more difficult for non-coder users to understand and modify). Instead of leaving the , it would be great if we could  to inject the returned value. A good explanation of how substs work now with  can be seen at ../Lua reference manual.
 * add mw.page.title/namespace and all other pseudo-templates so that coders can use them rather than in-code 'frame:preprocess("")' → even if it is coded the same in mw.* coders will not have to rewrite their code when it will be available in a proper way
 * add a more popular language like python.
 * some way (in debug mode) to check for trying-to-read-a-variable-that-was-never-declared-nor-initialized? This would help during coding to track-down typos in variable names that always work
 * allow in the Lua editor to use unix/linux copy/paste system (which is per default: selecting a part of text and then use middle-mouse-button to past it at pointer position). This system works fine when editing articles/templates, but in Lua editor only explicit ^C/^V works.
 * To accelerate templates, interpretation could be replaced by a pre compilation ? Perhaps, this needs to update the compilation each time any sub template or ParserFonctions are updated.
 * Simpler invoking : could become  for thousands of modules in hundreds of wiki.
 * Scribunto is not only about Lua, is it? Helder 14:10, 7 September 2012 (UTC)
 * Then we must distinguish Lua modules and others by the extensions foo.lua, foo.xxx which give longer names, or by the invoking way.
 * Also, Lua here is not exactly Lua, but nearer Lua Like which could become or.
 * In the 2 cases, or because the 2 reasons, the shortcut LL or L is usefull. --Rical (talk) 17:20, 7 September 2012 (UTC)
 * Re-evaluate use of templatelinks table to track module invocations
 * Feels kind of hackish; templatelinks table was never intended for this
 * Requires splitting every list of transcluded templates
 * Binary tracking (can't count invocations per page, e.g.)
 * Magic words... other breakage
 * Memory usage
 * Debugging tools
 * Track execution time
 * Track number of module invocations
 * Dedicated Special page? Special:LuaConsole or Special:Scribunto or something?
 * Style guide needed!
 * Split up reference manual into subpages (pagination!) and transclude onto a single page for single-page edition
 * Basic (side-by-side) comparison to ParserFunctions needed!
 * Explain how Module namespace fits into equation—it's an abstraction layer!
 * Link line number in error messages
 * Error messages are too confusing? &lt;eof&gt;?
 * CodeEditor tab key behavior...
 * It uses spaces instead of tabs for indentation
 * 39649 – CodeEditor extension's tab key behavior is slightly infuriating
 * Limit module invocation to Template namespace?
 * Trim lines that contain only spaces or tabs?
 * Module redirects?
 * Redirects and moves are both supported; only issue is rendering the redirect when &redirect=no is specified. This bug is mostly a sub-bug of the limiting syntax highlighting issue.
 * Tooltips for labeling/annotating code
 * Native capability for labeling/annotating lines of code? Unclear what level of benefit this would be.
 * Full comments fuck up the signal to noise ratio and make reading the code difficult. Tooltips work around this. Tooltips also suck without hover capability.
 * Tooltips could contain definitions of particular keywords/lines or they could contain plain English explanations of the code.
 * Track require calls in the templatelinks table?
 * Unicode + native functions such as string.len, string.reverse, etc.
 * "Script error" is not obviously a link
 * CSS to make it look like a button
 * Actual HTML submit button with some JS hijacking
 * Change link text to say "script error (click for details)" or something similarly obvious
 * When you file a bug, there's now a Lua option and a Scribunto option; as Scribunto becomes more popular, people will mis-file bugs
 * NOTE THAT SCRIBUNTO.WMFLABS.ORG IS USING A DIFFERENT VERSION OF SCRIBUNTO
 * Built-in modules can be syntax highlighted (e.g., ustring)?
 * GeSHi bug, I imagine
 * Better document how to dump functions from a Lua module
 * for name, func in pairs(string) do print (name) end
 * "How do I learn more about a Lua module?"
 * Does Lua have an equivalent to Python's help for its modules?
 * Autodocs?
 * Because lua replace templates, a module/Documentation page for each module, like for any template in any wiki.
 * Autodocs?
 * Documentation system of some kind... from the code?
 * Long doc comments increase signal-to-noise ratio; mountains of grey text... bleh
 * Versioning of modules???
 * How do you mitigate the "forking effect" when interfaces change irreversibly?
 * Allow variants in name?
 * Would allowing a user to specify the module version provide more stability or make everything awful?
 * Some sort of native Unicode support, as opposed to packing UTF-8 into Lua's native bytestrings, would probably be desirable.
 * There seems to currently be a  construct, à la Python, added into Scribunto's version of Lua.
 * However, a syntax addition like this would likely break syntax highlighters and other static analysis tools.
 * Also, this may end up making Scribunto Lua code snippets differ significantly from vanilla Lua, making it harder to share code and more formidable for beginners.
 * Perhaps make Unicode strings the default, and dispense with bytestrings altogether? They're not particularly useful in text processing, are they?
 * Perhaps make Unicode strings the default, and dispense with bytestrings altogether? They're not particularly useful in text processing, are they?

Documentation on MediaWiki.org is a mess

 * Lua – probably don't want to use this as the main title with subpages; too confusing to users
 * Scribunto – currently a redirect; probably want to use this as the main title with subpages (unique name, won't be as confusing to users)
 * Lua scripting – currently has a number of subpages
 * This page should probably be renamed to something like "Template scripting language rewrite" to get it out of the way; should be limited in scope to Wikimedia engineering project with finite duration
 * Move subpages elsewhere
 * Redirect "Lua scripting" elsewhere post-rename?
 * Add hatnote to renamed page pointing to useful pages
 * ../ – currently has technical subpages
 * Keep subpages where they are?

Further thoughts:
 * How do we separate Scribunto documentation from Wikimedia documentation about the use of Scribunto? Should we make a distinction?

Notes from MediaWiki core team meeting on October 29:

A few short term priorities, in no particular order:
 * git repo integration
 * MW interface
 * Unicode support (bug 39646)
 * UI design tweaks
 * Better debug interface