Live data from Hacker News

If it is worth keeping, save it in Markdown

p.migdal.pl

231–240 of 282 posts

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

#231
post #156

Markdown is great, but not a panacea. Tables, in particular, just suck, especially if you want to have even slight formatting inside of the cells. Unfortunately, it’s either plain-text-readable or rich representation. Pick your poison.

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…

I use Markdown Viewer, in Chrome: I'd bet there are multiple equivalents in Firefox and Safari. Well. I don't know what Safari's extension universe is like but it seems likely.

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

#232
post #146

My pain is that I couldn't find a decent md viewer for Windows: free, fast, simple, no distractions. Imagine notepad. I have to open my md files with VSCode or Notepad++ (nasty view).

Try this one: Markdown Viewer. Other than the larger size that comes with being based on Electron, it's all quite good. https://github.com/c3er/mdview

Thanks. It looks pretty decent. And more important is the first one being just a reader/viewer not an editor with preview.

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

#233
post #203

Earlier quoted context omitted.

I think they're mixing the GH web ui with the syntax. You can paste an image right into the editor and it does a really good job of inserting it right where you need to. It is really good UX that I miss when editing markdown locally. Obsidian also does a decent job, but not quite as smooth.

Sounds like powerful lock-in for Github. How could such a project ever decamp to Gitlab or Codeberg?

So I also do use gitlab quite a bit, but not as much recently. I went to compare. Gitlab actually does have a similiar ux experience, though I'd give the Github one just a bit of an edge. It looks like the key difference is that github converts a pasted image to an html image tag, while gitlab uses markdown with the width/height brackets that the end.

