-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Overhaul of the Manual #3189
base: master
Are you sure you want to change the base?
Overhaul of the Manual #3189
Conversation
Sorry to spam you again, but: @wader, @nicowilliams, @itchyny, @pkoppstein, @emanuele6, may I ask you what the status is on this PR? I've invested quite a significant amount of time into this, and it would be nice to have at least some basic feedback (which @pkoppstein has already given). If you have concerns about certain parts of this PR, then I'd be happy to address these. |
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.
Nice work! note that as i'm reading thru nearly all of the document I might have added comments about texts that are already present.
Some questions/issues/reflections:
- Read/Edit directly in markdown is much nicer than yaml i would say
- What to do with old versions of the manual? Keep as is? Try move things into one big manual with version compatibility section etc?
- How to get it merged? approval from 3 maintainers is enough? also i think personally i would rather merge early, as it includes so many improvements, and then fix up stuff in further PRs rather than keep iterating on the same PR for a long time. That would also maker it easier to work in parallell.
docs/content/manual/manual.md
Outdated
For instance, when the input value is an array, | ||
the filter [`.[]`](#iteration-operator) yields all the elements of the array. | ||
Even literals like `"hello"` or `42` are filters --- | ||
they take an input and produce the same literal as output. |
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.
Maybe be even more explicit like "they take an input, that is ignored, and produce the same literal output"?
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.
Added in 80ebbfe.
::: | ||
|
||
|
||
# Managing large programs |
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.
Maybe in the future this could also include a section about debug techniques etc?
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 would be a nice idea.
|
||
`empty` returns no results. None at all. Not even `null`. | ||
|
||
It's useful on occasion. You'll know if you need it :) |
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.
Maybe we could mention backtracking and use in recursive functions here? or refer to the section about functions and recursion?
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 personally do not see a special link between empty
and backtracking/recursive functions. empty
can be useful in so many ways. I'm actually not sure whether empty
or .
is my favourite filter. ;)
I would leave it as it is for now, given that this is what the original docs say about empty
.
@wader wrote:
I wholeheartedly agree. In particular, I hope that any potential revisions regarding gojq won't hold things up. Indeed, there's a lot to be said for waiting until the jq+jaq version of the manual has been merged before embarking on a gojq-related project. Perhaps that's something @itchyny might be willing to undertake? |
Sorry to answer a bit late --- I have been quite busy with other stuff, and did not have the time so far to integrate your comments.
Yes, that's also why I did this change in the first place. :)
I would propose to keep the old versions of the manual up to (including) 1.7, and to start annotating the current version with compatibility notes for added/changed functions. That way, finding out which functions are available in older versions of jq should become much easier, because you have the information in the manual. (Nowadays, you would have to browse through all manuals from previous versions until you do not find a reference to a function anymore.)
Of course, I do not have a say in this, but I wholeheartedly agree with this. It would be really great if some other maintainers would speak up here ... |
No worries! hope they are useful
Yes that is a good idea i think. Would that be per implementation?
Yeap would be great |
OK, I have now integrated all relevant suggestions by @wader, and updated the man page / tests. From my point of view, this is now ready. |
(I also integrated all changes to the manual in |
In the last days, I've completely overhauled the jq manual. Some of the most important changes:
|
, it is useful to know how to construct values first, and to understand paths such as.posts[0]
, it is useful to understand|
first.All in all, this PR adds a lot of new information to the jq manual and tries to improve its structure.
To see it in all its glory, you need Pandoc >3.0. Go to
jq/docs
, runpipenv sync
, thenand open http://0.0.0.0:8000/output/manual in your browser.
Please let me know if I can do something to get this merged.
This builds on and supersedes my previous PR (#3186).