Skip to content

strict checking for format in condition content #12547

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

Open
cderv opened this issue Apr 15, 2025 · 0 comments
Open

strict checking for format in condition content #12547

cderv opened this issue Apr 15, 2025 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@cderv
Copy link
Collaborator

cderv commented Apr 15, 2025

This is a split from #4411 to handle the strick checking.

Currently when-format and unless-format works through format and aliases, and they could group formats. So there is no easy way to do strict checking.

Previous initial comment on this:

I completely sympathize with @mcanouil's here: we should have a "actually I really do mean this specific format" option. One immediate problem is that any changes to when-format will break backwards compatibility in a way that's hard to track and warn users.

I think the right solution is for us to come up with a consistent naming scheme for what we actually mean by format. The issue is that what goes into a "format" is actually a pretty complicated story. Here's a (probably incomplete) set of issues at play:

  • Pandoc's format variants, such as html+emoji.

  • Convenience under wildcards. We really often want an html wildcard that catches "stuff that a web browser reads". Examples of complications:

    • html5 is technically different from html, and so is revealjs.

    • epub is an "html" "format".

  • quarto's custom formats: acm-pdf

  • quarto's yml schemas depend on formats and format "groups". We should be consistent there, whenever it makes sense to be

  • quarto tells pandoc useful, "harmless" lies about format: a pdf format declaration in a .qmd is actually sent to pandoc as latex; although pandoc supports pdf as an output format, quarto takes over the latex->pdf rendering part of the process.

I actually am now very reluctant to change this for 1.3.

Originally posted by @cscheid in #4411

See original post #4411 for more.

@cderv cderv added the enhancement New feature or request label Apr 15, 2025
@cderv cderv added this to the v1.8 milestone Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant