Extension:Scribunto/Brainstorming

Brainstorming!

• add an alternative to {{#invoke:}} such as {{#preparseinvoke:}} 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 {{#invoke}} 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 {{#invoke}}, it would be great if we could {{subst:{{#preparseinvoke:}}}} to inject the returned value. A good explanation of how substs work now with {{#invoke:}} can be seen at Extension:Scribunto/Lua reference manual#Returning text.
• add mw.page.title/namespace and all other pseudo-templates so that coders can use them rather than in-code 'frame:preprocess("Scribunto/Brainstorming")' → 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 : {{#invoke:}} could become {{#L:}} 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 {{#LL:}} or {{#L:}}.
    • 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? <eof>?
• CodeEditor tab key behavior...
  • It uses spaces instead of tabs for indentation
  • bugzilla: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???
  • {{#invoke: rev_id}}
  • 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 u"" 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?

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
• Extension:Scribunto – 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

See also

...as well as an unofficial deployment priorities page: Deployment priorities.

• We use Lua a reciprocation page between Lua developers.