Extension talk:Scribunto/Lua reference manual

Re : "If named arguments to #invoke are specified, for example " is not a full sentence, so "Then" cannot be with a capital.--Patrick1 (talk) 11:44, 30 August 2012 (UTC)

pattern in which function ?
"the empty capture captures the current string position (a number)." Perhaps a note about "pattern " could be usefull in these functions ? --Rical (talk) 11:51, 23 December 2012 (UTC)
 * string.find (s, pattern [, init [, plain]])
 * string.gmatch (s, pattern)
 * string.gsub (s, pattern, repl [, n])
 * string.match (s, pattern [, init])

What's available on WMF projects?
It seems like a lot of the libraries mentioned in this manual are not available on test2.WP, which I assume means that they won't be available on the WMF projects that Scribunto is about to be deployed on? (For example, mw.language, mw.site, mw.uri, and mw.ustring all appear to be missing.) Could this manual be edited to make clear which modules are available in what Scribunto versions? —Ruakh TALK 05:02, 18 February 2013 (UTC)
 * mw.ustring is available now. Here's a little test: User:Amire80/Scribunto. --Amir E. Aharoni (talk) 04:20, 19 February 2013 (UTC)
 * The hard part about that is idenfitying the versions. There isn't a 1:1 relationship between the version of MediaWiki and the version of Scribunto; for example, until the deploy 9 hours ago wmf9 had a relatively old version, which was upgraded to the newest. This could potentially be done again if warranted, rather than waiting for wmf11 to get the latest updates. Anomie (talk) 13:21, 19 February 2013 (UTC)
 * This is a point of confusion, though. As of right now there is no way to know for sure which functions are available on any given wiki, except by writing test code to see if it works or triggers a script error. At the very least, the documentation should specify the first Scribunto version for which each function became/will become available. CodeCat (talk) 22:19, 5 March 2013 (UTC)
 * Define "Scribunto version"; saying bit32 is first available in 5e548e769a464e3223cd52ffa0f819f6bf1c9924 doesn't help a whole lot. Anomie (talk) 02:34, 7 March 2013 (UTC)
 * It is possible to test existence of stuff by performing ~=nil tests. It is not very nice but it works (I use it in my test module to check functions that appears). Maybe we could write a "What's available module" that shows what is present or not? Hexasoft (talk) 08:59, 7 March 2013 (UTC)

(u)string patterns and PCRE
I believe, for people who know PCRE a special explanation of differences should be written, except that one must use  instead of  this will allow me, e.g., to do things like  or to create a table with some members, some of which may be functions, and construct new "instances" of this table by calling "new" and the table:

peace - קיפודנחש (talk) 18:07, 11 March 2013 (UTC)
 * The usual idiom seems to be to use  rather than  . Also, due to Scribunto's sandboxing, it is not possible for a  d library such as libraryUtils to add global functions as proposed here; it would wind up as , at which point you may as well use the normal idiom. BJorsch (WMF) (talk) 13:19, 12 March 2013 (UTC)

mw.text.unstrip
Hello, as far as I understand the doc, the  function will allow to "unstrip" incoming strings that include tags such as nowiki. It is fine (I filled the bugreport) because it will allow to read the full content of any kind of parameters. My question: does using  on the unstrip string will produce the same original string? Also, to be sure: unstrip will returns a copy, not modify the original string?

Regards, Hexasoft (talk) 19:31, 11 March 2013 (UTC)
 * No,  on the unstripped string will expand any wikitext in that string. Even if you were to add back the correct extension tag (e.g. wrap the string in , or , or whatever), the result still might not be the same. For example,   might return , but then unstripping might result in  : the HTML for the superscripted footnote, which isn't even valid for return from the Lua module since  is not allowed in wikitext. It's even possible that the text hidden behind   is something completely unexpected such as serialized PHP data, as it may be that the extension is intending to do postprocessing in a ParserAfterParse hook or the like.
 * Yes,  does not modify the original string. Strings in Lua are immutable and primitive values are passed by value, so it is not possible to modify an input string in a normal function call (you can modify the keys/values in an input table, of course). BJorsch (WMF) (talk) 13:38, 12 March 2013 (UTC)