Open elmimmo opened 15 years ago
Assuming you are not allowing your Notes & Settings file to be overwritten, styles in notes are preserved regardless of whether "Plain Text Files" is specified in the Preferences. However, when exporting notes a markdown option would certainly be nice.
Styles are preserved inside Notational Velocity, but not in the local plain text files in ~/Library/Application Support/Notational Data/. That is why I said that those files are lossy when specifying "Plain Text Files" in the Preferences.
If NV is already generating those, I'd like them not to depend on the file "Notes & Settings" and skip having to go to Export command so that I can use the files for other purposes just as they are.
How about interpreting any Markdown syntax already present in the note & rendering bold or italics in the note body when the note contains it? All my notes are already in Markdown, would be great if NV could parse the formatting info in the files & display formatting without having to mark text as bold, italics, etc. again by hand in NV.
I would also like to see some level of Markdown support in NV. I prefer elmimmo's suggestion, with infotexture's a close second. Exporting in Markdown would be nice, but not nearly as useful.
I definitely agree that it would be very helpful to preserve styles over a round trip to plain-text. (And you've already checked out the RTF storage format, right?)
Currently the problem with preserving styles in Markdown is that it might frustrate those who would edit plain text in NV -- especially when that text is deliberately markdown-formatted (e.g., a blog post) -- and then expect to access that text using a plain text editor (in a .txt file, no less). What will they see at this point? A. Double-markdown-formatted text? B. Their exact copy, which would then become styled in NV upon the next external save, thereby losing the markdown formatting?
Some variation of infotexture's suggestion (if I'm understanding it right) might solve that particular dilemma if it meant that NV would always add styles to any markdown syntax in its own editor. Of course then the problem would be for those who never wanted to see markdown at all and just wanted their styles -- all of a sudden they'd see asterisks appearing around bold words any time their file was changed externally.
Extended attributes might provide some more options, but those aren't portable across Dropbox or most file servers.
Am I overlooking something here?
My suggestion was that NV should interpret the Markdown syntax in notes & render it like the Markdown bundle for TextMate does: anything wrapped in double asterisks appears in the NV editor in bold, anything between underscores is italics, text in backticks is monospace
, etc.
You still see the asterisks, underscores and backticks when viewing the file in NV--NV shouldn't ever add or remove any characters on import or export. Just interpret the syntax if it's present and display text accordingly in the internal editor.
To avoid any conflicts such as A or B above, consider deactivating the Bold, Italic & Underline commands in the Format menu when NV is set to Store and read notes on disk as: Plain Text Files
.
While I realize this goes against elmimmo's idea of round-tripping NV's internal formatting to plain text, the result would be more consistent with the idea of plain text. Users interested in preserving formatting can set NV to write RTF files instead.
Coming late to the game. But I think infotexture has it right. Instead of deactivating the Bold and Italic commands when NV is set to Plain Text, why not (again, following textmate's markdown bundle) have them surround the text in the relevant markdown: italic, bold?
Now that NV supports cloud syncing via Simplenote, there is yet another channel where formatting can be lost due to conversion to, and from, text.
I like infotexture's suggestion, if I understand it correctly. My take would be this:
In the NV preferences, add two options: 1) "Embed Markdown formatting." 2) "Hide Markdown special characters."
The first option means: a) Whenever NV imports some text, it detects Markdown and formats bold/underline/italics as dictated by Markdown. b) Whenever (say) the user bolds some text, NV also emits Markdown around the text. c) When NV exports as text, it does no further transformation since the Markdown special characters are already in the "plaintext".
For example, the world "bold" below is bolded, and this is how it would look in NV:
This sentence has a *bold\* word.
The second option means: a) Hide the special characters from display, but still emit them on export.
For example, with this option enabled, the above note would be rendered as:
This sentence has a bold word.
I agree with spudbean. That would be a great implementation.
Markdown notes may also be saved as .mdown files. I wonder if detecting Markdown would be reliable.
spudbean's suggestion rocks.
If you are not going to use .txt, don't use .mdown but .markdown please. Other software such as QLMarkdown for Mac OS X already use that extension for Markdown textfiles.
I love the idea of being able to use basic rich formatting in NV, and having that saved as markdown in the actual plaintext file, and therefore in the simplenote text. I think spudbean has the right idea.
It looks like there's an overwhelming consensus! I'd been thinking that having two settings would be the easiest and most flexible means of implementing this feature, so I'm especially glad to see that elmimmo, the original poster, agrees.
One thing to keep in mind, however, is that neither Markdown nor any of the other structured text systems support underlining, which is one of the only three styles preserved in NV, so you will still be somewhat limited.
One thing to keep in mind, however, is that neither Markdown nor any of the other structured text systems support underlining
Oh I totally forgot about that! Some possible compromises:
1) Bad luck, any underlining is lost when you go NV->Markdown->NV
2) NV emits and interprets underscore as underline instead of italics. Seems hacky.
3) Markdown supports embedded html, so wrap underlined elements with just as you would bold with ** ?
I don't like 2). And personally I don't use underline that much, so (at least initially) 1) sounds better than 3).
I think there's a reason none of these support underline, and I know I've never even thought about using it. I think it'd be a mistake to try and work around by putting html tags into the plaintext; let's keep the output to what markdown supports. That's just my opinion.
QLMarkdown works fine with .mdown, elmimmo.
Had no idea (it does still work with .markdown too). What is the point in abbreviating to 5 characters, though? If only, John Gruber also seems to prefer the full name:
From markdown-discuss ML:
If you're going to go to six characters for ".mdtext", then why not go to eight characters and use ".markdown"? That's what I would use.
http://www.mail-archive.com/markdown-discuss@six.pairlist.net/msg00323.html
(Well, in a previous post he seems to prefer .text over anything, but I think that is silly, his is not the only plain-text-friendly markup syntax out there)
On spudbean's remarks about underlines:
With 1, would synchronizing cause problems (presently or in the future)? I.e. will syncing erase all your underlines under a specific circumstance?
I do not think 2 is a valid option. We should stick to the specification, not create a almost-but-not-quite-markdown version of it. The specification states that _ and * have the same function.
If 1 presents syncing problems, and 2 uses non-standard syntax, I see 3 as the only acceptable option, weather it looks nice or not.
Regarding the Markdown version, I would look at the implementation of this very site. The most significant advantages would be multiple underscores in words and URL autolinking. http://github.github.com/github-flavored-markdown/
I also agree on the usefulness of the behavior of the Textmate Markdown bundle.
Spudbeans prefs suggestion would be great. As for underlining, it's a holdover from the days of typewriters when no other methods of emphasis were available. Since the Web, people tend to associate underlining with links so it's often best to avoid it and just use bold or italics for emphasis. Since I never use it, I wouldn't care if underlining was lost when roundtripping to text files.
To avoid confusion, however, it might be best to disable the just the Underline menu option when menu when NV is set to Store and read notes on disk as: Plain Text Files
(perhaps depending on the state of the Markdown prefs suggested by spudbean).
As I commented above, this shouldn't be a big loss, since people who really care about underlining can still set NV to write RTF files instead.
I was pondering this before I came here, & came to rest at the arragement Spudbean cataloged. It sounds great. I've experimented w/ Steven Frank's fork to insert markdown formatted URIs, and viewing formatted notes from simplenote, both have been very useful - but I am not a fan of the extra pane.
IMO, option no.1 would be at home in prefs>editing, option no.2 would be better suited to the view menu. Not sure if splitting them makes sense though.
Spudbean's preference suggestion is exactly the implementation that I'd like to see. I'm already using markdown to format my nv notes, thankfully markdown is very human readable even without any reformatting. TextMate style markdown display would be nice though.
I also agree with Spudbean, adding Markdown support in this manner would be an excellent enhancement.
I'd be most thankful to receive some update on this topic by the developer. So I wanted to ask kindly if there is a roadmap when markdown support might be implemented. I'm very eager to have a nice - lossless, that is - syncing system for notes between OS X, iOS and Windows/Linux.
ashcroft, I've had a parser for nested range-based styling (which still doesn't fully answer the problem of mixing rich styles with Markdown styles in an RTF doc), but my priority is fixing the issues involving syncing via proxy servers, Unicode (de)composition during search, and handling upcoming changes to the Simplenote service.
I'd like to suggest that Markdown's syntax isn't really a great match for NV. As scrod mentioned already, Markdown doesn't support underlining. And technically, it doesn't explicitly support italic or bold formatting, either -- rather, it uses the semantic categories "emphasis" and "strong", each of which has syntax alternatives that look like both underline and bold as they've commonly been indicated in plain text email.
Personally, I like the txt2tags (http://txt2tags.sourceforge.net/) syntax (bold, //italic//, and underline) better for this purpose. I think the meaning would be more immediately obvious to folks who don't use Markdown and it's a better match for NV's current formatting options.
I'd like to pile on and add a few +1s to spudbean's markdown suggestion. Markdown was designed for this very purpose, writing in plain text. It matches quite well to NV, imo.
Using GitHub's flavour would be great, but not critical. Losing underlining is a nice bonus as far as I'm concerned, but as someone mentioned above, keep it for the RTF option if necessary.
Reminder: Markdown "supports" underline in the form <u>…</u>
, because HTML is allowed, and Markdown parses within inline elements like <u>
.
<u>Try *this* in any Markdown environment (**not**
GitHub though, they strip `<u>` tags).</u>
+1,000 for Markdown support, spudbean has it right I think.
I'm not sure how wise implementing GitHub Flavored Markdown would be considering it is a non-standard implementation of Markdown and would not work in the many situations outside of GitHub. I do agree that it is probably an improvement on the original, but since it is not standard, it could have unpredictable results elsewhere.
@spirulina
I think the main reason people want to use Markdown is that they use it in their day to day work (e.g. blog post writing, README files, etc...). Something more obscure like txt2tags would be useless for those of us who want Markdown support in the editor for that reason. I agree the formatting makes more sense for non-Markdown-friendly users, but the whole point of Markdown support is for those users.
@alanhogan
I think the point is that people are saying that using <u>
is not a native Markdown tag, but instead HTML. I agree that would be a solution, but it could not work for some people. I can think of one use case where it would cause problems: Markdown documents for things like README files that cannot handle HTML like here on GitHub. I'm sure there are other reasons why that would be a potential problem though. Embedding HTML into a document that is meant to be plain text just doesn't seem to make sense if it was not intentional in the first place.
@panicsteve made a fork of nv with markdown support:
That package is quite a bit out of date, being last updated almost a year ago.
I'm looking for all the new hotness of 2.0b4!
There is a more recent fork by Brett Terpstra named NVALT http://brettterpstra.com/code/notational-velocity-alt/
malvese,
Brett's fork is currently quite a bit older than version 2.0B4.
Here's a list of the features and fixes it lacks: http://notational.net/releasenotes/release2/#b4
@scrod, oh 2.0b4 is out since yesterday, no wonder NVALT has not been updated yet. Sorry I didn't notice it was a new beta, I had beta 3 in mind. Is it a merge with Brett's work? Just wondered as the icon is now quite similar and some of the new features were part of his fork.
Version 2.0B4 doesn't use any of Brett's code. You can read the blog post for more information: http://scrod.posterous.com/notational-velocity-204
Yes, scrod is right. I tried using it just now and it didn't even open. Didn't really seem to do what I wanted anyways...
I also miss this feature. Have you checked JustNotes?
It uses a user preference if you want to enable markdown-like formatting (a very small, subset, just bold, italic and headers), and does so with live preview, unlike nvalt.
I really liked the solution implemented by JustNotes, it would work perfectly for me.
I'd also love^2 to have Markdown (or Multimarkdown) support, with the two options spudbean has suggested!
1) There's a huge amount of people like me, academics (and the students we teach) who need to keep formatted text while backing things up or using text cross-platform.
2) As far as underlining goes, MLA (one of the main citation styles) just recently made underlining obsolete, with everything formerly underlined now put into italics. I can only imagine that with underlining being commonly used to indicate hyperlinks, its use is only going to wane further for regular text uses.
3) Markdown (or MMD) are already becoming pretty much the standard, it seems. Scrivener uses it, which syncs to Simplenote, which syncs to NV, which is connected to the hip bone, etc. You developers probably already know this far better than I do.
4) Thanks for making such an awesome tool, by the way!
For the record, Simplenote's built in Markdown support includes HTML including the <u>
tag. It shouldn't be a blocker. Who uses underline anyway ;)
I am all for the @infotexture + @spudbean solution... I would like to also suggest that we ensure that H1, H2, links, etc all keep that same pattern of rendering with both markdown syntax AND output styles, but keeping files as pure markdown (unless a setting has otherwise been checked).
What happened to this feature request? This issue was closed by pointing to issue #291, which was also closed and linked back to this issue.
I am still very interested in having live markdown. I.e. no need to preview, but displaying bold, italics, headings etc. in the editing view.
Any thoughts on this?
@psychomachine, I haven't tried this out, but nvALT sounds like a possible solution. See for instance this website: http://brettterpstra.com/project/nvalt/ and his github repo: https://github.com/ttscoff/nv.
nvalt does not seem to have a live markdown . Any alternatives?
It would be nice if keeping notes or exporting in Plain Text Files would still be lossless by keeping text formatting using markdown syntax http://daringfireball.net/projects/markdown/syntax