Not yet. I might do that later, but it requires some cleanup work.
The code has three parts: Markdown to HTML text, HTML DOM to Markdown, and the editor. The total size is about 30KB uncompressed (27KB JS + 3KB CSS). It didn't use any icon font or images.
It does not force you to use mouse click on GUI elements. You can use `⌘`+`/` (or `Alt`+`/` on Windows) to switch between WYSIWYG/Markdown modes. Actually it's the preferred way unless you are on mobile devices.
The default mode is WYSIWYG since Markdown syntax frustrates people who don't know Markdown well.
Thanks for mentioning Typora! It's an interesting implementation. I've thought about that approach (in-place real-time preview as you type Markdown text) before, but inside a browser, it's too cumbersome to fight against the inconsistent contenteditable behavior.
Yeah, European keyboard layouts are annoying like that. Too bad that it seems unlikely that they would ever change even if there is some talk in France that they want to reform their keyboard: http://arstechnica.com/tech-policy/2016/01/france-says-azert...
There was a project in Finland to reform keyboard layout ("Kotoistus"), only thing they managed to do is to add more dead-key accents and make the keyboard even more annoying to technical users. In all their great wisdom they decided to add non-breaking space character to altgr-spacebar key combination. In isolation that might seem like a good idea, but when also | character required the use of altgr-modifier it was a mess: working with the command line, you tend to have stuff like ... | grep foo. Soon enough there were plenty of users wondering why bash complains that grep is not found: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/218637
Personally, I have abandoned national keyboard layout and adapted US layout instead. Makes both programming and general use much more comfortable. Its amazing how much less I need to use modifier keys now, especially the painful altgr.
The French project would be even worse for us French coders.
Symbols used for code would be hidden behind several layers like altgr combinations. While, imo, archaic symbols (ÇÀÉÈàçê, etc) would be on the first layer.
I'm planning on doing the same as parent, using the US layout, but I can't change my keyboard at work, and although I can type in qwerty, I don't know all the layers like I do azerty, so I can't just type without looking.
Well, we ended up using quill.js in our own system (it's rad, and pretty easy to wire into an operational transform system to handle concurrent edits). But at least at the time we were looking, discourse was markdown only.
We had a lot of needs that weren't met by other FOSS platforms, so it wasn't just rich text, but rich text was a big driver there.
Forum anonymity (or more precisely, disposable account) is the source of moderation pain and the reason of suboptimal forum content quality. It's one of the main issues I want to address from day 1. If FB account puts a lot of people off, I may consider adopting SMS verification sooner, or change the yearly subscription to a one-time small fee.
It seems Markdown editing is a red flag for broader adoption. I've thought about a dual approach before: allow casual users to edit with GUI, and provide the Markdown editing capability for pro users.
I do not have a fool-proof way to prevent plugin copying. If somehow it's widely copied, it's not a bad thing (to most people), too.
As someone who's run a ton of forums, I disagree it's the source of suboptimal forum content quality. If I had forced real names and identities, I would have lost a significant amount of users and activity. And not just trolls and spammers either.
A lot of people like to keep identities separate. Any system that tries to remove the anonymity site of things will end up stifling quite a few people who worry about their personal information being misused or who don't want everyone to know about their every activity online. That's not a bad thing, especially not in a world where intelligence agencies want to spy on everything you do, you could lose your job because of some comments on Facebook or Twitter and being swatted is sadly quite common.
Not everyone wants their friends and family to know they're an active member on say, Donald Trump Fan Forums. Or that they're posted leaked content from an upcoming game, like quite a few people on 4chan or Reddit. Or that they're interested in setting up a Tor node.
As for markdown, yeah, your solution there is exactly the solution. A GUI for new users, a raw editing text box for pro users. It's like how a lot of forum editors switch between BB code/raw text and a WYSIWYG editor.
Plugin copying is a good thing here (because the features mentioned could be good in other scripts), but I'm just warning you'll need quite a bit more if you want to differentiate themself enough from competitors in the market (of which there are thousands).
People seem ok with a lot of awful things. I don't see that as an argument for Markdown.
The question is: has Reddit (or other Markdown users) actually studied Markdown's usability? Even a basic comparative study against a WYSIWYG equivalent?
It seems like "techy" people just kind of assume Markdown is great and easy and awesome without ever bothering to actually make any effort to question that assumption. That's really the part that bugs me most.
And the entire pitch of Markdown is that you can style your text the way you did back when you were using text-only stuff. Ok. So _this should be underlined, then_. And /this should be in italics, right?/ And naturally this is boldfaced. Oh wait. Markdown is ZERO FOR THREE.
(Strangely, Markdown doesn't even have underline. Go figure. It's not even remotely close to feature-parity with the WYSIWYG textboxes we were all using on the web in 2008.)
I'm quite confused with a lot of your dislike for Markdown.
I have a reverse question, what is better than Markdown in your mind? I'm starting a project that is heavily based around text, and for simplicity i just wanted plain text. Ie, i have no editor for the project. So for markup, i need something. What do you feel is the right markup language?
Personally i feel Markdown is easiest markup language i've found. Compared to some, it's quite intuitive. Combined with the fact that it is becoming quite prominent means users are also learning it. The only downfall with Markdown in my mind is a lack of a standard, but i think that's being worked on (there are some attempts at that, i believe).
Anyway.. i would really appreciate your feedback, if you feel there are better pure text Markup languages :)
If an end-user is using a markup language at all, you've already screwed up as a developer of usable software.
If you're going to use a markup language, at least use one that supports basic shit like underlining text, or typing the sentence "21." without it thinking you're trying to start a list.
No matter how users are interacting with the text on your site, do usability testing. If you do usability testing in good faith, and Markdown comes out as the winner, then use it, with my blessing.
Don't base your usability decisions on gut instinct or knee-jerk reactions. Which is pretty much exactly what every site using Markdown currently is doing. AFAIK it's never been studied in front of a fair selection of users.
I believe OP means a WYSIWYG editor is much better than Markdown.
In terms of a markup language in pure text, I think Markdown is your best bet. Folks in CommonMark.org tries to "standardize" Markdown. Our implementation in Twincl.com follows that standard as much as we can.
Appreciate the reply. Honestly though, this confuses me even more. Many sites have both Markdown and a rich editor.. isn't that sort of required for users anyway? No matter what language powers your Markup, at the end of the day many users want an editor.
The median user would rather click a "add a poll" link and select options (with interactive help) rather than read a guide page on exactly how to punctuate and arrange whitespace to get a poll that works properly
You can use a verified Facebook account to join Twincl site for free. Ideally, we should use our own SMS verification process to prevent disposable accounts - maybe when we have money. Since Facebook does a decent job of fraud account prevention, we leverage their work for now.
Thanks for your comment. We'll take that into account.
...Not that I'm a fan of G+, but I am happy to use that google account identity to sign into other services.
It's because that google account identity is tied to a work email account, too... You know what doesn't go on there? What I do on the weekends. That ends up on facebook even if I don't put it there... So leave that account alone.
It's worth noting that I am permitted more than one Google account, but not more than one Facebook account.
...There MAY be some rule about not having more than one G+ account, right? But, I don't really use that service. It was only included here because it's the only "profile" page I know of for that account.
At least you must be careful when using multiple Facebook accounts from the same computer. It might cause your main Facebook account locked, and take you a while to have Facebook unlock it for you.
> 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.
Correct. When comparing a static programming language to a dynamic one such as Go vs Python, this is a critical difference. It impacts system stability (production outage rate) and code maintainability a lot, the two characteristics a long-running product desperately needs.
But Go is not comparable to C. Go is garbage-collected, so unlike Rust, it is not a true system programming language (i.e. not low-level enough). On the other hand, it is not high-level enough. It lacks many advanced language constructs, and its type system is rather limited. Simplicity is a big merit of Go, but it's too limited IMO.
Go solves many software development problems for large engineering teams, so I think its ecosystem will keep growing for a while.
