Paragraph, icon, fonts, settings, sidebar, highlight

[felhasznalonev]

Installed Markpad: v2.7.6 (macOS Apple Silicon).

• If "Line Numbers" is turned off, and "Show Whitespace" turned on, then may necessary to show (even for empty lines) paragraph mark for line breaks (similar like show whitespace in settings).
• If "Table of Contents" is in left side, and hide, and "Line Numbers" is turned off then "Show Table of Contents" icon hangs into written text (application loses its beauty).
• If Typeface (v4.5.0) is used as font manager (Font Book is not used), then Typeface-activated fonts do not load at all, only system fonts of macOS.
• If possible, then would be important to load settings for example from ~/.config/Markpad/config.json or rather from custom path, as well as import/export.
• If possible, then would be important to show opened files (does not exist in sidebar) and switch between "Table of Contents" (does exist in sidebar).
• If possible, then would be important to highlight selected words/phrases/sentences that are identical, and maybe customize color of highlight (customize color of search results same important but does not exist also).

[PathGao]

Thanks — six separate things, so here is where each one lands.

1. Paragraph marks at the end of lines. Not planned. Markpad's editor is
Monaco, the editor VS Code is built on, and it has no end-of-line marker to
turn on: "Show Whitespace" draws spaces and tabs only. VS Code has had the same
request open for years. It could be built by hand on top of Monaco, but it is a
feature, not a fix, and it is a fair amount of machinery for it.

2. The Table of Contents button sitting on the text. This one is a bug, and
it is fixed in #812. With line numbers on, the button floats over the empty
line-number strip; turning them off removed that strip and left the button on
the first ~10px of the text (and on the fold arrows). The fix keeps a narrow
strip when line numbers are off.

3. Typeface fonts not appearing. I need a little from you to know whether
this is fixable here. Fonts pass two separate gates in Markpad: the app asks
macOS for the list of installed families, and then the text is drawn by the
system webview, which is sandboxed and can only read fonts from certain
folders. If the first gate is the problem we can fix it; if the second is, it
is out of our hands and the workaround is to have Typeface put the files in
~/Library/Fonts.

Three questions, with Typeface active:

• Open Settings → the font dropdown. Is the Typeface font's name in that list
  at all, or missing entirely?
• If missing: quit Markpad completely, reopen it, look again. Does it appear?
• Where does Typeface keep the font files — inside ~/Library/Fonts, or in a
  folder of its own (Application Support, Dropbox, iCloud, anywhere else)?

4. Settings from a config file, plus import/export. Enhancement. Today
settings live in the app's own storage and there is no file to point at and no
import/export.

5. Open files listed in the sidebar, switchable with the Table of Contents.
Enhancement. Open files are shown as tabs across the top today; the sidebar
holds only the outline.

6. Highlighting every copy of the selected word. This already exists. Press
⌘P and run "Highlight Occurrences". The colour is not configurable, and neither
is the search-result colour — that part is an enhancement.

Leaving this one open for 3 — that is the only item I need something back on.
The rest are written down above.

[felhasznalonev]

Answers for your three questions:

• Typeface's font name is listed, not missing.
• N/A
• I dont keep Typeface font files in ~/Library/Fonts folder but in my own folder which is synced with my cloud provider (this is one of great features of Typeface).

[PathGao]

Thanks — that rules out the answer I gave you, so scratch the part about the font having to live in ~/Library/Fonts. I tested it: on macOS the webview Markpad draws text with does render a font that another app activated from an ordinary folder, and Markpad itself runs without any sandbox restrictions. Fonts outside ~/Library/Fonts are not the problem, and Typeface's cloud folder is fine as a place to keep them.

While checking that I found a real bug next to it. Markpad inserts the font name you pick straight into the stylesheet without quoting it, and a name that is not a plain word gets thrown away silently — the font appears in the dropdown, you select it, and nothing changes. Any name containing +, (, ), ! or starting with a digit hits this. That one is ours and I am fixing it.

Two things from you so I know whether that is your case:

• The font's exact name as it appears in Markpad's dropdown, copied character for character.
• Does your cloud provider keep those font files downloaded on this Mac, or only online until opened? In Finder, a file that is not downloaded shows a small cloud icon next to it.

What was measured — nothing you need to read

macOS 27.0, Markpad 2.7.6 from /Applications.

