| Commit message (Collapse) | Author | Lines | 
 | 
Concerns were raised over possible race conditions due `asyncio.Lock`
internally awaiting coroutines. Does a mere `await` suspend the current
coroutine, or does it have to actually await something asynchronous,
like a future?
Avoid answering that question by doing away with the awaits, which
aren't necessary but are there as a consequence of using `asyncio.Lock`.
Instead, add a custom `LockGuard` object to replace the previous locks.
 | 
 | 
Clarify the significance of the argument being passed.
 | 
 | 
The annotation was previously changed on the basis of an incorrect
return annotation PyCharm inferred for `check()`.
 | 
 | 
The exception it raises reads better if the singular form of the word
is used.
 | 
 | 
Silent failure is confusing to users. Showing an error message clears up
why nothing happened with their command.
 | 
 | 
 | 
 | 
The exception will facilitate user feedback for commands which use the
decorator.
 | 
 | 
 | 
 | 
Instead of taking a callable, this wrapper just takes a name or position
to get the resource ID.
 | 
 | 
 | 
 | 
 | 
 | 
Explicit is better than implicit, and this default value wasn't much of
a convenience.
 | 
 | 
Replace the `_get_arg_value` call with `function.get_arg_value` cause
the latter makes use of bound arguments, which are more accurate.
 | 
 | 
 | 
 | 
 | 
 | 
This fixes race conditions between editing, deleting, and sending a
reminder. If one operation is already happening, the others will be
aborted.
 |