strict checking for format in condition content

Open
#12,547 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
javascript
Domain
cli, content

Research direction

The issue names no files, tests, or entry points. Start by reading the original discussion in #4411 and the quoted format and alias cases; the work is done when the project has an agreed strict-format behavior that addresses those cases without leaving backward-compatibility expectations unresolved.

Written by the indexing model from the issue text.

Description

enhancement

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.

Dominant language
JavaScript
Stars
6k
Forks
458
Avg merge
1d 9h
Merged PRs (30d)
41

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from quarto-dev/quarto-cli

All issues in quarto-dev/quarto-cli

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.