Brett on 29 Jul, 2014 02:56 PM
Thanks I'll update that doc.
I don't see any practical way to implement "refresh on focus" from a
usability point of view. I'll think about it, but Command-Tab, Command-R
is probably your best bet there. Marked does have a url handler that you
can implement in a script:
refresh all windows: marked://refresh
refresh a named document (can use a partial title):
This will be changing in the next version so that /refresh refreshes
just the frontmost window, and /refresh/all refreshes everything. I
don't know if this is useful in your case, but it's available.
Command-R doesn't work for the "clipboard preview" window, would be an improvement if it did.
Currently I have to - Copy my content in evernote, switch to marked, close the old 'clipboard preview', then hit shift - command - Y
A Command-R would remove one step if it worked.
An on focus refresh from pasteboard would replace 2 steps.
The idea would be that this type of persistent window is either a different type say 'refreshing clipboard preview' or some sort of option. Even better if it could hook the pasteboard event, but not sure that is possible.
Brett on 29 Jul, 2014 06:37 PM
You're correct on ⌘R, forgot about that case. The problem with refresh
on focus is that you have no control, and if you've copied anything else
and happen to focus the document, poof, gone. Hitting ⌘R (or a less
likely shortcut) to refresh from clipboard is an option that I'd
Brett on 23 Nov, 2018 05:42 PM
You should definitely not need such an elaborate workaround for
something that's a default capability. Could you also attach a sample
document with your footnotes so I can verify that the syntax is correct?
Brett on 23 Nov, 2018 06:32 PM
Using the same settings that you showed me, the file above displays as:
I'm honestly not certain what could be going wrong. It's possible that somehow a preference was corrupted and it's not actually using MultiMarkdown. You might try switching to the GFM processor, refreshing, then switching back to see if it makes a difference. Let me know if that helps.
When I switched to GFM, this type of footnote is indeed treated as a footnote: [^somesamplefootnote]. But not this type: [^This is the footnote itself] . That's OK, I don't need the latter type, and perhaps it's not even supposed to be understood by GFM.
When I switched back to MultiMarkdown, I got the same results as I first reported, alas.
That's OK. I have a long track record of uncovering all kinds of weird issues in OS's and applications (perhaps I should have gone into QA!). This must have something to do with my setup (maybe I once installed some markdown libraries that are being picked up in a path variable or something? ), otherwise others would be reporting it.
I'll try using GFM (which I didn't know about before).
When I blog, I write my footnotes manually (per above) -- I don't think my WordPress plugin handles footnotes. My current document is, in contrast, a long academic doc.
Brett on 24 Nov, 2018 02:28 PM
It's so odd that inline footnotes aren't working for you under MMD. It's
a default behavior for the version of MMD that's embedded (and no, the
processor is hardcoded into Marked, it can't be picking up any other
version from your system). I'm at a loss on this one.
If you haven't used GFM (GitHub Flavored Markdown) before, check the
Help->MultiMarkdown Reference for the differences. They're actually
pretty minor at this point, especially now that MMD handles fenced code
blocks. The biggest difference is what it _doesn't_ support. Things like
ABBR, definition lists, etc. For normal Markdown, tables, footnotes,
etc. it's great, though.
Most of the WordPress Markdown plugins do support footnotes (they use
PHP Markdown Extra), though I'm not certain the Jetpack version does.