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 |
Fixed in dd873f69bfc3a707ffb7c6114b6ef9f531e79087 |
dd873f6 to
af4dd10
Compare
|
I re-ordered the commits into a more logical order |
docs/cmdline-opts/append.d
Outdated
There was a problem hiding this comment.
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.
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.
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.
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.
Most options only belong to one category. The plural would sound weird there in my opinion.
In your code you are already referencing categories:
https://github.com/curl/curl/blob/af4dd100c6da95af1c3491de24a4a04f43326c1f/src/tool_help.c#L119-L123
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.
@bagder I'm not sure to understand you point of view 🤔 ; 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.
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
curlshould rather be renamedtooland 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.
Sounds good to me, your position @emilengler 😃 ?
There was a problem hiding this comment.
I will have a deeper look on this at Sunday or Monday. I am currently on vacation
There was a problem hiding this comment.
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 |
|
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 |
sterchelen
left a comment
There was a problem hiding this comment.
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 (d76538c9e9ef27b5b4c2ee06bce8c45c810c57e6).
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