Add previewStyles to CustomTheme for styling the preview pane

[akurach]

Follow-up to the discussion in MarkEdit-app/MarkEdit-theme-duotone#1: instead of each theme hand-injecting a <style> element, themes can now declare preview styling as configuration.

• CustomTheme gains an optional previewStyles?: string — CSS targeting the .markdown-body selector of MarkEdit-preview.
• The package maintains a dedicated style sheet and applies the active variant's previewStyles inside updateTheme, so it follows color-scheme changes, app theme switches, and the existing enabledMode gating for free. No media queries needed in theme code.
• The style sheet is created lazily (??=) because the shared __markeditTheming__ context may have been initialized by an older bundled copy of the package in another theme.
• It is a no-op when the preview extension is not installed, and when previewStyles is not provided.

Usage:

overrideThemes({
  light: { extension, colors, previewStyles: '.markdown-body { background: #faf8f5; }' },
  dark: { extension, colors, previewStyles: '.markdown-body { background: #2a2734; }' },
});

dist/ rebuilt with yarn build (lint passes). Once this lands and is tagged, I'll update the DuoTone PR to use the new field.

[cyanzhong]

Thanks for starting this. I was expecting something more strictly typed.

For example:

.markdown-body {
  background: #2a2734 !important;
  color: #eeebff !important;
}

Intead of having these as "string", we can have it as:

previewStyles: {
  markdownBody: {
    background: string;
    color: string;
  }
}

[akurach]

Reworked to a strictly typed configuration — no raw CSS strings anymore.

previewStyles is now a PreviewStyles object with per-element groups: markdownBody, headings, links, inlineCode, codeBlocks, blockquotes, tables (incl. alternatingRowBackground), and dividers, each accepting color / background / borderColor where applicable. The package generates the css internally (preview.ts, emitted as dist/preview.d.ts alongside colors.d.ts).

overrideThemes({
  dark: {
    extension,
    previewStyles: {
      markdownBody: { background: '#2a2734', color: '#eeebff' },
      links: { color: '#9a86fd' },
      inlineCode: { color: '#ffb870', background: '#36334280' },
    },
  },
});

Happy to adjust the group/property set if you'd prefer a different shape.

[cyanzhong]

Can you revert unrelated source code re-format?

[akurach]

Done — reverted the unrelated reformatting and squashed into a single commit. index.ts is now additions-only (+16 lines) against main.

[cyanzhong]

Sorry, I spent some time thinking about the relationship between the editor theme and the preview theme.

It looks like the changes in this repo and https://github.com/MarkEdit-app/MarkEdit-theme-duotone are actually quite loosely coupled.

What if we simply add the new preview themes to https://github.com/MarkEdit-app/MarkEdit-preview/blob/5b67059c116966ccbd0794d444864bb264f010c3/src/styling.ts#L50?

That way:

• We can use CSS variables instead of !important, which gives us more predictable results and avoids the code smell.
• The editor theme doesn't need to know anything about the preview theme, giving us a cleaner separation of concerns.
• Custom themes don't need to be updated, which reduces the maintenance cost.
• The trade-off is a few extra kilobytes for themes that aren't installed, which seems reasonable since users can use these preview themes without installing the corresponding editor themes.

[akurach]

Before I go ahead, let me make sure I understand the direction correctly.

Do you mean that preview themes should live in MarkEdit-preview's built-in catalog (previewThemes in styling.ts), and that this effectively becomes the workflow for theming going forward — i.e. a theme author ships the editor theme as its own extension repo, and then additionally PRs a preview counterpart into MarkEdit-preview?

Two data points to consider:

1. The registry currently has 10 theme extensions (basic, catppuccin, duotone, gruvbox, noctis-lilac, nord, one-dark, quietlight, tokyo-night, vscode). Applying this approach consistently means porting all of them into the preview and keeping the two repos in sync whenever a theme changes.
2. Catppuccin has four flavors (latte / frappé / macchiato / mocha, configurable in the extension), which doesn't map cleanly onto the preview's single light/dark-variant-per-theme model.

If the catalog approach is still what you prefer, I'm happy to start with a DuoTone port and follow up with the rest. Just want to confirm before creating a pile of PRs in the wrong direction.

[cyanzhong]

You asked a very interesting question, it looks like we really don't have a way to cleanly separate the responsibility due to the current architecture.

A worse situation is: I am not even sure how "auto" themeName (in https://github.com/MarkEdit-app/MarkEdit-preview) would work for custom themes, theme extensions don't replace existing themes, they just override colors.

[cyanzhong]

theme extensions don't replace existing themes, they just override colors.

I guess your current approach works for this quirk because as long as a
theme extension is applied, preview styles are forced in theme extensions.

That's quite interesting...

[cyanzhong]

Maybe your current approach is closer to the correct direction.

However I don't quite get how auto would work still.

Let's say I set the editor theme to GitHub and used a custom theme like VS Code, editorConfig would say GitHub instead of VS Code.

In MarkEdit-preview changes, how would the auto theme pick colors from VS Code?