Honestly, I think using an html image tag is the right way to go. I type in markdown all the time, and I have no problem making links. But markdown image syntax I have to double check each time or let the editor figure it out. HTML image tags, I find easier to remember and read than a markdown one. (But maybe that's because I learned HTML before markdown).

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

#234
post #26

Earlier quoted context omitted.

I like Commonmark but I wish it would have been more opinionated. They chose to allow two ways to do everything[0]. Making * always be used for bold and _ always for italicizing is so much clearer, and some Markdown flavors (notably WhatsApp) do this. So you only have to do *haha* or _haha_, which also makes italic-bold more _*intuitive*_. Similarly they should have gone with one style of headings, probably with #. T…

> Making * always be used for bold This is probably to support potential ambiguities and intraword emphasis e.g. underscore is a common pseudo-space so doesn't support intraword use but * does e.g. is_not_italic this*is*italic. I recently implemented a commonmark parser for emphasis. Holy shit it's painful. I regret doing it but it became a battle I refused to surrender. It's way harder than I expected because of the…

> This is probably to support potential ambiguities and intraword emphasis e.g. underscore is a common pseudo-space so doesn't support intraword use but * does e.g.

    is_not_italic

    this*is*italic.

That seems like a legacy spec mistake they had to adhere to. I'd expect

    this_is_italic
to work and for _ literal usage to require

    is\_not\_italic

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

#235
post #172

Earlier quoted context omitted.

To be fair, one there's a good one there's much less incentive to write something new. In this case the good converter is Pandoc: https://pandoc.org/

Thanks; but that's a converter, not a viewer. The problem is the lack of READER applications to simply view (not edit or convert) all these Markdown documents.

In my defence, the comment I was replying to mentioned "renderers" and "converters". Furthermore IMHO, any text editor is a Markdown reader. If you want it formatted as is it were "markup" then might I suggest converting to e.g. PDF using Pandoc and then using one of the many capable viewers.

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

#236
post #235

Earlier quoted context omitted.

Thanks; but that's a converter, not a viewer. The problem is the lack of READER applications to simply view (not edit or convert) all these Markdown documents.

In my defence, the comment I was replying to mentioned "renderers" and "converters". Furthermore IMHO, any text editor is a Markdown reader. If you want it formatted as is it were "markup" then might I suggest converting to e.g. PDF using Pandoc and then using one of the many capable viewers.

Noted, re the other comment.

But... come on. You might just as well say any text editor is a browser, because you can technically read HTML with it.

You can also technically read Word documents with a text reader.

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

#237

Earlier quoted context omitted.

Interesting. Why not HTML? Browsers have native basic WYSIWYG editing built in, and almost every screen we look at is nowadays HTML, including the code editor. On a ` element, calling document.execCommand('bold') will make selected text bold in WYSIWYG mode. See https://jsfiddle.net/z0umpb3x/12/ for the concept. The main idea here is that I don't want to know any syntax like RTF, nor I want to use any tools.

> Why not HTML? Browsers have native basic WYSIWYG editing built in Can you point me to a page in Firefox that I can use offline to WYSIWYG edit a hypertext document without needing to use the developer console to edit raw HTML?

I believe it's technically possible, but I don't know if there's a tool.

Btw, genuinely asking, what's your offline scenario? Long loong time ago, I used TiddlyWiki for a brief time period for my temp offline scenarios. Single local HTML, can edit, but not WYSIWYG.

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

#238
post #82

I've used or built more personal knowledge/task/project management tools than I care to list over the years, and adopted various methods along the way. I've ended up in a place where I know what I need day to day: A place to dump my ideas, plans, reflections, and tasks, along with methods of processing and accessing all this data. It's hard to compete with plain text files, a notebook, and structured daily/weekly rit…

Wow, this actually sounds quite neat. I'm already using markdown and being able to make my notes more interactive and useful via chat-like interface with automations would be great. Especially as I want to use AI systems on top to make the accumulated knowledge as useful as possible. Please share more

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

#239

Markdown is a wonderful format (I use it all the time) but it's very narrow and I don't think it's appropriate for storing general 'things we might publish'. You lose a lot of semantics just replacing html with markdown. For a general purpose markup language, I don't think we can beat XML.

I agree, if the purpose is archival (versus manually reading it with your eyeballs) then you will want a format that (1) can capture information in a somewhat self-documenting way and (2) is in a form that can be easily parsed and converted into a newer format.

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

#240

Earlier quoted context omitted.

There's notional underlining, which in typewritten documents is effectively the equivalent of italic , and there is typographical underlining, where "underline" means "there is a line under this element and/or text". Both matter, and although Markdown flavours handle the notional case well, they fall down at this (and several other) typographical capabilities. Expressing text in a particular colour (or greyshade) is…

i said "typewriter", and there is only one kind of underline on a typewriter. converting old typewritten notes, they may contain typewriter underlining, and it may represent italics. Markdown would be entirely sufficient to handle that. there was no need to de-clarify my comment.

The typewriter is distinct and often intermediate writing device standing between the markedly free-form though also variable handwriting and the much more standardised, though fairly developed, capabilities of typeset documents.

Unlike handwriting, typewriting uniform (both in type and spacing), and markedly faster.

Unlike printing, typewriting is limited (generally a single typeface, no variability in face, size, or styling (e.g., roman, bold, italic), and requires further guidance to define specifically what result is desired where a typewritten work is not a document's final form.

It's worth noting that print itself differs from handwriting: when we write letters, forms and sizes vary, different writers often differ markedly in their own scripts, trained copyists may achieve a high level of standardisation, but that itself requires significant training and is achievable only by a limited number of artisans,[1] and letterforms themselves are not discrete but individually instanced each time they are created. With the advent of moveable-type printing,[2] letterforms became fixed, and with digital typesetting and computer fonts, each discrete shape or language-specific forms, say, the Roman A, Greek Α (alpha), and Cyrillic А (Azǔ/Азъ), are represented by distinct code points, but are nearly or entirely indistinguishable when rendered on-screen or in print. Further, over the history of both handwriting and typesetting, conventions have emerged for the textual representation of language, including spacing of words (versus scripto continuo), punctuation, paragraphs, page numbering, division of books into chapters, sections, parts, subsections, etc., of lists, tables, indices, (foot|end|side)notes, (parenthesis), drop-caps, figure captions, cataloguing, etc., etc. All of those were inventions and conventions not inherent to language, writing, printing, document preparation, or archival and retrieval themselves. There's still considerable variation between different print language representations, e.g., many texts lack equivalents of italic, bold, or even upper/lower case letterform distinctions.

Typewriting itself occupies an interesting space, being a primary endpoint for some types of documents (correspondence, forms, and the like) and an intermediate form for others, most notably published articles and books. Given that typewriting has both capabilities and limitations which aren't present in typeset documents (whether moveable type or digital), it's not possible to draw a distinct correspondence between what a typewriter outputs and how that might be represented in a derived document. Yes, typewriters can generate underlines, but that might be represented in typeset print as italic, bold, underline, or something else entirely. In practice, editors proofing marks were inserted (as handwritten notations) on a typed manuscript to indicate the preferred presentation, generally following the author's intent and/or the publisher's own house style conventions. See: https://en.wikipedia.org/wiki/List_of_proofreader%27s_marks>.

________________________________

Notes:

1. An anecdote which sticks with me: among the 1001 Arabian Nights stories is one in which a character makes specific references to the not only his literacy and scribal capabilities, but the types of scripts he could produce. That is, this was a specific and valued skill of that age worth noting, even in a general-audience work.

2. As distinguished from earlier monoblock printing in which a whole work was engraved on a wood block or metal plate, typified by early Pamphilus, seu de Amore from which we have the word pamphlet, see: https://www.etymonline.com/word/pamphlet>. Such monoblock prints were more like a photocopied handwritten letter, in which variations in individual letterforms are replicated, than they are standardised print obtained from moveable type or, more recently and familiarly, computer-based digital typesetting or Web documents, in which fonts are standardised and each given character is identical to all others matching that style.

Post reply on HN