News for hackers. Stuff that matters.
Re:GitHub satanically messing with Markdown – changes 666 to... by baroffoos on Monday November 25, 2019 @11:22PM (#21635623)
The point of the numbering changes is if you want to insert a new item half way through the list you don't have to change every single line. Unfortunately it probably confuses people more often than it helps them.
Re:GitHub satanically messing with Markdown – changes 666 to... by c3534l on Tuesday November 26, 2019 @02:04AM (#21636177)
I've come to the conclusion that the worst thing about how developers design their products is the existence of "features" that override the user without the user ever telling it to. It assumes you wanted to do something other than was was inputted without getting further input from the user indicating they wanted to carry out that action. Pretty much every massive technology fuck-up in my life has been the result of the computer doing something other than what I told it to do and me not realizing or not being able to fix it after it did so. Things like "open restored document" helpfully deleting the older, unrestored document for me, attaching signatures to emails when I didn't configure a signature, etc. I want to start a movement that forces us to ask every new feature "did the user tell the computer to do X and if so, where is it indicated that X will happen?" There are a million examples when you look out for it and they're all infuriating.
Re:GitHub satanically messing with Markdown – changes 666 to... by _0ffh on Tuesday November 26, 2019 @04:42AM (#21636814)
Oh thank god I'm not alone in thinking that this is a horrible way to design a "feature"!

I've had very similar experiences as you. Every automatic "correction" of user input needs to at least be clearly indicated and easily reversible. In my opinion it shouldn't even happen until the user actively signed off on the proposed modification.

Re:GitHub satanically messing with Markdown – changes 666 to... by CarlRJ on Tuesday November 26, 2019 @10:47AM (#21639255)
Hitting far above its weight in this category is autocorrect (my wife took to calling it autocarrot in a small act of rebellion), which "helpfully" corrects millions of painstakingly correctly-spelled obscure words into completely wrong but more common words, every day, making human communication less understandable.
Re:GitHub satanically messing with Markdown – changes 666 to... by coldpie on Tuesday November 26, 2019 @08:59AM (#21638274)
Ehhhh I agree with your general point, but I'd argue Markdown's list behavior shouldn't be tarred with this brush. It's a reasonable feature that makes perfect sense if you understand it, but in practice it didn't survive contact with the real world. Nothing is perfect, after all.
Re:GitHub satanically messing with Markdown – changes 666 to... by JadeNB on Tuesday November 26, 2019 @10:04AM (#21638827)
> It's a reasonable feature that makes perfect sense if you understand it, but in practice it didn't survive contact with the real world.

I think the same argument can be made for almost every "the machine knows better than the user" decision, so it seems to me that this is pointing out that the Markdown list behaviour should be tarred with exactly the same brush.

Re:GitHub satanically messing with Markdown – changes 666 to... by c3534l on Tuesday November 26, 2019 @03:14PM (#21642197)
> It's a reasonable feature that makes perfect sense if you understand it,

This is true of all these features in general. They're all well-intentioned. No one wants to design a system that annoys users. But my criteria is meant to illustrate why it might not have been a smart idea to begin with: the user didn't indicate they wanted the system to renumber their bullet points. In fact, very often the user indicates that they want a specific numbering by placing specific numbers. The feature would work if there was some way to indicate this is just a bulleted list with numbers. Instead, the system assumes 100% of the time that the user made an error, then fixes that error in a way that is difficult to detect without ever providing feedback about the changes. That's a bad system that happens to usually be trivial or at most embarrassing. But the design itself is flawed from first principles.

A better way to implement auto-numbered lists would be indicate you want to use auto-numbered lists, just like you indicate you want to use headings, links, or any other element. First, don't rewrite all numbers, making the fact that a correction is taking place under the hood invisible to even experienced users. Auto-numbered lists should be indicated by having multiple lines starting with, say, "<space>0.", or even better "<space>#." to be more congruent with the use of "#" for headings and subheadings in other markdown systems (languages?). Second, when a user submits a post, the system should indicate what has been changed, perhaps with a non-intrusive highlight.

The problem would never have arisen had the developers asked my two questions "did the user indicate X?" and "where/how did the user indicate X?"

I suppose you should add onto that "is the change transparent to the user?" which is also known to cause some potentially life-threatening errors: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_... - you probably think "it's markdown, what's the big deal?", but who knows. Maybe someone gets some medical or chemistry advice and, sure, they shouldn't trust reddit, but then maybe someone dies anyway. So I think it's always best practice to indicate that a change has been made.

Re:GitHub satanically messing with Markdown – changes 666 to... by bloak on Tuesday November 26, 2019 @04:26AM (#21636731)
Besides confusing people, I'd say it's a useless feature for a couple of reasons:

1. If you insert a misnumbered item in the middle of the list then when you come back later to edit the text you will be confused by how the numbers in the source are different from the numbers in the formatted output.

2. There's no point in using a numbered list unless you're going to refer to the number(s) somehow. (In this case I'm using the word "couple" to introduce the list!) Markdown doesn't sort out those references for you so in practice you have to manually renumber things anyway.

Re:GitHub satanically messing with Markdown – changes 666 to... by TeMPOraL on Tuesday November 26, 2019 @05:16AM (#21636992)
This is like dealing with that clueless newbie who desperately tries to help you, in the process creates a huge mess. You'd tell them to stop, and ask for permission before doing anything.

I propose a new term: paternalistic software. It's software that overdoes being helpful, and becomes annoying or dangerous. It's the software that does things you don't want automatically, because it thinks it knows better than you. Automatic renumbering and autocorrect both fall under this.

Re:GitHub satanically messing with Markdown – changes 666 to... by JadeNB on Tuesday November 26, 2019 @10:06AM (#21638845)
> It's software that overdoes being helpful, and becomes annoying or dangerous.

It looks like you're trying to write a rant against Clippy. Would you like help?

Re:GitHub satanically messing with Markdown – changes 666 to... by TeMPOraL on Tuesday November 26, 2019 @10:21AM (#21638997)
Clippy was annoying, but at least it was personified enough to serve as a single point of blame. But more than that, it didn't actually do anything automatically for you. It was kind enough to ask.
Re:GitHub satanically messing with Markdown – changes 666 to... by majewsky on Tuesday November 26, 2019 @06:54AM (#21637488)
I used to call it "overly-clever syndrome", but "paternalistic software" is way better. Thanks for this word.
Re:GitHub satanically messing with Markdown – changes 666 to... by asudosandwich on Tuesday November 26, 2019 @05:23AM (#21637036)
Sounds like my web browser.
Re:GitHub satanically messing with Markdown – changes 666 to... by reacweb on Tuesday November 26, 2019 @04:03AM (#21636627)
I am working in ATC (air traffic control). Controllers prefer a dumb tool with easy to predict deffects (like STCA) instead of a smart tool with infrequent random failures. Simplicity is underrated.
Re:GitHub satanically messing with Markdown – changes 666 to... by blowski on Tuesday November 26, 2019 @04:06AM (#21636635)
I take your point, though I’m less bothered about errors on Reddit formatting than I am errors in air traffic control.
Re:GitHub satanically messing with Markdown – changes 666 to... by larntz on Tuesday November 26, 2019 @08:04AM (#21637883)
I use this "feature". But generally I use the same number for all items because it is a pain to have to renumber everything.

maybe the solution is to renumber if a list uses all 1's, but leave it untouched if it has different out of order numbers.

So this gets renumbered:

1. item 1

1. item 2

1. item 3

But this does not:

1.

3.

7.

Re:GitHub satanically messing with Markdown – changes 666 to... by pbhjpbhj on Tuesday November 26, 2019 @08:47AM (#21638194)
Shouldn't things like numbering be part of the UA, then the user can decide (directly or give the job to a plugin).

Reddit could then offer "use our text-editor assistant in your browser" to those who aren't using one.

The text box would have to define what it allowed as input: alnum, plaintext, markdown, etc., and the appropriate plugin would activate?

Re:GitHub satanically messing with Markdown – changes 666 to... by sammorrowdrums on Tuesday November 26, 2019 @01:31AM (#21636051)
I'd also add that while I agree with the confusion expressed, using code snippets to escape from markdown parsing is important when sharing stuff that literally contains markdown. Of course that depends somewhat on the provider and what custom flavour of MD they use, which is often contraversial.

Like #463 GitHub auto linking, which I usually like, but occasionally been caught by it.

Re:GitHub satanically messing with Markdown – changes 666 to... by dchest on Tuesday November 26, 2019 @02:17AM (#21636221)
Or there's no point and it's just a consequence of turning numbered lists into <ol>.
Re:GitHub satanically messing with Markdown – changes 666 to... by enriquto on Tuesday November 26, 2019 @04:27AM (#21636735)
that's what plain html is for! I don't really see the point of markdown. With modern html5 you do not even need to close most tags.
Re:GitHub satanically messing with Markdown – changes 666 to... by irrational on Tuesday November 26, 2019 @09:54AM (#21638722)
I don't know. Even though I know HTML, I'd much rather create a bullet list by putting an asterisk in front of each item than writing a bunch of <ul><li> tags.
Re:GitHub satanically messing with Markdown – changes 666 to... by JadeNB on Tuesday November 26, 2019 @10:08AM (#21638862)
> I don't know. Even though I know HTML, I'd much rather create a bullet list by putting an asterisk in front of each item than writing a bunch of <ul><li> tags.

But I wouldn't—and it's a lot easier for you to process your Markdown and paste it into an HTML-enabled text field than it is for me to process my HTML and paste it into a text field that understands only one of the flavours of Markdown that doesn't have sufficient escape hatches built in (or that, like most flavours, has lots of features built in that you're apparently supposed to discover only by experimentation, preferably without any sandbox or preview available).

Re:GitHub satanically messing with Markdown – changes 666 to... by feanaro on Tuesday November 26, 2019 @08:40AM (#21638137)
IMO, plain HTML is much more confusing and quite a bit less legible.