{"thread":{"id":"47390","subject":"git commit file completion recently broke","startedAt":"2017-12-06T23:54:17Z","lastAt":"2017-12-07T18:57:51Z","messageCount":13,"participants":["Jacob Keller","Jeff King","Christian Couder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"334288","messageId":"CA+P7+xotDPa+=G5ypfyD7gySp6r2SKRAjMSw_0BmvuyyfcjxBw@mail.gmail.com","threadId":"47390","inReplyTo":null,"subject":"git commit file completion recently broke","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-12-06T23:53:50Z","receivedAt":"2017-12-06T23:54:17Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"Hi,\n\nI'm still investigating, but thought I'd send an email. I recently\nupdated to jch branch, and found that completion for git commit does\nnot work as expected.\n\nIf I have a git repository with a modified file in a subdirectiory,\nthen git commit produces the name of the subdirectory instead of\nthe file names.\n\nThis occurs regardless of where I run the git commit command.\n\nThanks,\nJake\n"},{"id":"334289","messageId":"CA+P7+xouqMi4xo7psM-PmpqcpKre2X1YyYZBLfMDYSSZ8tD_VQ@mail.gmail.com","threadId":"47390","inReplyTo":"CA+P7+xotDPa+=G5ypfyD7gySp6r2SKRAjMSw_0BmvuyyfcjxBw@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-12-07T00:01:51Z","receivedAt":"2017-12-07T00:02:21Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Dec 6, 2017 at 3:53 PM, Jacob Keller wrote:\n> Hi,\n>\n> I'm still investigating, but thought I'd send an email. I recently\n> updated to jch branch, and found that completion for git commit does\n> not work as expected.\n>\n> If I have a git repository with a modified file in a subdirectiory,\n> then git commit produces the name of the subdirectory instead of\n> the file names.\n>\n> This occurs regardless of where I run the git commit command.\n>\n> Thanks,\n> Jake\n\nI think I narrowed this down to \"git diff-index --name-only --relative\nHEAD\" producing a list of files *not* relative to the current\ndirectory.\n\nThanks,\nJake\n"},{"id":"334291","messageId":"CA+P7+xqdJjxFDSe61BTkkxE0RF6-n4OCCrsL1ZbViXnJcAqE1Q@mail.gmail.com","threadId":"47390","inReplyTo":"CA+P7+xouqMi4xo7psM-PmpqcpKre2X1YyYZBLfMDYSSZ8tD_VQ@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-12-07T00:08:28Z","receivedAt":"2017-12-07T00:08:54Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Dec 6, 2017 at 4:01 PM, Jacob Keller wrote:\n> On Wed, Dec 6, 2017 at 3:53 PM, Jacob Keller wrote:\n>> Hi,\n>>\n>> I'm still investigating, but thought I'd send an email. I recently\n>> updated to jch branch, and found that completion for git commit does\n>> not work as expected.\n>>\n>> If I have a git repository with a modified file in a subdirectiory,\n>> then git commit produces the name of the subdirectory instead of\n>> the file names.\n>>\n>> This occurs regardless of where I run the git commit command.\n>>\n>> Thanks,\n>> Jake\n>\n> I think I narrowed this down to \"git diff-index --name-only --relative\n> HEAD\" producing a list of files *not* relative to the current\n> directory.\n>\n> Thanks,\n> Jake\n\nI've started a git bisect to see if i can find the source of the problem.\n\nThanks,\nJake\n"},{"id":"334294","messageId":"20171207002234.GA21003@sigill.intra.peff.net","threadId":"47390","inReplyTo":"CA+P7+xouqMi4xo7psM-PmpqcpKre2X1YyYZBLfMDYSSZ8tD_VQ@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-12-07T00:22:35Z","receivedAt":"2017-12-07T00:22:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 06, 2017 at 04:01:51PM -0800, Jacob Keller wrote:\n\n> I think I narrowed this down to \"git diff-index --name-only --relative\n> HEAD\" producing a list of files *not* relative to the current\n> directory.\n\nHmm, my guess would have been something funny in the setup code\nforgetting our original prefix.\n\nBut nope, it looks like the culprit is f7923a5ece (diff: use\nskip_to_optional_val(), 2017-12-04), which switched over parsing of\n\"--relative\".\n\n-Peff\n"},{"id":"334295","messageId":"20171207002439.GB21003@sigill.intra.peff.net","threadId":"47390","inReplyTo":"20171207002234.GA21003@sigill.intra.peff.net","subject":"Re: git commit file completion recently broke","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-12-07T00:24:39Z","receivedAt":"2017-12-07T00:24:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 06, 2017 at 07:22:35PM -0500, Jeff King wrote:\n\n> On Wed, Dec 06, 2017 at 04:01:51PM -0800, Jacob Keller wrote:\n> \n> > I think I narrowed this down to \"git diff-index --name-only --relative\n> > HEAD\" producing a list of files *not* relative to the current\n> > directory.\n> \n> Hmm, my guess would have been something funny in the setup code\n> forgetting our original prefix.\n> \n> But nope, it looks like the culprit is f7923a5ece (diff: use\n> skip_to_optional_val(), 2017-12-04), which switched over parsing of\n> \"--relative\".\n\nOh, actually, I guess I was half-right. It feeds &options->prefix as the\n\"default\", meaning that we overwrite it with the empty string. I don't\nthink \"--relative\" works for the semantics of skip_to_optional_value,\nsince it needs:\n\n --relative=foo: set prefix to \"foo\"\n\n --relative: leave prefix untouched\n\n-Peff\n"},{"id":"334297","messageId":"CA+P7+xpoaa5zaF13ageKKjpPKTECU6XjaRdSZy6WOP7Q0TX+yA@mail.gmail.com","threadId":"47390","inReplyTo":"20171207002439.GB21003@sigill.intra.peff.net","subject":"Re: git commit file completion recently broke","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-12-07T00:38:29Z","receivedAt":"2017-12-07T00:38:55Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Dec 6, 2017 at 4:24 PM, Jeff King wrote:\n> On Wed, Dec 06, 2017 at 07:22:35PM -0500, Jeff King wrote:\n>\n>> On Wed, Dec 06, 2017 at 04:01:51PM -0800, Jacob Keller wrote:\n>>\n>> > I think I narrowed this down to \"git diff-index --name-only --relative\n>> > HEAD\" producing a list of files *not* relative to the current\n>> > directory.\n>>\n>> Hmm, my guess would have been something funny in the setup code\n>> forgetting our original prefix.\n>>\n>> But nope, it looks like the culprit is f7923a5ece (diff: use\n>> skip_to_optional_val(), 2017-12-04), which switched over parsing of\n>> \"--relative\".\n>\n> Oh, actually, I guess I was half-right. It feeds &options->prefix as the\n> \"default\", meaning that we overwrite it with the empty string. I don't\n> think \"--relative\" works for the semantics of skip_to_optional_value,\n> since it needs:\n>\n> --relative=foo: set prefix to \"foo\"\n>\n> --relative: leave prefix untouched\n>\n> -Peff\n\nYep, and apparently our test suite completely lacked any tests of\n--relative on its own.\n\nI've sent a patch to add some tests.\n\nI don't know the exact best way to fix this, I guess we could just\nrevert it the changes to relative... but maybe we could add or modify\nthe semantics of skip_to_optional_val()?? What if it was changed so\nthat it left the value alone if no value was provided? This would\nrequire callers to pre-set the value they want as default, but that\nwould solve relative's problem.\n\nI'll look into that.\n\nThanks,\nJake\n"},{"id":"334298","messageId":"20171207005639.GB1975@sigill.intra.peff.net","threadId":"47390","inReplyTo":"CA+P7+xpoaa5zaF13ageKKjpPKTECU6XjaRdSZy6WOP7Q0TX+yA@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-12-07T00:56:39Z","receivedAt":"2017-12-07T00:56:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 06, 2017 at 04:38:29PM -0800, Jacob Keller wrote:\n\n> >> But nope, it looks like the culprit is f7923a5ece (diff: use\n> >> skip_to_optional_val(), 2017-12-04), which switched over parsing of\n> >> \"--relative\".\n> >\n> > Oh, actually, I guess I was half-right. It feeds &options->prefix as the\n> > \"default\", meaning that we overwrite it with the empty string. I don't\n> > think \"--relative\" works for the semantics of skip_to_optional_value,\n> > since it needs:\n> >\n> > --relative=foo: set prefix to \"foo\"\n> >\n> > --relative: leave prefix untouched\n> >\n> > -Peff\n> \n> Yep, and apparently our test suite completely lacked any tests of\n> --relative on its own.\n> \n> I've sent a patch to add some tests.\n\nGreat. I was also saddened by our lack of tests.\n\n> I don't know the exact best way to fix this, I guess we could just\n> revert it the changes to relative... but maybe we could add or modify\n> the semantics of skip_to_optional_val()?? What if it was changed so\n> that it left the value alone if no value was provided? This would\n> require callers to pre-set the value they want as default, but that\n> would solve relative's problem.\n\nI think that would work for this case. But just looking at others from\nthe same series, I think they'd get pretty awkward. For instance we now\nhave:\n\n else if (!strcmp(arg, \"--color))\n\toptions->use_color = 1;\n else if (skip_prefix(arg, \"--color=\", &arg))\n\t/* parse \"arg\" as colorbool */\n\nwhich became:\n\n else if (skip_to_optional_val_default(arg, \"--color\", &arg, \"always\"))\n\t/* parse \"arg\" as colorbool */\n\nHow would that look with the \"leave it alone instead of assigning a\ndefault\" semantics? It gets pretty clumsy, because you have to\npre-assign \"always\" to some pointer. But then we can't reuse \"arg\", so\nwe end up with something more like:\n\n const char *color_val = \"always\";\n ...\n else if (skip_to_optional_val(arg, \"--color\", &color_val))\n\nBut we need one such \"color_val\" for every option we test for, and we\nhave to set all of them up before any matches (because we don't know\nwhich one we'll actually match). Yuck.\n\nI think we'd do better to just assign NULL when there's \"=\", so we can\ntell the difference between \"--relative\", \"--relative=\", and\n\"--relative=foo\" (all of which are distinct).\n\nI think that's possible with the current scheme by doing:\n\n else if (skip_to_optional_val_default(arg, \"--relative\", &arg, NULL)) {\n\toptions->flags.relative_name = 1;\n\tif (arg)\n\t\toptions->prefix = arg;\n }\n\nIOW, the problem isn't in the design of the skip function, but just how\nit was used in this particular case. I do think it may make sense for\nthe \"short\" one to use NULL, like:\n\n skip_to_optional_val(arg, \"--relative, &arg)\n\nbut maybe some other callers would be more inconvenienced (they may have\nto current NULL back into the empty string if they want to string\n\"--foo\" the same as \"--foo=\").\n\n-Peff\n"},{"id":"334301","messageId":"CA+P7+xo5Zw5AjbJ2RAkzAidii-JUZHK=SDO+zS2nT1CD9mu_fg@mail.gmail.com","threadId":"47390","inReplyTo":"20171207005639.GB1975@sigill.intra.peff.net","subject":"Re: git commit file completion recently broke","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-12-07T01:04:02Z","receivedAt":"2017-12-07T01:04:31Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Dec 6, 2017 at 4:56 PM, Jeff King wrote:\n> On Wed, Dec 06, 2017 at 04:38:29PM -0800, Jacob Keller wrote:\n>\n>> >> But nope, it looks like the culprit is f7923a5ece (diff: use\n>> >> skip_to_optional_val(), 2017-12-04), which switched over parsing of\n>> >> \"--relative\".\n>> >\n>> > Oh, actually, I guess I was half-right. It feeds &options->prefix as the\n>> > \"default\", meaning that we overwrite it with the empty string. I don't\n>> > think \"--relative\" works for the semantics of skip_to_optional_value,\n>> > since it needs:\n>> >\n>> > --relative=foo: set prefix to \"foo\"\n>> >\n>> > --relative: leave prefix untouched\n>> >\n>> > -Peff\n>>\n>> Yep, and apparently our test suite completely lacked any tests of\n>> --relative on its own.\n>>\n>> I've sent a patch to add some tests.\n>\n> Great. I was also saddened by our lack of tests.\n>\n>> I don't know the exact best way to fix this, I guess we could just\n>> revert it the changes to relative... but maybe we could add or modify\n>> the semantics of skip_to_optional_val()?? What if it was changed so\n>> that it left the value alone if no value was provided? This would\n>> require callers to pre-set the value they want as default, but that\n>> would solve relative's problem.\n>\n> I think that would work for this case. But just looking at others from\n> the same series, I think they'd get pretty awkward. For instance we now\n> have:\n>\n\nThat obviously won't work for any case which sues\nskip_to_optional_val_default() (since these provide a default value to\ngive in case none is provided.\n\n> else if (!strcmp(arg, \"--color))\n> options->use_color = 1;\n> else if (skip_prefix(arg, \"--color=\", &arg))\n> /* parse \"arg\" as colorbool */\n>\n> which became:\n>\n> else if (skip_to_optional_val_default(arg, \"--color\", &arg, \"always\"))\n> /* parse \"arg\" as colorbool */\n>\n> How would that look with the \"leave it alone instead of assigning a\n> default\" semantics? It gets pretty clumsy, because you have to\n> pre-assign \"always\" to some pointer. But then we can't reuse \"arg\", so\n> we end up with something more like:\n>\n> const char *color_val = \"always\";\n> ...\n> else if (skip_to_optional_val(arg, \"--color\", &color_val))\n>\n\nIt obviously wouldn't. The only sensible solution is to have\n\"skip_to_optional_val_something()\" which does this new behavior.\n\nOr, change skip_to_optional_val() behave this new way, but\nskip_to_optional_val_default() behave in the current way.\n\n> But we need one such \"color_val\" for every option we test for, and we\n> have to set all of them up before any matches (because we don't know\n> which one we'll actually match). Yuck.\n>\n> I think we'd do better to just assign NULL when there's \"=\", so we can\n> tell the difference between \"--relative\", \"--relative=\", and\n> \"--relative=foo\" (all of which are distinct).\n>\n> I think that's possible with the current scheme by doing:\n>\n> else if (skip_to_optional_val_default(arg, \"--relative\", &arg, NULL)) {\n> options->flags.relative_name = 1;\n> if (arg)\n> options->prefix = arg;\n> }\n>\n> IOW, the problem isn't in the design of the skip function, but just how\n> it was used in this particular case. I do think it may make sense for\n> the \"short\" one to use NULL, like:\n>\n> skip_to_optional_val(arg, \"--relative, &arg)\n>\n> but maybe some other callers would be more inconvenienced (they may have\n> to current NULL back into the empty string if they want to string\n> \"--foo\" the same as \"--foo=\").\n>\n> -Peff\n\nWhat you outlined above is probably the best we can do. We could even\nadd some extra helper which does that for us if we want.\n\nI sent a patch that merely reverts the change to --relative and adds a\ntest for now though.\n\nThanks,\nJake\n"},{"id":"334302","messageId":"20171207010801.GD1975@sigill.intra.peff.net","threadId":"47390","inReplyTo":"CA+P7+xo5Zw5AjbJ2RAkzAidii-JUZHK=SDO+zS2nT1CD9mu_fg@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-12-07T01:08:01Z","receivedAt":"2017-12-07T01:08:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 06, 2017 at 05:04:02PM -0800, Jacob Keller wrote:\n\n> What you outlined above is probably the best we can do. We could even\n> add some extra helper which does that for us if we want.\n> \n> I sent a patch that merely reverts the change to --relative and adds a\n> test for now though.\n\nThanks. I'm fine with reverting --relative to its original form, or\nhaving it do the NULL thing I mentioned. Christian can decide, since\nit's his series.\n\nI do think we may want to take the test improvement as a separate patch.\n\n-Peff\n"},{"id":"334308","messageId":"CAP8UFD3iL_sRgvhm7YO_jVG5RiNn1=JRW0qvhBEPcUtCorWdYA@mail.gmail.com","threadId":"47390","inReplyTo":"20171207005639.GB1975@sigill.intra.peff.net","subject":"Re: git commit file completion recently broke","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-12-07T08:14:31Z","receivedAt":"2017-12-07T08:14:37Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Dec 7, 2017 at 1:56 AM, Jeff King wrote:\n\n> I think we'd do better to just assign NULL when there's \"=\", so we can\n> tell the difference between \"--relative\", \"--relative=\", and\n> \"--relative=foo\" (all of which are distinct).\n>\n> I think that's possible with the current scheme by doing:\n>\n> else if (skip_to_optional_val_default(arg, \"--relative\", &arg, NULL)) {\n> options->flags.relative_name = 1;\n> if (arg)\n> options->prefix = arg;\n> }\n\nYeah, that is a possible fix.\n\n> IOW, the problem isn't in the design of the skip function, but just how\n> it was used in this particular case.\n\nI agree.\n\n> I do think it may make sense for\n> the \"short\" one to use NULL, like:\n>\n> skip_to_optional_val(arg, \"--relative, &arg)\n>\n> but maybe some other callers would be more inconvenienced (they may have\n> to current NULL back into the empty string if they want to string\n> \"--foo\" the same as \"--foo=\").\n\nI discussed that with Junio and yeah there are many callers that want\n\"--foo\" to be the same as \"--foo=\".\n\nBy the way I wonder if \"--relative=\" makes any sense, and if we should\nemit a warning or just die in this case.\n"},{"id":"334309","messageId":"20171207081910.GA29464@sigill.intra.peff.net","threadId":"47390","inReplyTo":"CAP8UFD3iL_sRgvhm7YO_jVG5RiNn1=JRW0qvhBEPcUtCorWdYA@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-12-07T08:19:10Z","receivedAt":"2017-12-07T08:19:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 07, 2017 at 09:14:31AM +0100, Christian Couder wrote:\n\n> > I do think it may make sense for\n> > the \"short\" one to use NULL, like:\n> >\n> > skip_to_optional_val(arg, \"--relative, &arg)\n> >\n> > but maybe some other callers would be more inconvenienced (they may have\n> > to current NULL back into the empty string if they want to string\n> > \"--foo\" the same as \"--foo=\").\n\nOof, I lost all ability to type in that last sentence. :)\n\nIt looks like you deciphered my meaning, though.\n\n> I discussed that with Junio and yeah there are many callers that want\n> \"--foo\" to be the same as \"--foo=\".\n\nYeah, if this is the only case, then just calling the \"_default\" variant\nwith NULL for this instance makes sense to me.\n\n> By the way I wonder if \"--relative=\" makes any sense, and if we should\n> emit a warning or just die in this case.\n\nI also wondered about that. It does function as \"relative to the root of\nthe tree\". But of course if you want that you can just omit\n\"--relative\". Still, it could be a minor convenience for somebody who is\nfilling in \"--relative\" in a script. That's reaching, I think, but I\ndon't see any particular reason to _forbid_ it (especially since it has\nworked for many years).\n\n-Peff\n"},{"id":"334322","messageId":"xmqq8teeftn7.fsf@gitster.mtv.corp.google.com","threadId":"47390","inReplyTo":"CAP8UFD3iL_sRgvhm7YO_jVG5RiNn1=JRW0qvhBEPcUtCorWdYA@mail.gmail.com","subject":"Re: git commit file completion recently broke","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-07T15:24:28Z","receivedAt":"2017-12-07T15:25:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n>> I do think it may make sense for\n>> the \"short\" one to use NULL, like:\n>>\n>> skip_to_optional_val(arg, \"--relative, &arg)\n>>\n>> but maybe some other callers would be more inconvenienced (they may have\n>> to current NULL back into the empty string if they want to string\n>> \"--foo\" the same as \"--foo=\").\n>\n> I discussed that with Junio and yeah there are many callers that want\n> \"--foo\" to be the same as \"--foo=\".\n\nYup, the original thread has details and me saying that assuming all\nof them want --foo and --foo= the same is questionable. The likely\nfix would be to use the _default variant with NULL, which was added\nexactly for cases like this.\n\n"},{"id":"334344","messageId":"CA+P7+xrhgbcogxYa38jEu3PuF5hVNNYPjAq031bYE8bgao168Q@mail.gmail.com","threadId":"47390","inReplyTo":"xmqq8teeftn7.fsf@gitster.mtv.corp.google.com","subject":"Re: git commit file completion recently broke","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-12-07T18:57:23Z","receivedAt":"2017-12-07T18:57:51Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Dec 7, 2017 at 7:24 AM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>>> I do think it may make sense for\n>>> the \"short\" one to use NULL, like:\n>>>\n>>> skip_to_optional_val(arg, \"--relative, &arg)\n>>>\n>>> but maybe some other callers would be more inconvenienced (they may have\n>>> to current NULL back into the empty string if they want to string\n>>> \"--foo\" the same as \"--foo=\").\n>>\n>> I discussed that with Junio and yeah there are many callers that want\n>> \"--foo\" to be the same as \"--foo=\".\n>\n> Yup, the original thread has details and me saying that assuming all\n> of them want --foo and --foo= the same is questionable. The likely\n> fix would be to use the _default variant with NULL, which was added\n> exactly for cases like this.\n>\n\nSlightly more complex. You have to use the _default variant, pass in\narg instead of options->prefix, and then make sure arg was set before\noverwriting options->prefix. If you just use _default with NULL, it\nwill not quite fix the problem.\n\nThanks,\nJake\n"}]}