* Use plural linking verb
While it looks like you could use "there's" informally, grammatically, it should be "are" since "commits" is plural.
<https://dictionary.cambridge.org/us/grammar/british-grammar/there-is-there-s-and-there-are>
* Omit "the"
I created a remote called "github" and got this prompt:
> Would you like to push commits from the current branch to the "github"?
Normally, the default name "origin" doesn't sound bad in that prompt,
but using the name "github" made the prompt sound like something wasn't
right to my American English-speaking ears.
Here are a few options. Yes, I know English grammar sucks, to put it
mildly. But, hopefully, the following options and explanations make
sense.
Get rid of "the". This is the option I went with. "github" acts as a
proper noun, so no determiner is needed. If you substitute your own
name for "github" in the original prompt above, you get the same effect:
> Would you like to push commits from the current branch to "github"?
Add the implicit word "remote". "github" now acts as an adjective and
"the" refers to "remote":
> Would you like to push commits from the current branch to the "github" remote?
Or, combine the two. This last option relies on the fact that
instructions and manuals often omit definite articles because most
articles are definite. See the [zero-marking][2] article on Wikipedia.
The original prompt already does this by omitting "the" before the word
"commits":
> Would you like to push commits from the current branch to "github" remote?
Reference:
[1]: http://writing.umn.edu/sws/quickhelp/grammar/articlesproper.html
[2]: https://en.wikipedia.org/wiki/Zero-marking_in_English
The `issue comment` command would perform a `filepath.Base()` on the
value of EDITOR and use the result for launching the editor, which is
undesireable for both functional and display purposes:
- For functional purposes, always shellsplit the value of GH_EDITOR or
EDITOR before we shell out to that process;
- For display purposes, extract the basename only after shellsplitting.
I noticed that PadlockState didn't really have anything to do with the
LockOptions and it was easy to call an incorrect locking function that
didn't match the PadlockState.
Now, you pass in the state as an argument and you simply call the
appropriate function instead of setting PadlockState and then calling
the correct function.
- Other touch ups and refactoring
Rather than saving the intended lock state and calling a method
depending on the lock state, just call the method directly. By the time
you need to the padlock state, you already know which method to use; no
need to first change the lock state than call the method.
Also, refactored print/error messages that are conditional.
- Fix error if found an issue while using `gh pr lock/unlock` or vice versa
- Added additional types
- Used githubv4 types
- Added "relock" state
- If the conversation is already locked you have two choices: try to
lock it again or do nothing. Do nothing is easy. But, if you
want to change the lock reason, you need to first unlock the
conversation and then lock it again.
- Added survey to confirm if you want to relock
- Added formatted print statements
This removes the explicit check for the gist owner, speeding up the gist
deletion due to fewer API requests, but resulting in a more vague error
message in case the gist is "not found".
