WORLDEDIT-2874 - Reported by Eaglebird

I realized a few moments ago that //replace, or worldedit itself, does not support multiple block specifications for the "" of the replacement. I discovered this when my pile of diamond blocks and pile of emerald blocks became intermingled when I selected them and tried to switch them using //replace diamond_block,emerald_block emerald_block,diamond_block.

Logically, replace the first block of the target with the first block of the payload, second block with second block, third with third, etc. so that multiple replacements can be done in a selection at once. This might allow users to build their homes out of any material and change the theme or look with a simple selection and replacement.

Syntax could be similar to the current syntax, "//replace <from-block(s)> <to-block(s)>", "//replace iron_block,diamond_block,50 gold_block,iron_block,glowstone", and if they don't match up as singles or a list, show the player an error.

If we implement this, I propose shifting the syntax to a new command -- I don't think this is very compatible with traditional masks/patterns. Perhaps something like //translate (short: //tr, //trans), which takes mask and pattern lists. We can even have it work more like Unix tr, with -d delete modes or -c complement.

I think //swap would be a better name, translate usually suggest spacial translation.

I suggest making swapping pairs, instead of 2 indexed lists, It's more user friendly and less prone to errors. I hate having to count and align arguments.

//swap dirt>sand wood>stone water>lava

I wonder if a straight up single //swap makes sense for the simple case of swapping two blocks, but then a more advanced palette system for these larger translations. Could also be useful for things such as schematics / structures.

Personally, I would name it "map", from a programmer's perspective, it makes sense imo. And, I mentioned this in discord, but you could do a command structure similar to lambda statements? Eg. //map mask->pattern

Or, you could even do a system where you parse every other argument as a mask/pattern. Eg. //map mask pattern [mask pattern]... and so on. I would argue the first way seems to make more sense than the second way, though.

Another thing to note, if you did the second way, you could theoretically just tack it onto the current replace command rather than creating a whole new command.