News for hackers. Stuff that matters.
Re:GitHub satanically messing with Markdown – changes 666 to... by input_sh on Tuesday November 26, 2019 @01:50AM (#21636131)
Let's say you have a list with 50 items and want to add one item in between. Instead of updating all the indexes, you just type a number and Markdown does that for you.

In any case, it can be escaped by writing 1\. instead of 1.

Re:GitHub satanically messing with Markdown – changes 666 to... by Dylan16807 on Tuesday November 26, 2019 @02:40AM (#21636321)
I can't think of any reason I would want half my list indexes to be wrong in my source file.

I can think of plenty of reasons I would want to use auto-numbers while removing explicit numbers. But this is insane as a default behavior.

Re:GitHub satanically messing with Markdown – changes 666 to... by CarlRJ on Tuesday November 26, 2019 @11:21AM (#21639647)
> I can't think of any reason I would want half my list indexes to be wrong in my source file.

Agreed. The bit about "oh, well, it fixes mistakes if you rearrange items" falls in the astonishing (in a bad way) camp far too often. When you really meant to number the lines, "2, 4, 6, 8" and it "helpfully" changes this to "1, 2, 3, 4". Arguably it's bad also in a list that has been maintained over time and has out-of-sequence numbers, where the users are counting on the processor to renumber - now, if someone says to change item 37, is that the one numbered 37 in the rendered output, or in the source? Better to use a tool of some sort to physically renumber that section of the source document.

A better alternative for auto-renumbering would be to only have it kick in when the entire list all starts with "1. " and there's more than one line in the list (so "...meet me at<next line>1. Then we'll..." doesn't end up with a line being dragged into being a numbered list). Then, the repeated use of "1. " at the start of the line becomes a much more obvious indication that you want to numbered list.