Skip to content
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

Open
wants to merge 71 commits into
base: master
Choose a base branch
from
Open

Overhaul of the Manual #3189

wants to merge 71 commits into from

Conversation

01mf02
Copy link

@01mf02 01mf02 commented Oct 9, 2024

In the last days, I've completely overhauled the jq manual. Some of the most important changes:

  • I've regrouped the chapters. I tried to make it such that the chapters build on each other; for example, to explain basic filters such as |, it is useful to know how to construct values first, and to understand paths such as .posts[0], it is useful to understand | first.
  • To help with finding the information, the TOC can now be expanded to show subsections of sections.
  • I've annotated many filters with compatibility notes that document divergent behaviour for other implementations. Currently, this covers mostly my own jq interpreter jaq, but I expect this to be useful too for gojq.
  • I've reworked the visual appearance of the man page, such that longer blocks (such as examples or notes) are visible as such.
  • I've corrected bugs in the manual as I went along; for example, the behaviour of arithmetic-update assignments.
  • I've also added a large number of new examples.
  • I significantly reworked the sections on paths, definitions, and assignments. These are nearly rewrites.

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, run pipenv sync, then

pipenv run python3 build_website.py --root /output && python3 -m http.server

and 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).

Screenshot 2024-10-09 at 16-40-21 jq Manual
Screenshot_2024-10-09_16-37-28

@01mf02
Copy link
Author

01mf02 commented Oct 18, 2024

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.

Copy link
Member

@wader wader left a 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/filters/filter.lua Show resolved Hide resolved
docs/content/manual/manual.md Show resolved Hide resolved
docs/content/manual/manual.md Show resolved Hide resolved
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.
Copy link
Member

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"?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added in 80ebbfe.

docs/content/manual/manual.md Show resolved Hide resolved
docs/content/manual/manual.md Outdated Show resolved Hide resolved
docs/content/manual/manual.md Show resolved Hide resolved
:::


# Managing large programs
Copy link
Member

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?

Copy link
Author

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.

docs/content/manual/manual.md Outdated Show resolved Hide resolved

`empty` returns no results. None at all. Not even `null`.

It's useful on occasion. You'll know if you need it :)
Copy link
Member

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?

Copy link
Author

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.

@pkoppstein
Copy link
Contributor

@wader wrote:

also i think personally i would rather merge early, as it includes so many improvements

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?

@01mf02
Copy link
Author

01mf02 commented Oct 30, 2024

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.

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.

Read/Edit directly in markdown is much nicer than yaml i would say

Yes, that's also why I did this change in the first place. :)

What to do with old versions of the manual? Keep as is? Try move things into one big manual with version compatibility section etc?

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.)

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.

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 ...

@wader
Copy link
Member

wader commented Oct 30, 2024

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.

No worries! hope they are useful

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.)

Yes that is a good idea i think. Would that be per implementation?

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 ...

Yeap would be great

@01mf02
Copy link
Author

01mf02 commented Nov 14, 2024

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.

@01mf02
Copy link
Author

01mf02 commented Nov 14, 2024

(I also integrated all changes to the manual in master since the opening of this PR.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants