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

Brainstorming!

Documentation on MediaWiki.org is a mess

See also