-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
better "Defaults file" documentation #5990
Comments
Yes, please do share. |
Will do, but I have to extend it to all entries first. |
Here it is. A complete list of command line options (according to Markdown source and pdf: It would be good if you could have a look, there are a few things I could not figure out, and others where I'm not certain I got it right. Let me know, and I'll make a new version. One thing that is confusing me particularly: If I understand the YAML specification correctly, an omitted value is interpreted as I also see some (unnecessary?) changes from command line options to defaults file entries. Generally,
So far, so logical. Deviating from that:
A more consistently logical translation could make this table unnecessary. On the other hand, this table could serve not only as a documentation of defaults files, but as a general option reference. For that purpose, I would separate it into several sections, e.g. options affecting the reader, affecting the writer, affecting variables / metadata, and helper options (the last 11). And I still think it should be an "options file", option |
The defaults file corresponds closely to the structure of the
This was me not remembering what the option actually was (since I never use these variants).
I think we should keep allowing the list, but also allow a non-list value (treating it like in options).
See above.
I think this is fine the way it is. "metadatas" is not a word anyway ("metadata" already being plural).
That's what we've done for the options in the manual; keeping the same order for this would make sense I think.
This was discussed in the original issue for the defaults file. Two reasons I don't like |
To answer your questions:
One other thing: currently this table is too wide to fit into the standard of |
Oh, and aside from fitting into 80 columns in the markdown source, we need the table to render well in 80 columns for man page use, and to render in LaTeX in portrait mode. (Unless this is to be a separate document.) |
|
I could use a definition list instead of a table, that should fit better? |
How about
Good point. But command-line options are arguments, too, right? Then |
Technically you're right, they're all arguments: I guess I meant "mere arguments." |
Hm, but that's exactly my problem: "defaults" doesn't make sense to me. In my understanding, a "default" is a fallback. Just like Pandoc's default templates: They are used if the user does not explicitly request a specific template. But there is no falling back upon "defaults files", they are functionally equivalent to command line arguments, explicitly requesting something. There is some sense in applying the name "default" to the files in There could be "default arguments" proper, if Pandoc were to automatically use e.g. Sorry if I'm being overly pedantic... |
A few updates:
|
|
I do think of these things as fallbacks. For example: normally, pandoc creates a fragment unless Note that the fallbacks specified in a defaults file can be overridden by further options on the command line. So, if your defaults file says |
I didn't like having a single yaml entry spanning two table cells, so I redid this with code blocks in a grid table.
|
Good! Are you going to integrate this version into the manual? |
I've been having trouble making it work. The problem is the large margin we currently get with block-level content in table cells in man page output. I've been experimenting with some changes |
To get a sense for it, save this as
|
Interestingly, if you comment out lines 3-6, the table looks good. |
Somehow missed your reply... You're right, there is a lot of wasted space. Maybe revisit the idea of using a description list instead of a table? |
I'd like to figure out how to make the man table output better if possible. |
Here's a slightly modified test case.
|
I suppose we could just use a single code block in tabular form... |
I'm afraid I don't know the first thing about roff. The roff code is generated from the Markdown by Pandoc I assume? If so, that sounds like there is a problem with the roff writer. There are three people incl. email adresses listed on the groff page: |
Note: |
Thanks for the update! After thinking about it again, I believe now that it would be better to mention the defaults-file version at the same place where the command line option is described. For example like this: For this I just hacked a bit of What do you think? |
I'd prefer not to depart this far from standard practice in presenting option lists; I think that might be confusing. |
Fallback data is normally that used when a preferred set is unavailable or unusable. Yet the so-called defaults would often be given as a primary set of data to apply. Although command-line options would take precedent, they would be more often used to override select fields for a certain use, not to represent a complete set of options that hopefully remove the need for any other data set designated as fallback. I tend to agree with @allefeld that the conceptualization as defaults or a fallback is confusing and possibly misleading.
The Previously the choice was made to choose a word whose initial was not currently used in lower-case form in the set of short options. I am having growing doubts that this restrictions is having a good effect on final design. I further suggest that accepting that the file name as an undecorated (positional) argument, and inferring its meaning based on inclusion of some designated extension (e.g. |
This is true. I did some testing, and I found that the values in the defaults files aren't just a fallback. I tried adding
This indicates that Further, there is inconsistency in this order of precedence depending on the flag/variables/metadata (CSS, for instance, behaves differently). Full comment here: #3139 (comment) |
"Fallback" isn't quite right, that's true. It's more like a replacement for command-line options you could specify on the command line; they agglomerate when the corresponding command line options would. I don't know if it would be a good idea to change the terminology at this point, though. |
Building on John's comments, and trying to be fair to what I understand as the original intention, fallback and defaults would express a relation limited to that between the contents of such files and command-line arguments. Strictly, rules for processing metadata fields are not in conflict with this relation. Overall, of course, nuances of such kind are difficult for a user to capture without making a serious study of them. |
I see no problem in the term "defaults". But I do think orders of
precedence + when the items aggregate, when they take the left-most, when
they take the right most, and when they replace, should be clearly captured
in the manual.
And ideally, there should be one standard rule that can be described in the
manual, with any exception being for clearly stated reasons and also
described accordingly.
…On Tue, 13 Oct, 2020, 04:50 brainchild0, ***@***.***> wrote:
Building on John's comments, and trying to be fair to what I understand as
the original intention, *fallback* and *defaults* would express a
relation limited to that between the contents of such files and
command-line arguments. Strictly, rules for processing metadata fields are
not in conflict with this relation.
Overall, of course, nuances of such kind are difficult for a user to
capture without making a serious study of them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5990 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXQE6FERZHUB6MTACQI5UDSKOFKDANCNFSM4J2W6SNQ>
.
|
The earlier part of the manual probably should be revised so that defaults is not given to the user only as some later revelation. (I have been away from this subject for some time, but last I remember, questions of the sort concerning stable aggregation rules had not been firmly resolved.) |
Perhaps you're right. But it would be useful to provide a three-way comparison between valid command-line options, in-file metadata / metadata file options, and the defaults file option. (I tripped up today, trying to use |
Hey, so following along this path (and to help with some automation on my end) I've been working on a JSONSchema for pandoc defaults files. Thanks for the documentation here - It made it a much easier process. I've run into a few inconsistencies between the latest output in this issue (albeit from Dec 2019) and the pandoc defaults file example in the manual. Would someone be able to chime in here with which is more current / correct?
defaults-narrow.txt: metadata:
bibliography: string
csl: string
citation-abbreviations: string pandoc manual csl: ieee
bibliography:
- foobar.bib
- barbaz.json
citation-abbreviations: abbrevs.json In short, should they be keys under metadata, or just root keys? And is bibliography a string or an array? Either way, thanks again for the documentation. It has been quite helpful working with some CI systems lately! |
If they're at root, they behave like the corresponding command line options. But what the command-line options do is set a metadata field. So, the answer is: either!
Either will work. |
Since this discussion did veer somewhat toward argument precedence, I hope my question will not be out of place: If I specify, e.g., |
I suppose this effect would require expanding the user interface, for example, to support arguments of the kind |
I would like to bump this issue, since I keep forgetting the defaults file entries. |
I have created an updated version of the mapping table, based on jgm's version from by now more than 2 years ago: defaults.md In doing so, I found a few inconsistencies: There are two command line options without apparent defaults file equivalent: @jgm I'm not sure whether you are still interested in integrating this into the manual? |
@allefeld this would be welcome, yes. I think it would be an improvement over what we have now, although there are a few comments in the commented defaults file we now include that may be useful to include somehow (footnotes?, endnotes?). I don't know why those options are missing. |
If you use grid tables, column widths should be the same if they are the same in the source. |
And, maybe submit another issue asking for |
This is closed by #7872. |
The documentation under Defaults should be improved, for example like this:
I can share the underlying Markdown code, and also extend it to include all possible entries.
The text was updated successfully, but these errors were encountered: