* For any commands allowing for a targeted shopkeeper: Print 'Ambiguous shopkeeper. Specify the shopkeeper explicitly instead.' error in case more than one shopkeeper is targeted?
* Instead of either only using the first shopkeeper, or applying the operation to all of them
* Allow arguments to change the following arguments, similar to how subcommands have different chains of arguments
* Eg. /shopkeeper info ['own'|'admin'|<player>] <shopkeeper>: Different suggestions/allowed arguments for the second argument depending on the first argument
* But: Avoid duplicate definition of common argument chains, if different chains are not required/used
* Eg. by defining an argument chain once and then reusing it for different sub-commands/arguments
* Maybe even dynamically, by allowing arguments that get parameterized by the arguments parsed before
* Eg. /region <region> removeMember <member>: Only suggest members that are part of the region
* Bind executing code directly to an argument chain, to avoid having to manually check the CommandContext for which arguments got actually parsed
* Allow for easier debugging of command execution and argument parsing (without introducing plugin-specific logging dependencies into the library classes).
* Also: "/list 123 2" would currently try to parse "123" as page number and then print an error due to the unexpected "2" due to the fallback mechanic used for the player argument
* Warning if command/arguments allow for ambiguity? Eg. by letting arguments provide a list of examples and evaluating all possible combinations
* Parse all possible argument assignments and print a warning if the input is ambigous?
* but: requires users to know the exact argument name: issue when arguments can have alises? (eg. for literals, especially if the command format uses an alias instead of the actual argument name)
* also: what about sub-arguments? Is it required to be able to explicitly specify which sub-argument an arg is meant to bind to? sub-arguments are usually an implementation detail
* or: "/list '' '2'" (quotes contain the arg(s) that get bound to specific arguments; including marking empty arguments explicitly)
* or: use some separator that marks which arg(s) get bound to which arguments, eg.: "/list | | 2"
* or: use special character/marker to explicitly mark missing arguments: "/list ! 2", or "/list _ 2"
* However: Does not allow resolving all kinds of ambiguities! eg. if arguments parse multiple args: "/cmd [multiple args (here] and there)" ('here' may be the last arg of the first argument, or the first arg of the second argument)
* -> Special character marks 'end of current argument': Allows marking missing arguments, as well as using it as argument delimiter
* Prohibit multiple shopkeepers using the same chest (currently only possible by manually editing the save file)?
* Or make this an official 'feature'? (Allowing players to link multiple of their shops to the same chest.
* Maybe together with the ability to link shopkeepers to multiple chests (because otherwise this might not make much sense, since a single chest might be quite limiting if used by multiple shops)
* More types of block shops? -> clicking button to open shop
* Virtual shops (command to edit and open trade menu), would allow tons of possibilities for other plugins / server admins to use shopkeeper shops in other contexts
* Change amount-per-click from 10 to 8 when clicking items in the player shopkeeper editor? (feels more intuitive due to minecraft's stack sizes)
* Compress currency items in the chest (low currency to high currency)? To maximize available storage capacity. This would also mean that the usage of the high-currency-min-cost setting would be limited to creating the trading recipes, and not be used when adding currency items to the shop chests.
* Maybe prevent any unrecognised types of clicks if running in compatibility mode? To reduce the risk of minecraft updates with new clicking actions causing issues.
* add an option to reposition shops: button pressed > window closes + message > player clicks a block > runs new/updated/smarter placement logic there, checks distance to chest, option (default true) to not allow it for shops that are not directly placed on top of the shop chest (because those were probably created via command and it is unclear whether players are meant to be able to reposition those shops)
* Or allow shops to be picked up (with all their data) inside an item (possible now via bukkit API? Limit on amount of data that can be stored?)
* Per-Trade/Shopkeeper settings, maybe via written books:<br>
-> by adding another row to the shopkeeper-editor inventory window each trade option and shopkeeper could have a slot for a written-book<br>
-> which could contain additional meta-data, per-trade/shopkeeper settings, which could be used (ex. by other plugins) to trigger certain actions when a specific trade is used <br>
* Maybe move shop options (like currently name, profession, etc.) into a separate inventory view to have additional space there<br>
* Add message to default zero-currency items explaining how to increase/decrease costs.
* Add zero-cost items in trading shopkeeper, with lore which explains how to setup the trade.
