Extension:Scribunto/Brainstorming

From Linux Web Expert

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 [[../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...
  • 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
  • [[../]] – 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.
Retrieved from "https://www.linuxwebexpert.com/wiki/index.php?title=Extension:Scribunto/Brainstorming&oldid=11194"