Live data from Hacker News

If it is worth keeping, save it in Markdown

p.migdal.pl

271–280 of 282 posts

Re: If it is worth keeping, save it in Markdown

#271
post #205

Also, as an old person, I will tell you that 1) I got my first personal computer in 1979 and have been trying to keep my bon mots archived ever since. I have tried a million things and have learned one key lesson: It's not really worth it. I literally have a footlocker filled with old disk drives (remember, since 1979!) and I have never, ever gone back more than a few years, hell, more than a year. Now that disks are…

Similar perspective, but I'd offer a minor tweak. Just as before gmail people spent a lot of time "managing" their email. Gmail allowed us to stop bothering and just use search to find stuff among the now-messy volume of email. It works pretty well. Similarly, I'd say save everything, but spend no time on organizing it, relying on search and ai/future technology to find what you want from among the mess.

I'm a big fan of general search.

Re: If it is worth keeping, save it in Markdown

#272
post #251
post #60

Earlier quoted context omitted.

Do you use any plug-ins for that? Obsidian tells me it only supports Obsidian Sync and iCloud out of the box.

You don't have to use any plugins. You can put your obsidian vault anywhere you like, e.g. in a folder that is synched by nextcloud. I use a git repo for this, which works fine also on mobile.

I get how that works on desktop, but on mobile, I can add a local file as a vault in Obsidian, but I don't think that file could be tracked by my cloud sync app. Does the Nextcloud app support that? Not sure how you use git here, could you explain?

What I have gotten to work was to download a file from the sync app, open it in a markdown editor app and then save it to the cloud by sending it back to the sync app. It technically works but it was a bit too inconvenient to become a real habit (too many taps, need to rename the file on upload and set location each time,...).

Re: If it is worth keeping, save it in Markdown

#273
post #84

Earlier quoted context omitted.

I'm not the parent commenter but I'm going to guess because HTML is horrible at WYSIWYG. If your editing tool changes or if your switch editors, they will all botch your HTML anywhere you make edits. RTF is basically "it just works," very much like "Microsoft Word Light."

Your complaint seems to be about the editors, not HTML.

Yes, my complaint is about the editors. But it's also a problem with HTML because with HTML you can implement a document that looks the same using multiple techniques, so editors will always have code generation differences.

Re: If it is worth keeping, save it in Markdown

#274

I've landed on a workflow that I like a lot, and have shown to several people on my team. I use Google Drive for Desktop, which maps the G:\ drive to Google Drive. From there, I use VS Code for Markdown editing. Google Docs now supports Markdown files, so if I need to convert the Markdown file to Word or PDF, I just open it in Docs and download it in the format I need. (Pandoc also works for this, as the author menti…

But why should you need to convert it? Why does no one call out the giant problem with Markdown: the lack of READERS?

I rarely need to convert markdown documents, but sometimes I need to produce a report for a client or a non-technical internal reader.

Re: If it is worth keeping, save it in Markdown

#275

Earlier quoted context omitted.

But why should you need to convert it? Why does no one call out the giant problem with Markdown: the lack of READERS?

People read documents, not formats.

Exactly. So why are we supposed to read Markdown full of embedded codes?

Re: If it is worth keeping, save it in Markdown

#276

Earlier quoted context omitted.

But why should you need to convert it? Why does no one call out the giant problem with Markdown: the lack of READERS?

I rarely need to convert markdown documents, but sometimes I need to produce a report for a client or a non-technical internal reader.

Exactly. The problem isn't converting; it's viewing.

Re: If it is worth keeping, save it in Markdown

#277

Earlier quoted context omitted.

Those are all PDFs. Why, if Markdown is so great?

Not OP but I've done similar work myself. Alternatives for authoring PDFs include LaTeX or similar markup languages, or GUI-based tools. For many works, Markdown is more than sufficient for producing book-length texts (I've done this numerous times myself, either authoring my own works or transcribing/modifying books for improved access/readability). Markdown's benefit is that it is extraordinarily lightweight , and…

I'm not arguing that we need more than Markdown; just the opposite.

The publication of all those as PDFs INSTEAD OF Markdown testifies to Markdown's big problem: the lack of readers (viewers) for it.

Re: If it is worth keeping, save it in Markdown

#278

Earlier quoted context omitted.

The biggest problem with Markdown is the baffling lack of plain VIEWERS. Not editors with a preview pane, but straight-up viewers that render Markdown for reading. There are very, very few. I use Marked 2, for Mac. I don't even remember if I ever found another one. It's irritating as hell, because pretty much every open-source project's read-me files are in Markdown. Why, when there is no viewer anywhere near as ubiq…

Makefile-driven development. Run "make pdf" as needed (looped in a shell one-liner if you prefer, or driven by an event watcher). A decent PDF viewer will either reload the document automatically on change or can be readily reloaded. The Suckless PDF viewer zathura is among the former, I've also used, variously, xpdf (slightly grungy these days but an old reliable) or MacOS's Viewer app. https://pwmt.org/projects/zat…

Why should you have to make a PDF? It would be even easier to have a live Markdown-editing window with preview... or better, just a WYSIWYG Markdown editor.

Re: If it is worth keeping, save it in Markdown

#279

Earlier quoted context omitted.

Not OP but I've done similar work myself. Alternatives for authoring PDFs include LaTeX or similar markup languages, or GUI-based tools. For many works, Markdown is more than sufficient for producing book-length texts (I've done this numerous times myself, either authoring my own works or transcribing/modifying books for improved access/readability). Markdown's benefit is that it is extraordinarily lightweight , and…

I'm not arguing that we need more than Markdown; just the opposite. The publication of all those as PDFs INSTEAD OF Markdown testifies to Markdown's big problem: the lack of readers (viewers) for it.

https://daringfireball.net/projects/markdown/syntax#philosop...

"Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions."

Any text editor (Notepad, TextPad, (neo)vi(m), Emacs, TextMate, Apostrophe, GhostWriter, Typora, etc.) will do. Markdown-specific editors have either a real-time preview or the ability to edit as WYSIWYM:

* https://keenwrite.com/ (mine, FOSS, cross-platform)

* https://pandao.github.io/editor.md/en.html

* https://markdownlivepreview.com/

* https://stackedit.io/

What do you mean by lack of readers?

Re: If it is worth keeping, save it in Markdown

#280

Earlier quoted context omitted.

Makefile-driven development. Run "make pdf" as needed (looped in a shell one-liner if you prefer, or driven by an event watcher). A decent PDF viewer will either reload the document automatically on change or can be readily reloaded. The Suckless PDF viewer zathura is among the former, I've also used, variously, xpdf (slightly grungy these days but an old reliable) or MacOS's Viewer app. https://pwmt.org/projects/zat…

Why should you have to make a PDF? It would be even easier to have a live Markdown-editing window with preview... or better, just a WYSIWYG Markdown editor.

You can substitute whatever output endpoint you'd prefer, e.g., ePub, HTML, etc., if PDFs don't satisfy your personal itch.

I happen to generally be aiming for PDF output, it's among the more complex to produce, and still runs pretty much without concern even on very large documents. Anything else would be even more trivial.

Post reply on HN