[HN Gopher] Markdown is meant to be shown (2021)
___________________________________________________________________
Markdown is meant to be shown (2021)
Author : SoKamil
Score : 165 points
Date : 2024-08-15 11:53 UTC (11 hours ago)
(HTM) web link (daringfireball.net)
(TXT) w3m dump (daringfireball.net)
| deafpolygon wrote:
| I prefer not to see the markdown, and only the styling. We used
| to have a smattering of RTF-styled notetakong apps until they all
| became markdown-backed ones. It's telling that they're hiding the
| Markdown. People don't want to see it.
| Y-bar wrote:
| I am currently trying to fit Obsidian into my workflow as a note
| taking app, and this is one of my main gripes about the app.
| Another being that it does not integrate well with the operating
| system spell checking, so adding a word elsewhere to the system
| dictionary does not reflect in Obsidian, and the other way
| around.
| bachmeier wrote:
| Obsidian has both live preview and source mode. I have a
| shortcut to switch between the two. I use live preview when
| making lists and source mode for most other documents.
| Y-bar wrote:
| I've been scouring the preferences pane once again but can't
| find anything like it. Any tips?
| LordDragonfang wrote:
| Settings > Editor > Default editing mode
|
| Switch the dropdown from "Live preview" to "Source mode"
| bachmeier wrote:
| The other commenter has given you the way to set the
| default. Just go with that if you never want live preview.
| My keyboard shortcut is in Settings > Hotkeys > Toggle Live
| Preview/Source Mode. I set that to Alt P.
|
| You can also click the three dots in the upper right corner
| and select source mode.
| replete wrote:
| I use a keyboard shortcut to quickly switch between source and
| live preview mode.
|
| I open sourced my css snippets repo, and the first CSS rule in
| this file in my minimal theme CSS snippets repo resets font
| sizes in source view so font sizes are the all the same:
|
| https://github.com/replete/obsidian-minimal-theme-css-snippe...
| tjoff wrote:
| Though only show the markdown if one is expected to edit it
| (which would be the case in an editor).
|
| Otherwise, if the usecase is consumption you are better to show
| the generated output.
| filcuk wrote:
| Yeah, I'm happy I can edit via markdown and fallback on it if
| the site is down, for example, but I see no benefit to
| intentionally making it less readable when reading/presenting.
| jessriedel wrote:
| Yes, the blog post could have made it clearer that the author
| was talking about editing mode only. (His wording was "meant to
| be visible to the writer".)
|
| The issue, of course, is when the writer is also the reader,
| such as for the note-taking apps. It's not always clear then
| what mode the user wants to be in.
|
| I'm pretty happy with the compromise struck by Bear, which does
| some of what the author is complaining about. Bear's technique
| is to show the formatting (i.e., hide the markdown syntax) for
| everything except the "word" (contiguous non-white-space) that
| you are currently editing, as determined by the location of
| your cursor. This lets you edit the markdown directly, ASCII-
| character-by-ASCII-character, but the rest of the doc looks
| pretty. It's not perfect, but hiccups are rare and I find it
| vastly better than the alternatives: (1) a conventional WYSIWYG
| editor or (2) a hard distinction between writing and reading
| mode that the user needs to constantly toggle actively as they
| use their notes. But it seems fine to me that different users
| prefer any of these options.
| gsinclair wrote:
| Grover thinks the purpose of Markdown is that the author knows
| what HTML tags will be generated. That was his purpose, but it's
| long outgrown that!
| hoosieree wrote:
| Probably easier to get people to change the name from README.md
| to RENDERME.md.
| msf1024 wrote:
| The reason I write in markdown is because it is fast and
| keyboard-driven. I don't want to see it when I'm looking at my
| notes or editing them. The idea that it is meant to be seen is no
| more than a personal preference.
| Joker_vD wrote:
| But uh, how do you undo the styling from the keyboard? Does
| Backspace turn " _italic_ " into "*italic"?
| wccrawford wrote:
| I've seen editors do it that way, and if you know what it
| looks like in your head, it works quite well, IMO.
|
| I can't imagine how it works for people who aren't pretty
| good at the syntax.
| ixwt wrote:
| I personally like the way that Obsidian and Typora hide the
| styling: when you get to where it would be, it shows up on
| screen to show you it's there causing the styling. When your
| typing indicator moves away from it, it hides it. Some don't
| like it because it can cause some displacement of text a bit
| because it's now showing characters it didn't before.
| SOLAR_FIELDS wrote:
| I found Obsidian's way of doing it to be a bit jarring at
| first but now that I've used it for awhile I personally
| quite like it. Just takes a little while of getting used to
| cnity wrote:
| You could probably do this in a way that doesn't trigger
| text reflow if a popover appeared with the visible syntax
| exactly positioned such that the extra syntax slightly
| obscured surrounding text. It's a tradeoff but I think that
| might be slicker.
| Sylamore wrote:
| Not a user of either of those but that sounds an awful lot
| like "Reveal Codes" from WordPerfect which saved my ass
| more than once when formatting got screwed up in a
| document.
| g15jv2dp wrote:
| Ctrl+Z
| diwank wrote:
| It does on a lot of editors and I hate it. On my vim the
| highlights only get added/removed when I switch back to
| normal mode, during editing nothing changes except for the
| actual keystrokes.
| Slackwise wrote:
| > because it is fast and keyboard-driven
|
| How is it faster to press `*` than `Ctrl-I` in any other rich
| text editor?
|
| > The idea that it is meant to be seen is no more than a
| personal preference.
|
| Actually, the entire philosophy of Markdown is that, even if
| you didn't process it into HTML or some form of rich text, it
| uses common conventions that have been used across Usenet, IRC,
| and plaintext files for years, and is thus readable without
| ever being processed. In fact, you can likely take various
| plaintext files and process them and they'll gain many
| incidental markups and highlights.
|
| Meaning, Markdown is Markdown without needing to be turned into
| HTML or rich text. It is, in itself, a great way to universally
| markup text as people have been doing online for years.
| watwut wrote:
| You need to highlight first and only then to press ctrl-I. So
| yes, typing is faster if you do it a lot.
| scintill76 wrote:
| You may not be aware that Ctrl-I toggles the mode of new
| text, not just selected text. I think that poster was
| saying this:
|
| If you're writing a new sentence in MSWord, you type
| "Emphasize words <Ctrl-I>like this<Ctrl-I>."
|
| If you write a new sentence in Markdown, you type
| "Emphasize words *like this*."
|
| The keys are neighbors even, at least in a US keyboard
| layout, so there is not a reason most US users would say
| it's "faster" to type * than Ctrl-I. (And if other layout
| users disagree, okay, but I don't think that was in the
| scope of the original point.)
| TeMPOraL wrote:
| I think in practice, people write "Emphasize words like
| this.", then <left> *, then <C-left><C-left> *. At least
| I myself usually add markup immediately after writing the
| words to be marked up.
|
| The problem with Word-like editor styling is exactly that
| the boundaries are invisible, and the style is applied
| destructively to everything within highlighted range,
| instead of non-destructively by the range itself. What I
| mean is, if in the example above, I want to change the
| emphasis to only italicize "this", I can kill the first *
| and place it a word later. In Word-style editing, I'll
| have to highlight the whole "like " sequence and un-
| italicize it, hoping I didn't miss a space or a dot that
| invisibly retains the italics and then screw up editing
| for you down the line.
| g15jv2dp wrote:
| > I think in practice, people write "Emphasize words like
| this.", then <left> _, then <C-left><C-left> _. At least
| I myself usually add markup immediately after writing the
| words to be marked up.
|
| Is this very different from "<left> <Ctrl+Shift+left>
| <Ctrl+Shift+Left> <Ctrl+I>"?
| kragen wrote:
| you will probably appreciate the keystroke command design
| in https://news.ycombinator.com/item?id=41258170
| kragen wrote:
| i haven't pushed it to github yet, but i have a keybinding
| for alt-* similar to the alt-` binding at https://github.com/
| kragen/kragen-.emacs.d/blob/master/init.e... which italicizes
| the _previous_ word. that way, to italicize a single word,
| which is the most common case, i only have to press alt-*
| _once_. successive presses expand the italicized region
| leftwards over more words (this happens whenever the cursor
| is directly to the right of a *; it isn 't activated by an
| invisible bit that remembers whether the previous command was
| also an alt-*)
|
| (it also ought to italicize the selection when there's an
| active selection, but i haven't implemented that yet)
|
| i think this is a superior interaction paradigm to the
| paradigm where ctrl-i sets an italics mode that doesn't
| visibly change anything near the cursor, but affects the
| _future_ text you type. that design not only usually requires
| more keystrokes but causes mode errors. this is how ctrl-i
| and ctrl-b should always have worked, and if larry tesler had
| thought of the idea by 01983, that 's how they always would
| have worked
|
| however, the _keystroke_ ctrl-i is easier to type than the
| keystroke alt-*
| JNRowe wrote:
| Stolen, thanks! I just played around with something like
| that in vim1, and it works great.
|
| I have a tooling issue with your method, perhaps in the
| same manner as you feel about C-i. To me "italicize $count
| previous words" makes far more sense than expanding the
| region on repeated calls. Although to be fair I can wrap
| over visual mode for that functionality which would feel
| more comfortable _to me_ ; "ge" end of previous word, "v",
| $navigation, ...
|
| My point - to the extent I have one - is that there is
| probably a degree of personal comfort that colors our
| reactions to people using C-i.
|
| 1 Basically "imap <C-S-8> <Esc>bcw*<C-r>-*<C-o>w". I'll
| give it some more thought, along with adding v:count and
| non-* support, before it hits my vimrc.
| kragen wrote:
| awesome! i look forward to hearing how you end up doing
| it
| phone8675309 wrote:
| > Maybe I don't know much about Markdown, but my understanding is
| that the whole point of it is to provide a syntax where the most
| common HTML tags for prose can be replaced by simple punctuation
| characters that are meant to be visible to the writer.
|
| Cracking up at this quote
| dpritchett wrote:
| The deadpan was so good there I had to stop and double check
| the origins of Markdown just to make sure my mind wasn't
| playing tricks on me. Hard to believe it's been twenty years!
| keybored wrote:
| > The deadpan
|
| Based on his interaction with the CommonMark people I would
| characterize it more as overly possessive.
| Y-bar wrote:
| I bet, if I would take your copyrighted work, create a
| deritative work, have the gall to call it "Standard
| YourCopyrightedWork", and then go back and forth if it is a
| derivative work or not, you would certainly not consider me
| friendly either.
|
| As someone who contributed a bit to the early CommonMark
| spec I think some of us were really doing it the shitty way
| towards Gruber.
|
| How would the Rust people react if we created a "Standard
| Rust" language?
| LordDragonfang wrote:
| > if I would take your copyrighted work
|
| https://daringfireball.net/projects/markdown/
|
| >Markdown is free software, available under a BSD-style
| open source license.
|
| John Gruber's markdown is _unmaintained_ (last updated in
| 2004), _free_ software, which many people have
| contributed to to fix oversights and extend its
| capabilities. This is exactly how fsf is supposed to
| work.
| Y-bar wrote:
| You are unfortunately making the same incorrect
| conclusion many of us did back then.
|
| It was about the _Name_ , never about the
| syntax/implementation.
|
| Gruber was very clear with his license and regular words
| that he did not allow the usage of the name in a manner
| which would cause people to be confused or suggest that
| it was an official implementation.
| LordDragonfang wrote:
| Huh. Good point, I did miss that. That, however, seems to
| primarily be an issue of trademark, not copyright. And
| once we enter the domain of trademark [law],
| genericization becomes a salient point, especially with
| the "anyone can use it however they want" reality of FSF.
| kaoD wrote:
| The usage of the word "copyright" made me wonder... can
| you even _copyright_ Markdown? I don 't think you can,
| can you? You can copyright the spec (if any) or the
| reference implementation, but you cannot copyright the
| concept or syntax itself.
|
| You could maybe _patent_ Markdown (given the amount of
| trash software patents I 've seen I wouldn't be
| surprised) but (1) it's not patented AFAIK and (2) it's
| become so common (mark, heh) that I don't think it could
| be patented anymore.
|
| You could say Markdown is covered as a _trademark_ even
| if not officially registered maybe? I don 't know the
| specifics though, could anyone chime in? (this is
| complicated further by the different jurisdictions). But
| my understanding of the general idea is that if your
| trademark becomes common (which I guess happened?) or you
| don't actively defend it (which is what Gruber was trying
| to do fighting Standard Markdown), you lose it.
|
| So, to summarize, I think he was right to be angry (in a
| moral way) but that's possibly the only _right_ he had in
| the literal sense. Which is more than enough of course.
| Y-bar wrote:
| How I see it as well. Gruber really wanted the project to
| use a name which did not imply any kind of "official"
| status, support, or such relationship with regards to him
| and Markdown.
| keybored wrote:
| What if someone went to the effort of congregating around
| making a standard out of my weekend (? I dunno) Perl
| script? I would be elated. But maybe my standards are low
| because I'm not already "famous".
|
| If the crucial part here is the fact that he apparently
| already copyrighted the name then that seems kind of like
| begging the question. I wouldn't copyright a bland name
| like that which has no connection to my own person.
| (Maybe I would copyright something like keybord-lang
| though...)
| tomcam wrote:
| Milspec troll. I was nonplussed and rechecked a few of his
| articles as well.
| zeveb wrote:
| I think that this is correct. Also, we really shouldn't forget
| that Markdown is meant to generate HTML, and that HTML blocks are
| valid Markdown: a system which does not permit it isn't really
| using Markdown.
| jareklupinski wrote:
| put a "Show Markdown / Show Result" toggle button at the top of
| the textbox that contains the editable field
|
| save the current setting to a cookie
|
| some people who stay on the rendered side sometimes forget the
| syntax, and use the Show Markdown button to check how something
| was created
| KeplerBoy wrote:
| Does anyone prefer the syntax view when in read-only mode?
|
| I don't think I'd ever prefer seeing raw markdown over rendered
| documents when browsing GitHub repositories for example.
| jareklupinski wrote:
| i think it's like an HTML browser at that point: content
| creators and power users might want to check the code for a
| typo or hint, some people copying a section of text want to
| be sure they are copying the code also and not just the text
| (or vice versa)
| red_admiral wrote:
| Someone please tell Atlassian who are about to disable this for
| trello desktop.
| voidhorse wrote:
| I think the bigger problem is that apps that don't need/shouldn't
| use markdown reach for it as a default and build upon it when
| they would have been served better investing in richer markup.
|
| Take ulysses (mentioned in the article) for example. It has grown
| into a full-fledged writing and word processing application, but
| its being based on markdown originally has only hampered that.
| They've had to implement all of these clunky extensions and
| features in terms of markdown, and as the post states, try to
| hide the fact that it's all markdown to make it feel more like a
| classic word processor. At this point it just makes the whole
| experience clunky. People that just want to write markdown deal
| with weird extensions and frustrating syntax hiding, people that
| don't need to learn some minimal markdown just to use a word
| processor...
|
| It's 2024. I hope companies start to realize that markdown is a
| _fantastic_ solution for certain cases but it is not _the only_
| solution. Some applications really are better served by more
| complex, but much more expressive markup languages, especially if
| they are going to shield the user from it all anyways.
| jasonpbecker wrote:
| Of course you can use any number of ways to implement rich text
| or formatting. A lot of people want Markdown because of the
| portability of plain text. Markdown has served as a good
| mechanism for plain text formats that still can do a bit more.
| Ulysses would lose a significant portion of its audience if it
| moved to it's own syntax or some form of rich text or its own
| binary. A new audience would likely become interested-- though
| fighting Microsoft Word is ... hard to say the least.
|
| Maybe that's where Ulysses wants to go, and its own
| implementation of some non-standard elements suggests that. But
| I also know people who will not use Ulysses because of its non-
| standard Markdown elements resulting in files that are less
| portable.
| sbuttgereit wrote:
| Couldn't agree more.
|
| I find that I'll choose Markdown (assuming it's a choice) when
| I expect multi-modal consumption... where a given text will in
| some contexts simply be presented as-is using plain text and
| the text can also take advantage of rendering into a more
| styled presentation.
|
| I write in-database comments (e.g. PostgreSQL's `COMMENT ON
| [...]`) using Markdown for this reason. My go-to database
| documentation tool of choice (https://schemaspy.org) will very
| nicely render the Markdown into styled documentation integrated
| into the rest of the documentation it generates, but the plain
| text rendering when I'm looking at those same comments via
| `psql`, where no Markdown rendering is applied, still look
| decent due to how Markdown works.
| j1elo wrote:
| Ulysses? Take an app with a MUCH wider audience: WhatsApp!
|
| They use Markdown-esque syntax for message formatting. It
| mostly _is_ Markdown, with a single caveat that gets me a lot:
| *Single asterisks* become bold, instead of italic. For italics,
| you have to use _underscores_.
|
| Other syntax works fine. Slack also uses Markdown. In summary
| that's nice as it is just one single syntax to remember across
| systems. I wouldn't enjoy too much that every app started
| having its own different, more expressive syntax, at least not
| for apps which their primary job is communication, not text
| edition.
| voidUpdate wrote:
| It really annoys me that services can't decide if * is bold
| or italics. It makes the most sense to me as italics, so when
| I use whatsapp or youtube I always get annoyed that it did
| the wrong one
| cwillu wrote:
| I can't comprehend why * wouldn't be bold. Given that
| underlining is how you italics when you can't italics, _
| makes perfect sense.
| digging wrote:
| > Given that underlining is how you italics when you
| can't italics
|
| In my experience underlining is how you bold when you
| can't bold.
| JoshTriplett wrote:
| In my experience, underscores are how you underline when
| you can't underline. Asterisks are emphasis, which is
| typically italics.
| kccqzy wrote:
| That's completely true, but emphasis is normally rendered
| by italics too. (See for example the <em> element in HTML
| with the default CSS.) Emphasis is the semantic, italics
| is the presentation. From this perspective both
| underscores and single asterisks should render into
| italics.
| JoshTriplett wrote:
| > emphasis is normally rendered by italics too
|
| I wasn't disagreeing with that; edited my comment to be
| clear. Asterisks are emphasis; emphasis is typically
| italics.
|
| I do think that underscores _should_ have been
| underlining, but unfortunately that 's not what Markdown
| chose.
| glenngillen wrote:
| > are how you underline when you can't underline
|
| Underscores/underline were a hint on a manuscript to the
| typesetter that you wanted italic
| (https://en.wikipedia.org/wiki/Underscore). It later
| became a way to add emphasis (either italic or bold
| styling) on typewriters as there wasn't a practical way
| to have bold and italic versions of every character on a
| mechanical typewriter.
|
| Most professionally typeset content (i.e., optimised for
| legibility through years of experience rather than just
| whatever your word processor will allow) will not contain
| underlined content
| (https://practicaltypography.com/underlining.html).
| cwillu wrote:
| FWIW, https://style.mla.org/underscore-instead-of-
| italics/
| gowld wrote:
| CAPS is how you bold when you can't bold.
| digging wrote:
| Funny of you to say that so authoritatively when you're
| only demonstrating my point: there is no _one correct
| way_ to replace bold text when you can 't use bold text.
| biztos wrote:
| For decades (centuries?) in German, s p a c i n g was how
| you "bolded" (or italicized) when your typesetter
| couldn't. Very elegant solution once your eye adjusts to
| it.
| SllX wrote:
| I've been using Markdown since 2006 and for me it's
| always been:
|
| *emphasis* (i.e. italic)
|
| **strong emphasis** (i.e. bold)
|
| You can use underscores in exactly the same way, but the
| reason I've stuck purely to asterisks is that it's just
| slightly easier to type and I think it's slightly more
| readable when I'm reading an un-rendered Markdown
| document, so I appreciate the syntax that John Gruber
| chose here.
| zo1 wrote:
| * was to bold or to emphasize stuff way before markdown was
| even a thing. That's how I remember the early days of the
| web in the early 0's.
| Fomite wrote:
| I think the issue is "bold *or* emphasize". There's not a
| universal consensus on whether or not emphasis is italics
| or bold.
| eyjafjallajokul wrote:
| See also: Imperial v/s Metric. :-)
| chrismorgan wrote:
| > _Slack also uses Markdown._
|
| No it doesn't. It uses something they call mrkdwn, which is
| only _vaguely superficially_ similar to Markdown. In most
| important places, mrkdwn has made different decisions from
| Markdown. It 's a _completely_ different, and far more
| rudimentary, Lightweight Markup Language.
| riffic wrote:
| it's better than whatever Microsoft Teams makes you use.
| saratogacx wrote:
| Teams (and I believe Slack too) uses what I call MS Word
| formatting (They call it "Auto format as you type"). A
| lot of the markup you can do in teams came from elements
| that do the same in Word/Outlook/etc.
| j1elo wrote:
| In my defense I'll say that with that "also" in my mind I
| was thinking on the previous phrase, so I was referring to
| a "Markdown-esque syntax for message formatting"...
|
| Nevertheless, good catch
| slightwinder wrote:
| Markdown is build on popular custom syntax from mails and
| other message-platforms. WhatsApp is probably doing the same.
| Similar problem exist with all the other simple markup-
| languages, doing the same. At the end, there is only limited
| syntax available for those cases, those they are destined to
| have similarities and duplicates.
| playingalong wrote:
| Wait. In my Slack asterisks mean bold too.
| ericyd wrote:
| > Trust me, it's meant to be shown.
|
| Maybe it's time to accept that this thing you created is bigger
| than yourself and it's future is not in your hands.
| gkoberger wrote:
| One thing I love about being able to see the syntax when editing
| is that you know what's about to happen. A backspace will always
| delete the previous key; you won't end up in a situation where
| you're deleting a whole block of content. And when you type, you
| know if the cursor is on the left or right side of the "*",
| whereas in WYSIWYG it could be on either side of the invisible
| change from bold to regular.
|
| It's much more relaxing for me to write in Markdown, because I
| don't have to think about the mode I'm in or how to get out of a
| small pickle. Everything is just a character.
|
| I don't think Markdown is for everything. Microsoft Word is not a
| Markdown editor, and most people are better served by a WYSIWYG
| editor. But for writing content, I always prefer personally to
| write in markdown (and to see the syntax), since it's easier to
| focus more on writing and less on the editor.
| ximm wrote:
| You haven't dealt with bidirectional text yet, have you?
| gkoberger wrote:
| I feel like that's a hard problem no matter what, and doesn't
| negate my personal preference for using markdown when writing
| longform content?
| svachalek wrote:
| The thing where backspace magically reformats half your
| document is so frustrating. I wonder if Word's solved it as
| it's been decades since I've used that, but it seems like
| pretty much anything else I use still has that issue.
| bitwize wrote:
| Maybe it's time we brought back the "Reveal Codes" command?
| slightwinder wrote:
| But syntax is ugly, especially the more complex parts we have
| now. And I think some of them, like tables, code blocks or modern
| link-style, weren't even part of the original markdown.
|
| And the reason I prefer Markdown, is because it's not
| proprietary, and Obsidian, my preferred Markdown-Tool, has a
| different workflow than the usual WYSIWYG-Tools. If Obsidian
| would use json or yaml for everything, I would still use it. It's
| just a tool for me, not the goal.
| thomascgalvin wrote:
| I generally don't even like syntax highlighting for Markdown. I
| find having the text jump around because it became bold or
| italicized distracting, and it's even worse when a header is
| suddenly a larger size and everything below it is pushed down the
| screen.
|
| Markdown is simple, and I like working with it simply.
|
| I suppose there is some value in having the more complicated
| aspects, like images and tables, checked for syntax so you can
| see if you've made a mistake, but I run a macro to generate those
| anyway, so I'm fairly confident in the result.
| diwank wrote:
| Yep but to me this feels like a lot of poor ux decisions too. I
| would def appreciate the visual indicators of italics and bold
| text but ffsake please dont toggle it every time I add a bloody
| keystroke. It's so jarring when editors do that. There are so
| many alternative designs where you can have both. For instance,
| on my vim the highlights only get added/removed when I switch
| back to normal mode, during editing nothing changes except for
| the actual keystrokes.
| bfung wrote:
| > Maybe I don't know much about Markdown...
|
| Says the inventor of it, 20yrs ago.
| https://daringfireball.net/projects/markdown/
| hungie wrote:
| Inventing a thing and understanding a thing aren't necessarily
| the same. We adopt technologies and make them our own,
| sometimes away from the inventor's initial vision.
|
| I think if people, by and large, enjoy markdown one way (for
| example in this forum, where you _italicize_ text but the
| control characters don 't show), then maybe the inventor is
| wrong. Or is right about their preferences but shouldn't try to
| make their preferences the de facto standard.
| breadwinner wrote:
| The best example of that is Bob Metcalfe, inventor of
| Ethernet, predicting the collapse of Ethernet... didn't
| happen.
|
| https://www.reddit.com/r/todayilearned/comments/azevs3/til_t.
| ..
| natpalmer1776 wrote:
| I think the author of the blog post intended the comment as a
| tongue-in-cheek joke; A humble way of pointing out that they
| _created_ markdown and thus have some degree of implicit
| authority when speaking on the subject.
| hungie wrote:
| Yes, I understood that. My point is that they specifically
| _don 't_ have implicit authority.
| timetraveller26 wrote:
| It should be optional, hide by default (maybe like Obsidian where
| is only visible on the cursor's line) but add an option to make
| it always visible
| red_admiral wrote:
| Trello, once made for developers by developers, has announced
| that some time this August they will disable the markdown editor
| on desktop and force you to use the WYSIWYG one. The markdown one
| will remain on mobile, so there's clearly no compelling reason to
| do this. There won't even be an opt-out anymore.
|
| (Could someone please find out which resources we all have to add
| to ublock to work around this?)
| paradox460 wrote:
| I'd prefer if we stopped using markdown all together, and moved
| to something like djot: https://github.com/jgm/djot
| gkoberger wrote:
| Maybe djot is better... I'm sure it is in a lot of ways.
|
| But one of the key features of Markdown (and, indeed, most tech
| such as programming langauges) is the ubiquity. It's really
| hard to overcome the fact that almost every platform can
| export/import markdown.
| Aardwolf wrote:
| Ignores newlines as well, so just as annoying as markdown to
| me.
|
| Why are almost _all_ of those light formatters removing your
| line breaks? Everytime someone mentions some markdown variant
| (and there are many of them!) and I look up the syntax
| description, it shows that newlines are being ignored.
|
| If it's trying to be plain text, at least behave like plain
| text, and don't remove newlines in a shopping list like this
| (just like hacker news also does with its comments):
|
| -eggs -milk -flour -water
|
| BBCode has it right.
| ulbu wrote:
| I guess, because it works well with terminal text editors,
| emails, and other contexts where your text isn't wrapped at a
| margin. which is most places.
| Aardwolf wrote:
| I'm mean ignoring single newlines that you enter, so it's
| wrapping _less_ , not more
| codemac wrote:
| Markdown has lots of syntax from irc/email that folks have been
| using for decades. The popularity is also due this, it was
| partially a refinement rather than invented.
|
| This is also why the parsing ambiguity/backtracking ends up
| occurring - humans can read plaintext and do pattern matching
| with context/attention whereas parsing algorithms have a hard
| time.
| chrismorgan wrote:
| > _If you want WYSIWYG, do WYSIWYG. If you want Markdown, show
| the Markdown. Trust me, it's meant to be shown._
|
| One valuable thing about using Markdown as an data
| storage/exchange format is that it's often easier to manipulate;
| for example, diffs are normally going to be better, and content
| edits often easier. Mind you, a proper encoding of a WYSIWYG
| format, and corresponding tooling, _will_ be better... but for
| quick-and-dirty that _normally_ works well, Markdown is
| ultimately pretty good (unfortunately, in my opinion).
| taeric wrote:
| Oh wow. From headline, I first thought this meant that viewing a
| markdown document should show me the markup. Which falls on its
| face with images and links, of course.
|
| No, this is about editing the document. And... I confess I'm
| confused on why folks would want the opposite? WYSIWYG is, of
| course, a thing and popular for many reasons. So, I can see
| having the option to operate in that way. But a huge benefit of
| markup languages of any kind is that I can see the markup. Fully
| agreed that I should be able to see it.
| thinkling wrote:
| I use markdown for note-taking. I do as much reading as
| editing, and they're generally intertwined. I don't want to
| switch between "view mode" and "edit mode". I want to be able
| to embed links but not have the document become cluttered with
| long, ugly URLs. I want to use headlines and bulleted lists and
| have them auto-formatted. I also want to keep my notes in a
| 100% portable human-readable format. (No MS Word, no Bear, no
| Evernote, etc.)
|
| For my use, the best solution is an app that shows me the
| formatted (styled) output, until I navigate the insertion point
| into it, and then expands the text to show the formatting.
|
| Obsidian is an app that does this. I don't love other parts of
| it, but the editing experience works well.
|
| (What I really want is the search/browse experience of nvUltra
| with the editing experience and cross-platform presence of
| Obsidian.)
| kragen wrote:
| this only partially addresses your complaint, but you may or
| may not be aware that markdown has an option to put urls in
| footnotes, which you can put anywhere in the file:
| (This is part of the background work for [Monnier's paper
| with him about Elisp's history][3] for HOPL '20.)
| ... [3]:
| https://dl.acm.org/doi/pdf/10.1145/3386324 (Evolution of
| Emacs Lisp, by Stefan Monnier and Michael Sperber)
|
| in my .emacs.d/init.el i wrote a command https://github.com/k
| ragen/kragen-.emacs.d/blob/master/init.e... which inserts
| such a footnote link, linking the previous word to the link
| pasted from the clipboard. it auto-increments the footnote
| counter, initially setting it higher than any numbered
| footnote it finds in the file. i have it bound to the fairly
| horrible key ctrl-alt-]; successive presses of the key expand
| the link leftwards to include more words
|
| (it _ought_ to use the selection as the link text if there is
| one, and to find an existing block of footnotes to add the
| footnote to if there is one, but i haven 't implemented those
| features)
|
| the upshot of this is that in the above, after typing
| 'history', i pressed ctrl-alt-] and kept pressing ] until the
| link had engulfed monnier's name
|
| emacs markdown-mode does also automatically syntax-highlight
| links, headers, bulleted lists, italic, bold, typewriter
| code, and markdown linebreaks, and it has a command (the also
| rather horrible keybinding ctrl-c ctrl-o) to open a link. if
| the link is to a local file, it opens it in emacs rather than
| your browser. it also uses the tab key to expand and collapse
| headers, and of course it always has emacs's instantaneous
| full-text search. but the formatting is much uglier than
| obsidian's
| taeric wrote:
| This sounds like an agreement, then? I get why WYSIWG is
| pleasing sometimes. Most of the time it is not what I would
| want during editing, though.
| ides_dev wrote:
| This is precisely why I use Bear [0] (although Bear does hide the
| link URLs) and just cannot get on with Notion. The worse thing
| about editing in Notion (and other editors where the syntax is
| hidden) is trying to adjust `mono-space text`. It always seems to
| get confused about whether I'm inside the mono-space area or
| outside it and I end up making stuff mono-space that shouldn't be
| or vice versa.
|
| [0] https://bear.app/
| walthamstow wrote:
| For me it's Zettlr on MacOS
|
| You can also set Slack to not render the markdown until the
| message is sent, which I would thoroughly recommend
| iambateman wrote:
| Ahh, yes. I, as a developer, think Markdown is wonderful - simple
| even - so I use it all the time. It finds it's way into my
| applications and interfaces. The pure elegance is the stuff of
| dreams.
|
| Then I bring a client into their app for an onboarding meeting.
| When they see a bit of Markdown, they start to fidget, then
| sweat. "Will I be asked to perform these magic incantations?"
| they wonder. They feel a bit of queasiness but try to hold it
| back. Perhaps this will be ok. But, after about 10 minutes, I
| show them that `# Header` is how you make a header.
|
| Their disdain is now total...How dare I imply that a hashtag
| implies a header. This is hard.
|
| Then, I show them a link. "It's just like this", I say:
| `(https://example.com)[example link]`. "You'll get used to it."
|
| Finally, the client pounds his fists on the table. "That's CODING
| DAMMIT. WE PAID YOU TO DO THE CODING YOU *$$HOLE. I want it to be
| like...well...Microsoft Word."
|
| ---
|
| You see, my friends...the real problem here is that Microsoft
| Word is a nightmare but it is _the_ nightmare to which all other
| dreams are compared. And thus, sheepishly, I awaken, and install
| TinyMCE.
| haroldp wrote:
| And now you have a new job: untangling garbage <a><em><em
| style="font-weight: bold;"><em><span>HTML &nbs
| p; </em></span></a></em></em> disasters and coaching
| your clients about keeping the text styles in alignment with
| the site branding. :)
| iambateman wrote:
| "Coaching clients to keep text styles aligned with the brand"
| should come with a trigger warning! :D
| kragen wrote:
| this sounds like fiction you wrote about stereotypes rather
| than honest reporting of your experiences--and not only because
| you got the markdown link syntax backwards
| iambateman wrote:
| I enjoyed the dramatic value, for sure.
|
| But I did have a client who really hated markdown because she
| couldn't make colors red.
| kragen wrote:
| that's a legit problem with markdown, yeah. you can use a
| <span> or something but you can't use a <p> or <div>
| because everything inside it is exempted from markdown
| parsing, and the ux is abysmal compared to a wysiwyg editor
| with a color picker, and there's no extension mechanism to
| hang stuff like that on in a backward-combatible manner.
| commonmark is a little bit better there
| teo_zero wrote:
| When I edit a C program, comments are highlighted in a specific
| way, but the // characters are not removed. Why should editing a
| markdown text be different?
| fenomas wrote:
| Related: given that markdown is meant to be _read_ , it kind of
| drives me up the wall that some people nowadays run
| autoformatters like Prettier on it. Super-aggressive formatters
| like prettier remove various whitespace, and mangle other things
| that human authors do for readability. Which is fine if the file
| is something that's only ever meant to be parsed by scripts, but
| the whole point of markdown is that people read it!
|
| (edited to add: It wouldn't really be an issue if prettier had
| some config options for not mangling whitespace, but that ship
| seems to have sailed for some reason.)
| diwank wrote:
| Yes! I sometimes prefer to use `====` h1s and `----` h2s
| especially when I am writing slides or taking notes on a live
| call for others and I hate that prettier and other linters
| would automatically turn them into `# ` and `## ` ...
|
| Please stop doing that, prettier.
| The_Colonel wrote:
| Well, Markdown is a superset of HTML where extra whitespace is
| usually collapsed, so this behavior isn't surprising. Having
| "source" Markdown looking meaningfully different from the
| rendered Markdown seems like an anti-pattern.
| Shog9 wrote:
| As the essay and this discussion repeatedly try to emphasize,
| thinking of Markdown as a "superset of HTML" is missing the
| point - it is meant to be read. It has both meaningful and
| collapsible whitespace, and both allows and encourages uses
| of whitespace that _only_ have a significant effect on source
| readability.
|
| ...Arguably, the reason HTML has collapsible whitespace is to
| allow writing readable source, and once upon a time it was
| more common to see HTML produced in a way that didn 't get in
| the way of this (e.g. paragraphs and indentation indicated
| primarily via whitespace with only opening `<p>` and `<li>`
| tags). But that ship sailed; tooling long ago coalesced
| around more rigid conventions, and thus the need for Markdown
| emerged. Throwing those advantages away raises the question
| of why bother using Markdown at all.
| jpc0 wrote:
| You are confused about markdown.
|
| There is no "source markdown". Markdown is meant to be
| formatted to be read, without any intermediate step.
| "Prettifiers" like github etc are just converting the
| markdown into "styled" text. The format was always meant to
| be read as is.
| SllX wrote:
| Markdown is an intermediate format between a writer and
| rendered HTML. It is easier to read, write and edit as a
| writer (or someone reviewing someone else's writing intended
| for the web) before generating and serving HTML. It's not a
| superset, it's not a subset, and it's not HTML, although you
| can include HTML tags within a Markdown document to include
| things Markdown does not provide coverage for.
|
| Which is to say there isn't any such thing as "source
| Markdown" and "rendered Markdown". Markdown is the source,
| HTML is the output, although you can make your own parser
| output to whatever you want.
| bastawhiz wrote:
| > Which is fine if the file is something that's only ever meant
| to be parsed by scripts, but the whole point of markdown is
| that people read it!
|
| Nobody is running prettier on their code or markup for the
| benefit of the computer. If it's not readable, it's just a bad
| formatting tool (or wasn't configured properly). The whole
| point of a formatter is to make it easier to read.
| Shog9 wrote:
| Pretty much the _only_ benefit I 've seen of running prettier
| on Markdown is to highlight mistakes in formatting that
| otherwise wouldn't be apparent without viewing rendered
| output (which it highlights mostly by trashing the file in
| some fairly obvious way).
|
| The stated philosophy behind Prettier is to end arguments
| within a team about how to format code, which... Given
| Markdown is _already_ heavily constrained, barely applies;
| unlike other languages supported by Prettier, there are
| precious few adjustments made to Markdown that are clearly
| intentionally made in pursuit of consistent readability -
| indeed, if I recall correctly the Prettier Markdown engine is
| mostly just a round-trip through the remark.js parser and
| stringifier, _and the results reflect this_ - the results
| look mechanical, and it is just as likely to eliminate
| whitespace that lends clarity as it is to add it (if not, as
| the GP suggests, _more_ likely).
|
| Sadly, there are remark.js plugins that _could_ have been
| used to e.g. enforce consistent use of whitespace without
| stripping everything down to the bare minimum, but last I
| looked the Prettier folk were pretty hostile toward any
| suggestions that their (default, bare-minimum-effort)
| "style" was at all problematic.
| fenomas wrote:
| Prettier disagrees, as I understand it. Its authors know it's
| "wrong" to take this: const matrix = [
| 1, 0, 0, 0, 1, 0, 0, 0, 1,
| ]
|
| and collapse it onto one line. But their view is that
| reformatting everything from scratch is more important that
| such things, and that it's reasonable to add /* ignore */
| comments to every single place where you want anything
| preserved.
| danbee wrote:
| I'm not a fan of Prettier at all. A log of the time I find it
| makes code uglier.
| kragen wrote:
| maybe as a compromise the markdown metacharacters should be
| displayed in a lighter-weight font, a smaller font, or a reduced-
| contrast color? then you can see them, so it isn't a mystery how
| to type them, but the visual noise they add to the text you're
| editing is minimal
| eslaught wrote:
| I guess I'll defend the minority opinion.
|
| For context, I write over 100k words a year. That's something
| like 150 pages depending on how you format it. This includes both
| technical documents (which I mainly do in Latex) and more
| traditional long-form writing (which I do in Markdown).
|
| For technical documents, formatting is very much a key part of
| the presentation, so I want to see the markup. I mainly use Emacs
| and I render the PDF from the terminal when I want to see it.
| Fidelity to the final result is essential, so I don't bother with
| Latex IDEs (unless I'm doing collaborative editing on Overleaf).
|
| For my long-form writing, I want the markup to get out of the
| way. I use Markdown because it's simple and portable and
| generates a large number of formats (via Pandoc); that does NOT
| mean that I want the asterisks and hash signs and so on staring
| me in the face. Also, frankly, it's just easier to write when the
| text looks pretty. For most of this writing I write in Typora
| (with a nice variable-width font), and then edit in Emacs with
| the generated PDF side-by-side.
|
| Why bother with Markdown at all? Because Word ultimately gets in
| the way of me producing nice documents. The fact that I can move
| my cursor to see exactly what the markup is, and that this markup
| is simple and straightforward and maps well into what I'm trying
| to generate, helps me focus on content and avoid distractions.
| Word has far too many knobs, far too many ways to do something
| that looks _visually_ correct but generates the wrong markup
| (especially when you 're going to do post-processing in some
| other tool), and really hinders refactoring (when you need to
| make global style changes). So I use Markdown, but again, that
| doesn't mean I want markup staring me in the face.
|
| I'm not sure why people are so incredulous that this is a
| desirable goal? I mean it should be pretty obvious that the apps
| would not exist if there wasn't a market for it, so clearly I'm
| not the only one who feels this way.
| verdverm wrote:
| There are some editors, like TipTap, that output a json object,
| even though they look like they could be markdown editors.
|
| This is my goto React Markdown editor, very solid out of the box
| and customizable in all sorts of ways
|
| https://uiwjs.github.io/react-md-editor/
| Doctor_Fegg wrote:
| > I have no idea why there are now apps that use Markdown as
| their back end storage format but only show styled text without
| the Markdown source code visible.
|
| Because backend storage of rich text is not a solved problem?
|
| RTF is a horrid, over-complex serialisation. Some platforms have
| their own internal format for rich text (e.g. NSAttributedString)
| but serialisation is either lacking or platform-specific.
|
| Writing as WYSIWYG but storing in the backend as Markdown is not
| an insane idea, and I say that as someone whose muscle memory has
| been cmd-B/cmd-I since 1992 and would never choose to actually
| compose in Markdown unless I had to.
| throwmeawaysire wrote:
| People say that Markdown is isomorphic to HTML but HTML has <b>,
| <i>, <em>, and <strong>, while Markdown bold and italic almost
| always get transformed into <em> and <strong>, right? According
| to MDN the HTML standard defines clearly very different semantics
| for the elements, although IIRC there was once a drive to move
| away from <b> and <i> as presentational, which is why people
| started using <em> and <strong> instead but in a way as if they
| were presentational, kinda defeating the point. IDK, what do you
| think?
|
| "<b>: The Bring Attention To element" "<i>: The Idiomatic Text
| element" "<em>: The Emphasis element" "<strong>: The Strong
| Importance element"
| bastawhiz wrote:
| If you only care to expose limited formatting to the user,
| whether the file is stored in Markdown or not is immaterial. It
| could be stored in Word 2003 DOC format and export to Markdown,
| and if the serialization and deserialization are faithful, it
| doesn't matter at all.
|
| Markdown is portable, fast, safe, and simple. Being able to dump
| your data as Markdown (which you know works, because the Markdown
| version is the literal source of truth) means you're guaranteed
| to be able to extract your data and move it wherever you want
| with perfect fidelity. That's a huge bonus.
|
| The argument here is pointless if your concern isn't the syntax:
| Markdown _as a serialization format_ versus Markdown _as a
| typeable syntax_ are two separate concerns. The UX of a tool
| meant for editing Markdown is going to be extremely different
| than a tool to edit simple rich text.
|
| In my own app, I default to WYSIWYG with an option to edit the
| raw markdown (for podcast show notes, which have very limited
| formatting options). Why? Because the alternative is HTML and
| that sucks to write by hand (especially if you can't use most
| tags).
| dogsledsleddog wrote:
| I think the don't do it if you are mixing, purist thinking cycles
| through for each UI and is generally pointless and doesn't serve
| people who take it up.
|
| All the rat poison oriented window managers also have a great
| point and the ones with no mouse support at all might be perfect
| for many but it is silly and counter productive not to provide
| the mouse support because it is an anti pattern and pretend that
| all the users who need to see the benefits of avoiding the anti
| pattern, and practice [not] using it, are going to somehow
| magically end up trying the purist UIs.
| j1elo wrote:
| Before I learned the existence of Markdown, the intuitive most
| logical markup for me was (and after 10+ years of writing
| Markdown, still is):
|
| * *Asterisks* should be bold. Like WhatsApp and Slack do. Because
| they bring attention to the eye, marking a strong emphasis, and
| also because for italics there seem to be a much better
| alternative.
|
| * /Slash/ should be _italics_. Young me thought this was so
| obvious! Because _italic text is leaning to the right_ , just
| like the slash bar. (Note that with time I ended up realizing
| that this would be a bad idea because slashes are too commonly
| used in plain written language. The parser would need to be too
| clever. But still, seemed nice for a while :-)
|
| * _Underscore_ should be underline. I mean, the name says it all.
| This is so obvious to me that I never understood how it's not the
| case. I had been writing _this_ to visualize an underlined word
| for so much time before learning Markdown, that having it for
| italics just _feels strange_.
|
| Anyway. If someone knows some resource about the thought process,
| discussions, or decisions that were made to adopt the current
| syntax (especially to decide that _underscore_ should italicize,
| which feels so strange) please let me know, I love reading about
| that kind of thing :)
| tasuki wrote:
| In polite society, underlined text is not a thing.
|
| I'm with you wrt slash for italics, but sometimes you also just
| want to write a slash... how would you do that? Underscores are
| good because you never really want to display them...
| indoordin0saur wrote:
| If you're documenting technical things (what markdown is most
| commonly used for) underscores need to be displayed all the
| time because they are common in all sorts of resource and
| variable names.
| j1elo wrote:
| Just adding that for technical terms that include
| underscores, I am on the camp that most if not all of the
| times they should also be marked as such (as a technical
| identifier of something) with `backquotes`. Which solves
| the issue of having unexpected formatting.
|
| I agree, however, than my original naive idea of using
| slashes was not so good. Obviously some practice gives a
| better understanding of the problem, and nowadays I see it
| differently. The slash is too common in written language;
| it's actually a good thing that unintended italics are not
| introduced after writing some trivial slashed term in a
| text, such as "he/him".
| indoordin0saur wrote:
| Agree on the backquotes
| desas wrote:
| Use / for a slash and use // for //italics// and make *bold*
| match.
| BalinKing wrote:
| This is precisely how Org mode works in Emacs, IIRC. Now I'm
| curious who was the first person to invent this syntax--like
| you say, it seems like a very natural choice, so I'd be
| surprised if it doesn't have a long history of some sort.
| spc476 wrote:
| Back when most writers used typewriters, the convention was to
| use the underscore to mark text that was to be italicized. And
| because they were using typewriters, they would backspace to
| the first letter of a word or phrase, then type the underscore
| under each characters to be italicized. When computers came
| along, backspace worked differently (back up, replace character
| with space), so the convention was to start and end the
| word/phrase with an underscore, _like this_.
|
| Using asterisks for bold is again an adaptation for computers.
| With typewriters, you could just back up and retype the
| word/phrase to get a bolder look (maybe a few times to really
| make it stand out).
| samstave wrote:
| This is how it was in yee olden times... I've asked a couple
| time that HN takeone the content boxes of reddit's markdown.
| What I do with markdown (copying formatting of tables and such
| super well, is to paste it into the 'Visual Tab' in Rstudio,
| and then click to the CODE tab and copy the properly formatted
| markdown, then past that into a reddit comment and get the
| great formatting that I want.
|
| For example when I have GPTs spit out tables for researching a
| topic.
|
| https://i.imgur.com/4gIGYLu.png
|
| https://i.imgur.com/DJVhrUr.png
|
| https://i.imgur.com/aTRWN5S.png
| preommr wrote:
| 90% sure the reason is that new users, not familiar with the app,
| want to see that the change is actually taking place. Without it,
| the user may expect the post would literally be '*text*' instead
| of being bolded.
| rubymamis wrote:
| > I have no idea why there are now apps that use Markdown as
| their back end storage format but only show styled text without
| the Markdown source code visible.
|
| The reason why we do in Plume[1] is simple - we want a WYSIWYG
| editor for our non-technical users, yet also the reassuring
| longevity of a plain text format such as Markdown. Simple as
| that. In my opinion, it's a combo that's hard to beat.
|
| [1] https://www.get-plume.com/
___________________________________________________________________
(page generated 2024-08-15 23:01 UTC)