Support .qmd as an output file extension

Quarto uses the file extension .qmd for its documents, which are basically an extension of markdown (qmd = quarto markdown). Currently if I try to compile using MultiMarkDown to Test.qmd the file saved becomes and quarto refuses to process it. I can make a small wrapper script to rename the output of Scrivener, but if the compiler could allow the .qmd file extension would be better. @AmberV — what is the reason to enforce .md?

What has always worked for me, if I want a custom extension, is to disable the option that automatically adds one. It is found in the file dialogue box: If no extension is provided, use “.md”.

Hi @AmberV, I did try clicking that and got an immediate crash (8.6 KB)

But even on restart, I still end up with .md being appended to the filename.

Hmm, OS version break maybe? I tested on macOS 10.15.7.

I’m on intel macOS 12.5.1 with the latest Scrivener :melting_face:

FWIW, I have the MBP before yours (11,4), running Monterey 12.5.1 and Scrivener 3.2.3, and compiling a simple project to Markdown with a qmd extension works without crashing (and .md is not appended to the compiled file).

Attached now, if you feel like testing the same project on your MBP. (47.7 KB)

1 Like

Indeed using your project I also get just .qmd. However try as I might, I cannot find the difference in the settings, please see if this project generates for you (it does for me): (64.4 KB)

I have both projects opened at the same time, your qmdtest.scriv generates .qmd and my Math.scriv generates on my machine. I’ve tried to copy the Compile format across to yours, add front-matter, change some of the compiler settings all to no avail. The same Scrivener and system, there is something in the project itself separate from the compiler settings driving this at least on my machine…

1 Like

Both the default and the math test compile settings compile with .qmd only on my MBP. (76.2 KB)

If I got the same error that you see, I would be able to investigate the it, but …

Could it be that a setting is persisting from a previous compile? Would a reboot help?

If you copy the files to a new project with a new name, do they then compile with the correct extension?

1 Like

I get the same results as @sobs does: “.qmd” only from all test projects including my own. I am about 90% that this extension override setting, as a function of the file dialogue box, is an opt-in generic Mac system. You will for example find the same switch in TextEdit.

Given that, I agree a reboot—preferably as Safe Boot cycle to flush caches—would be worth trying. You know how Apple can be: why make a simple toggle-state impact a single dialogue box when you can build an elaborate underlying mechanism with hundreds of moving parts?

1 Like

Reboot did nothing (I didn’t safe boot though). Looking at my Scrivener preferences (~/Library/Preferences/com.literatureandlatte.scrivener3.plist) I can see why there is a difference (it is a binary plist but there is a nice VSCode extension that converts to XML for editing, no fussing on the command-line):


If I edit these to <string>Math</string> and <string>qmd</string> then I can compile Math.scriv to Math.qmd without issue. Probably if you use .md for a first save, then this gets encoded in the prefs, and gets “locked in” somehow? I suspect if you edit your prefs plist to <string>Math.qmd</string> and <string>md</string> you will see the same issue, and Scrivener should be updating these settings based on the latest compile rather than the first?

Note I also normally always compile to a folder that has -mmd appended (a compiler trick to keep files), not sure if this has anything to do with it?

I just confirmed if I make a new blank project Temp.scriv and compile it to MMD with a name, then close the document and reopen it, the next time I try to compile to Test.qmd I end up with The prefs show:


Noticed, in the circumstances described by @nontroppo, that if I close the project, rename it, and then compile it again, it will compile as .qmd without appending .md as well.

So the name of the project seems to impact on the persistancy of the .md extension, yes?

Edit: Related to this post by @KB?

1 Like

@sobs, yes, the project name is what the preferences match on, so new project name “resets” the settings for that project :nerd_face:

And yes, I think your link to @KB’s post is bang on the money, good find! The prefs logic to allow these options to carry over make it harder to “unstick” them later on. Not entirely clear what the most elegant rule is that balances utility and flexibility here :upside_down_face:

1 Like

A fine description of LaTeX, I think.

I thought of that 2018 post by Keith when I first started reading this thread (weird but imperfect memory) but then got sidetracked by the crash report. Thankfully the forum search worked well. Think it would be preferable for users to be able to change the extension without having to rename the project.

1 Like

Thanks for digging up that link! That explains a slightly different, though related, problem (it is referring to the hard custom extension setting available to TXT files in the Format Designer window). But the underlying cause is likely pertinent.

What is interesting about this is that I actually cannot reproduce invalid behaviour if I do all of my testing in one session. It seems reloading the project is the key trigger in getting extension stacking. If we try all of this with an ongoing session we get the expected warning dialogues with options to choose one extension or another, and in doing so, setting the extension precedent for the next compile if it changes.

I’ll get it written up. Hopefully it’s an easy fix since it seems to already be working properly, just not on a clean session.