rom/startup.lua has a whole host of completion helpers (completeMultipleChoice, etc...). However, these are not usable to people outside the program, which means anyone else who adds completions to programs has to copy and paste them.

It may be worth moving these into a helper module, which can be required by anyone.

A couple of things worth discussing first:

• I'd be inclined to put this under shell.completion or cc.shell.completion - thoughts? Basically, I don't want to fill up the top-level module namespace with ComputerCraft specific things, and it'd be good to establish a rule to follow for future modules.

• A lot of helpers are of the form if nIndex == 1 then return a(text) elseif nIndex == 2 then return b(text). It'd be nice if we could replace this with a function which just accepts a list of "argument completers"s, so you can do completing(a, b).

Having proper requireable module for dealing with completion would make lot of programs a bit smaller. And it would make it a bit more simple for users to add it to their programs while teaching them to require things.

• As it would be first module that would be added to the system i would say cc.shell.completion having 'cc' prefix would make a good separator for build in official modules that exist in /rom/modules/main/ and ones made by other players.

• As for your proposed completing(a , b) function looking from this line onward in startup for examples i only see only few places where it could be used without making interim functions for each index that just tail call prebuild function with all parameters it needs if nIndex == 1 then return fs.complete( sText, shell.dir(), true, false ) end would end up as completing(function(sText) return fs.complete( sText, shell.dir(), true, false ) end) for example.

as for your proposed completing(a , b) function looking from this line onward in startup for examples i only see only few places where it could be used without making interim functions

One thing I was thinking would be to allow writing completeMultipleChoice (and potentially other functions) in a more curried style - so you could have completing(completeMultipleChoice(tLabelOptions), completePeripheralName) or something.

But yes - I don't know if it'd be worth it or not. I think something to try out, and see if it ends up being any cleaner.

Just commenting to say that I agree with the idea of having a CC prefix for built in modules.

I can't comment on the other bits though.