• A WKWebView (the engine Markpad renders in) was asked for a family that a separate process had registered with CTFontManagerRegisterFontsForURL at kCTFontManagerScopeSession from a non-standard directory. It rendered: 371.38px for the target span against 337.62px for an installed-font control and 358.38px for a deliberately bogus family, document.fonts.check true. So a font activated by a font manager from its own folder is reachable by the renderer, and the earlier "the webview cannot read it" reasoning does not hold.
• codesign -d --entitlements on the shipped 2.7.6 bundle: no entitlements at all — ad-hoc signed with hardened runtime, no App Sandbox. There is no sandbox gate to fail.
• The unquoted interpolation is MarkdownViewer.svelte:4052, font-family: {settings.previewFont}, sans-serif, and editorOptions.ts:60 hands the raw string to Monaco. With the parent element at 40px Courier, M+ 1c, 04b03, Gill Sans (Body) and Helvetica! each produced a computed font-family of Courier and an identical 264.04px width — the whole declaration is dropped and the element inherits. Helvetica in the same shape rendered at 257.66px.

[felhasznalonev]

I selected some fonts from Google Fonts for testing, and my cloud provider keeps files downloaded on my Mac (sync mode is two way).

[PathGao]

Thanks — that rules out the cloud folder as well, so the file is a real local file and the system can read it.

Here is where this lands. I found and fixed a separate bug in how Markpad applies a chosen font name, and it hits fonts whose name contains a +, brackets, or a number as one of its words — which covers a fair number of Google Fonts families (Source Sans 3, Baloo 2, M PLUS 1p). Before the fix those fonts appear in the dropdown and selecting them does nothing at all, which is exactly what you are seeing. So please try again on the next release and tell us whether it works.

I want to be straight with you about the other outcome. If it is still broken after that, it is probably not something we can fix. Markpad gets the list of fonts from one part of the system and draws the text with another, and when those two disagree about a font there is no lever on our side — editors built the same way have had this open for years, and the only known workaround is to also install the font somewhere the drawing side can see it, such as ~/Library/Fonts. Not satisfying, but I would rather say it now than have you wait for a fix that is not coming.

If it does not work on the next release, the exact font name as it appears in the dropdown, copied character for character, is the one thing that would still help.

Implementation notes — nothing you need to read

The fix is #820: a chosen family now reaches CSS quoted, so a name that is not a bare <custom-ident> sequence applies instead of invalidating the declaration. Measured before and after in a WKWebView, in that PR's description.

On the remaining path, in case it is needed: the dropdown is get_system_fonts, which is font_kit's SystemSource::all_families() over CoreText in the Rust process, while resolution happens in the web content process. Nothing keeps the two in agreement, and the renderer cannot be asked cheaply either — document.fonts.check('40px "NoSuchFamilyQZX"') returns true for a family that does not exist. The only reliable renderer-side probe is a width comparison against two different generic fallbacks: equal to both means unresolvable, measured here as 273.95px/264.04px for a bogus family against 257.66px/257.66px for Helvetica. That would let the list stop offering what cannot be drawn, at one layout pass per family. It is not on the roadmap.

[PathGao]

Thanks for splitting these up — that was the right move. Here is where the seven new ones landed:

• Show a paragraph mark at line breaks when Show Whitespace is on #813 paragraph marks — open, enhancement
• Loading settings from config file and import/export #814 settings from a config file — closed, duplicate of Export, import and load settings from a file #134, which asks for the same thing; your extra details are noted there
• List open files in the sidebar alongside the Table of Contents #815 open files in the sidebar — open, enhancement
• Direct/indirect save #816 closing without saving — closed, duplicate of Persist unsaved/untitled tabs silently instead of prompting to save on close #808 and 自动保存启用了，关闭软件还是提示要保存文件。 #779; the reasoning is in Direct/indirect save #816
• Markpad.app collides with shreyam1008/markpad (Quillpane) on macOS #817 the name clash — answered there, nothing for us to change
• Inline calculator in the editor, like Heynote's math block #818 calculator — open, enhancement
• Focus mode: dim everything outside the current paragraph or sentence #819 focus mode — open, enhancement

One request for next time. Please open feature requests through the enhancement template rather than a blank issue, and give each one a title that says what it asks for. Conflict, Calculator, Paragraph mark — a single word tells me nothing in a list of 280 issues, and I have rewritten all five of them by hand. The template also asks what problem it solves and whether another app does it well, which is usually the difference between a request I can act on and one I have to come back and ask about.

This issue stays open for the Typeface font problem only. The fix for it is in #820.