On 07/03/2017 08:01 AM, Max Reitz wrote: > On 2017-07-03 14:51, Eric Blake wrote: >> On 07/03/2017 07:25 AM, Max Reitz wrote: >>> Currently, bdrv_reopen_prepare() assumes that all BDS options are >>> strings. However, this is not the case if the BDS has been created >>> through the json: pseudo-protocol or blockdev-add. >>> >>> Note that the user-invokable reopen command is an HMP command, so you >> >> s/invokable/invocable/ > > I was asking this myself when writing this commit message and actually > consulted Wiktionary: https://en.wiktionary.org/wiki/invokable
My intuitive reasoning for favoring 'c' is that we spell it "invocation", not "invokation", even if the short form is "invoke". But I also consulted dictionary.com before writing my original reply: http://www.dictionary.com/browse/invocable which pulls up "invoke" as the primary, and only lists "invocable" (and not "invokable") as the related form adjective. Meanwhile, you are correct that wiktionary does list both forms as alternates of one another, so I can live with the 'k' even though it looks odd. >>> + * all options. For now, this is not too big of an issue >>> because >>> + * the user simply can not specify options which cannot be >>> changed >> >> Seeing "can not" usually looks wrong for "cannot"; but here, it is >> grammatically correct. But better would be "the user can simply not >> specify" or "the user can simply avoid specifying options". > > Awww, I deliberately designed the sentence so I could use "can not". :-) > > (and even contrast it with the following "cannot"!) Maybe it's just that I'm being thrown off by the placement of 'simply'; as a native speaker, I have an easier time parsing "can simply not" than I do "simply can not", maybe because of where the emphasis of "simply" is falling. Which is perhaps weird, because in the infinitive form (coming up with a construct that uses "to" instead of "can"), I note that "it is possible to simply not specify options" is a split infinitive (which style guides tell you to avoid, even though I think it is acceptable); while "it is possible simply to not specify options" satisfies more style guides. But since you are intentionally doing it for the play on words, > >>> + * anyway, so they will stay unchanged. */ >> >> The grammar tweak is minor, so: >> Reviewed-by: Eric Blake <[email protected]> > Please let me keep it :-) you can keep it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
