These are chat archives for kbknapp/clap-rs

15th
Mar 2018
xliiv
@xliiv
Mar 15 2018 19:52
is it possible to add arg to clap::App without moving app?
Kevin K.
@kbknapp
Mar 15 2018 21:55
@willmurphyscode yeah 805 is what I meant
@cjm00 not exactly, but using default values and juat manually checking for value "" to set this other default is pretty easy
@xliiv yes, but it's a private API so shouldn't be relied on as it can change without warning
What is the reason for wanting to avoid the move?
Kevin K.
@kbknapp
Mar 15 2018 22:00
If it's a perf thing, I don't think it makes a large difference as even CLIs with many, many args only take a few hundredths of a millisecond
I haven't looked at the generated asm but the move mighr even be elided
William Murphy
@willmurphyscode
Mar 15 2018 22:03
@kbknapp Did you want me to merge kbknapp/clap-rs#1208 ?
xliiv
@xliiv
Mar 15 2018 22:05
@kbknapp i could redesign it so this problem is obsolote, but i've got new :)
Kevin K.
@kbknapp
Mar 15 2018 22:07
@willmurphyscode I'm going to do a scrub of the v3 changes this weekend and potentially undo some of the deprecations and changes. Now that cargo just merged clap I want the upgrade from 2 to 3 only include required breaking changes, and not breaking changes just for the sake cosmetics or "technical API correctness" (i.e. renaming of the ger_matches methods
I don't want to get into a python 2 to 3 conundrum
Then the change from 3 to 4 could like wise be a gradual nudging towards correctness, rather than all out change everything
William Murphy
@willmurphyscode
Mar 15 2018 22:09
Ok, so we are not planning to merge this change right now?
Kevin K.
@kbknapp
Mar 15 2018 22:11
From my quick glance only the renaming of App methods and removal of Arg bool methods will be undone. Everything else should be fine to stay in
William Murphy
@willmurphyscode
Mar 15 2018 22:12
I'm not sure we're talking about the same PR - I'm talking about the PR to print ARGS section first in help output - I haven't intentionally renamed any methods
Kevin K.
@kbknapp
Mar 15 2018 22:14
Yeah you can merge 1208
William Murphy
@willmurphyscode
Mar 15 2018 22:14
OK thanks
Kevin K.
@kbknapp
Mar 15 2018 22:14
My comments above were just general comments, not directed at any pr !)
;)
William Murphy
@willmurphyscode
Mar 15 2018 22:16
Oh ok - I thought you were providing specific comments on a different PR
Kevin K.
@kbknapp
Mar 15 2018 22:16
Nope, sorry should have been more clear :)
I'm still technically on vacation with my kids till Saturday, so I won't actually take a deeper look until I get home. Mainly I want the upgrade to be as painless as possible
William Murphy
@willmurphyscode
Mar 15 2018 22:18
Should I still look at ways of doing kbknapp/clap-rs#805 next?
Kevin K.
@kbknapp
Mar 15 2018 22:18
Yep that'd be great!
Although it kind of goes against the normal way clap works, the easiest way to do this would be to have an App method (App::arg_heading?...name is bikeshedable) which then implies AppSettings::DeriveDisplayOrder and keeps track of which args were added to each "heading" then just displays these headings after all default headings

I'm on mobile but I have an example of what I think the use should look like (just no idea about implementation)
Kevin K.
@kbknapp
Mar 15 2018 22:25
App::new("Foo")
.arg(...) // Added to default headings
‎.arg_heading("my section")
‎.arg(...) // Added to "my section"
‎.arg_heading("other section")
‎.arg(...) // Added to "other section"
‎// etc
It's the only way I've found that interacts correctly with things like groups, etc
William Murphy
@willmurphyscode
Mar 15 2018 22:27
hmm ok, so we would have to keep track of which section args were passed under? I had imagined something like:
App::new("foo")
    .arg("some_arg")
    .arg("debug").under_heading("ADVANCED")
Does that have issues with groups? I haven't looked at how we parse groups
Kevin K.
@kbknapp
Mar 15 2018 22:28
That could work, but if you have 50 args under "advanced" you have to type "advanced" 50 times
William Murphy
@willmurphyscode
Mar 15 2018 22:28
yeah that would be a pain
i'd like to create dynamically clap::App
Kevin K.
@kbknapp
Mar 15 2018 22:30
That help string gets dropped at the end of the loop
xliiv
@xliiv
Mar 15 2018 22:30
@kbknapp i can't find solution
.. of this
is it possible to write help as non-static?
Kevin K.
@kbknapp
Mar 15 2018 22:31
You just need to pull those help strings out of the loop so they last at least as long as the subcommand they are for
xliiv
@xliiv
Mar 15 2018 22:32
is it possible while i want to create them in loop?
Kevin K.
@kbknapp
Mar 15 2018 22:34
If you use a collection (vec or hashmap) to hold those help messages that lives outside the loop it'd work
But those Strings are freed at the end of the loop as written
Sean Leffler
@sdleffler
Mar 15 2018 22:34
Alternatively you could use an arena.
Kevin K.
@kbknapp
Mar 15 2018 22:35
Yep, or lazy_static
Sean Leffler
@sdleffler
Mar 15 2018 22:35
That would basically do the same thing as the vec/hashmap solution but is simpler IMO. otoh that's another dependency :P
Kevin K.
@kbknapp
Mar 15 2018 22:35
Ripgrep used to do something similar to this
xliiv
@xliiv
Mar 15 2018 22:36
i'll try collect it in vec
thanks
and look at arena tomorrow
xliiv
@xliiv
Mar 15 2018 23:00
btw: this doesn't work, but i'm going to bed
:)
Kevin K.
@kbknapp
Mar 15 2018 23:16
name and help are never added to the Vecs
William Murphy
@willmurphyscode
Mar 15 2018 23:19
something like this: https://play.rust-lang.org/?gist=c48eb00431d402c4c9623ab21b3857ea&version=stable but I'm having a little trouble getting the param to about to have the right type