New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--help me if you can #5680
--help me if you can #5680
Conversation
I like your idea, however making it interactive is the task of the shell, not ours. However maybe we should provide autocompletion scripts. It wouldn't be a problem to add this functionality to the gen.pl script but this is probably outside of the scope of this PR. |
Test 1139 seems to fail on some CI builds (example):
|
Two questions (that I didn't find answered yet, most probably because I didn't look very closely yet):
|
Not yet but I think it throws a warning that it misses a category line. Same with other required options
Yes, because there won't be a bitmask #DEFINE. However if you're generate the bitmask definitions with |
dd873f6
to
af4dd10
Compare
I re-ordered the commits into a more logical order |
@@ -2,6 +2,7 @@ Short: a | |||
Long: append | |||
Help: Append to target file when uploading | |||
Protocols: FTP SFTP | |||
Category: ftp sftp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say categories
Category: ftp sftp | |
Categories: ftp sftp |
I see that in most cases, categories
is equal to protocols
. Does it make sense to use by default the protocols field as the categories and in specific cases use the categories
as an override field ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your review!
Most options only belong to one category. The plural would sound weird there in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to use by default the protocols field as the categories
That sounds like a lever idea that will reduce a lot of duplication!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like a lever idea that will reduce a lot of duplication!
But what is with options like --user
or --output
which don't belong to any (specific) protocol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most options only belong to one category. The plural would sound weird there in my opinion.
In your code you are already referencing categories
:
Lines 119 to 123 in af4dd10
struct helptxt { | |
const char *opt; | |
const char *desc; | |
curlhelp_t categories; | |
}; |
Protocols is in plural form and b/c category(ies) is relatively equal to protocols I think we need to stay consistent.
But what is with options like --user or --output which don't belong to any (specific) protocol
We could you use this logic to define the category(ies):
my_category(ies): category(ies) | default(protocols) | default("curl")
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bagder I'm not sure to understand you point of view :thinking: ; tell me if I am wrong:
- each file has a
category:
field and over all just make sure they match
, so you have to duplicate the protocols in the categories to make sure it is correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I think:
- each .d file gets a
category:
field, that can be empty or list additional categories apart from the protocols which are used by default - The category
curl
should rather be renamedtool
and should be explicitly mentioned as a category if desired.
This way, the used categories are all visible in each file (just that they're also in the protocols line) and we don't need to repeat the protocols in the category field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me, your position @emilengler 😃 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will have a deeper look on this at Sunday or Monday. I am currently on vacation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change from tool to curl makes sense. I will change this.
I also agree on the part that the category field can be empty where the item would fall into the misc category then.
However I still don't think it is a good idea to mix up with protocols. Of course this saves some work but I still think it adds more confusion also AFAIK the protocol field is not omnipresent so far
I implemented @bagder's improvements. I will now put the commits into a more logical order |
32cd3f4
to
0237466
Compare
I've also added a new test which tests the case insensitivity. |
@emilengler a lot of tests are failing.
|
Thanks for your testing! For me they all worked fine o.O |
By looking on the checks of your PR |
I will have a deeper a look soon. |
0237466
to
bf24e39
Compare
Should be fixed now |
Someone knows what type I should use? I need at least 32-bits of space for the bit mask. However fixed size data types are a C99 thing |
You mean for an unsigned 32 bit variable? |
Ok will change that |
bf24e39
to
b63bc8a
Compare
Updated |
I think the failed test is very likely a false positive |
Merge conflicts solved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks great. This is a big step forward for --help
. I think the categories you've picked seem perfect. We can always fix them later if we find mistakes.
I just have three minor things.
Could we get a bash completion script for that? I specially asking not for a command line option cause this either makes she'll startup slow or decouples the auto completion version from the fuel version. |
I generally like the bash completion for curl provided by the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eager to see this great addition in the next release 💪
e63de0e
to
682e4a8
Compare
@bagder Changes from you applied. I also rephrased the category descriptions to be more descriptive. |
Note to the maintainer who will merge this: |
Sure, that's possible. But are they really stand-alone enough to warrant being individual commits? They certainly don't have proper individual commit messages right now... |
Yes I also thought about that while writing the comment. I thought about adding a prefix or add that line to the commit message:
|
The failing tests on Windows are a lower level problems. It is because of line endings. Adding the Windows line ending to the test cases will make them to not work on Windows. Fixing this would be outside of the scope of this PR. |
Fixing it is a matter of setting |
This is the begin of the implementation of "--help me if you can" by Daniel Fandrich presented at curl up 2020. See: https://bit.ly/2C92PvR This commit is a part of "--help me if you can"; curl#5680
This commit is a part of "--help me if you can"; curl#5680
This commit is a part of "--help me if you can"; curl#5680
This commit is a part of "--help me if you can"; curl#5680
682e4a8
to
ac93efd
Compare
Tests should be fixed now |
I made something that helps in that case. See the commit messages |
I think the CI failures are fine. As far as I think they are unrelated to this PR |
I've taken the liberty of squashing them into three logical commits: docs, tool and tests. Merging now. Many thanks for your hard work on this! |
This commit is a part of "--help me if you can" Closes #5680
This commit is a part of "--help me if you can" Closes #5680
Was a pleasure for me! |
Fantastic work! Thanks for making this dream a reality.
|
Introduction
This implements the --help me if you can by Daniel Fandrich presented at curl-up 2020. See here.
I know that the diff looks big (242 files changed). However, ~99% of these just set the category for each item.
I suggest you to have a look at this YouTube Video where I explain how this works in detail.
I hope this can get into the next release. Maybe set this high priority?
I split up curl into 22 categories:
It works through a bitmask. Because of this every item can contain multiple categories.
If the user does not request any special category, a list of the most important curl commands is being shown. I know this topic is highly controversial and I am open to any suggestions (maybe also start a user survey?).
Reviewing
Please see this PR as two parts. One documentation part and one technical part.
The documentation part is just the first commit (d76538c).
The technical part are all commits after this one.
The technical part is already ready to merge in my opinion. However the documentation part still needs to be reviewed a lot. I put most options into the categories on guessing.
Requested Reviewers
Of course everyone is most welcome to do his review, I would still like a review from @bagder on the selected categories (sorry for 200+ files :P) as he probably knows them the best and a review from @dfandrich as he is the inventor of this idea.
TODO