Markdown preview is now available when writing topics/comments/etc.
Continuing to work my way through (long overdue) merging of open-source contributions, today we've got another much-requested one that was implemented by @wirelyre: a preview function for markdown.
Anywhere that you're writing markdown now (comments, topics, messages, user bio), there will be two "tabs" above the text field for "Edit" and "Preview". You can flip back and forth between them to see what the result of your markdown will be while you're writing, which should make it a lot easier to work on some of the tricky formatting like tables.
Like so many other features, there are still a few little weird interface oddities with it, but I wanted to get it live on the site and will probably do a few more minor tweaks to it today. Let me know if you notice anything particularly strange or broken with it.
And thanks again, @wirelyre!
I don't think people give enough credit to the difficulty of accepting open source contributions. It's hard enough keeping track of code you wrote; taking what someone else wrote and even just making sure it works is much harder!
Now a call to action:
If you're at all interested in making a contribution to Tildes, please go ahead. I'd never done any kind of web framework stuff before, but the Tildes codebase is exceptionally well organised and easy to read.
As someone familiar with tech (4th semester computer science student) but completely unfamiliar with web dev, do you have a good point to start?
https://docs.tildes.net/development-setup is a good place to start for Tildes specifically. It walks you through forking the repo, getting the prerequisites installed and setting up the Dev environment using vagrant so you can play around with it.
But if you're talking about a good place to start for webdev in general, then it really depends on what tech stack you plan on working with or want to learn.
E.g. AFAIK Tildes stack is (might get some of this wrong since I am still learning it myself):
scripting = Python 3.7, javascript + intercooler + jquery
server = nginx, gunicorn
templating = jinja2, pyramid
database = PostgreSQL, Redis, SQLalchemy + alembic + webargs
CSS = spectre.css, Sass
Although this is a fine description of the tech stack, it's kind of overwhelming. I spent a lot of time skimming through all that documentation and frankly most of it was unnecessary. The code is all right there after all — you can just read it and see what it's doing!
So here's where I'd start:
This way you won't get bogged down in APIs and reading technical documentation. If you need to write more code, open the file where it's going to go; there's probably hints for where to start just a few lines up!
This might sound like a hacky or shallow way of working with the code, but it's not. You're observing the subset of the API which is actually used in this project, and also accurately reproducing the house style.
@Deimos, is there anything particular you are doing with jQuery that can't just be done with native Javascript in the browser? I haven't really needed to use jQuery for any clientside development for a while because browsers are at that point where features like
.querySelectorand such are so widely supported.Intercooler (which handles all the ajax-y stuff on the site) has it as a dependency, and I think some other things I'm using depend on it as well (like "areyousure", which adds the confirmations when you try to leave a page with a modified, unsubmitted form).
Honestly, people worry way too much about jQuery. It's tiny, can be cached indefinitely outside of version updates, and does a lot of things well. It's a tempting target and eliminating it feels good, but it accomplishes very little overall.
I don't know about others, but I'm not a fan of this feature. It might be the one thing I dislike about Tildes. Sometimes I decide to abandon comments when I think they're non-contributing or maybe overly-aggressive. Getting a prompt when trying to close the tab is really frustrating. I was annoyed when reddit added the same feature a few years back.
I understand the idea is to prevent accidental page closes, but that's just never been an issue for me.
IMO accidentally leaving a page when you were in the middle of typing a huge comment with tons of markdown in it and having to start over as a result is far, far more frustrating than only occasionally having to hit the confirmation to leave the page intentionally every once in a while.
I'm sure that's true in a general sense - I'm just giving my personal preference. I almost never lose comments, and I can't remember a time I've ever been saved by this feature. I am however frequently interrupted by it. For that reason I wish I could disable it.
Fair enough. Added it as a suggestion to Gitlab:
https://gitlab.com/tildes/tildes/issues/449
Ah cheers. I wouldn't be too surprised (or upset) if it's closed in an effort to prevent settings page overload, but I appreciate you submitting the suggestion. We'll see what Chad thinks.
Yeah, I think I'll close it, but to explain my reasoning a little:
I understand why it's annoying. It is, by nature, something that gets in your way. When you've already decided that you want to leave the page, that's frustrating. You were trying to do something, and it made that harder for you. That's not what it's trying to do though, it's basically a side effect. It's trying to prevent accidentally leaving the page, and there isn't really any way to distinguish between leaving deliberately or accidentally.
Personally, I know that it's saved me multiple times from losing a post when I do something like accidentally push a hotkey or misclick when I'm trying to open something in a new tab, and I think that's worth the minor inconvenience of needing to push Enter or click one more time when I abandon something deliberately (which really isn't that common).
If you want to avoid it, you can always just click the "Cancel" button to discard your partial reply first (assuming it's a reply to another comment), or do a quick Ctrl-A, Backspace to delete the whole post - it won't pop up if the form is empty. It's about the same amount of work anyway, but maybe it feels better because the discarding becomes a deliberate action as well.
Updating my muscle memory to delete the text seems like a good suggestion, and I'll see if I can work on that. Thank you for the explanation.
Bit of a side note, but this is similar to a problem that Google Chrome solved some ten years ago. Browsers used to ask you to confirm when you'd close a tab, just in case there was something important there. Google took the approach instead to always close the tab immediately, but to build in a "restore tabs" feature to make it easy to undo the action. They had found an alternative solution to reduce friction.
Other tools seem to have embraced this idea as well. Sublime Text and VS Code will store unsaved documents and open them back to where you were last time. No more "You have unsaved changes" prompts.
I wouldn't actually suggest Tildes implement something like this. Such a feature unfortunately doesn't jive with Tildes' philosophies (as I understand them). It introduces complexity, adds more reliance on fancy scripting, and may have privacy implications.
I really just bring up these examples as I think they provide some clever outside-of-the-box thinking, and it seemed relevant enough. Sometimes it's nice to appreciate just how much better software has gotten in the last 15 years, too.
If privacy is the biggest of the concerns, maybe the comment-in-progress could be saved in the browser's
localStoragewhen the window/tab is closed that can be restored later. Comment wouldn't leave the user's machine. You could even use it to provide a Local Drafts user page. Could make it a user setting and gracefully fall back to the confirm-leave-alert if turned off or JS is disabled.Ooh! Fancy stuff! It's nice to see something like this. There's:
An Edit tab.
A Preview tab.
And when I click between them, I see the different formats (like this) in my comments, so I don't have to save my comment to see if I got the formatting
wrongright, and then ninja-edit it.Nice!
It would be better to see a live preview below the text field as I type, rather than having to click back and forth between tags, but this is definitely an improvement. Thanks, @wirelyre!
Live preview isn't very feasible, unfortunately. To make it work you need to either:
Both of those options aren't very good. They both add a lot of overheard (of one type or another) for something that's unnecessary the large majority of the time, since most comments only include straightforward formatting.
Understood. Thanks for the explanation.
Dynamically loading a clientside markdown editor when clicking "Preview" doesn't seem too crazy to me?
The markdown on Tildes isn't completely standard. There are a number of behavior changes (of varying significance) that would all need to be re-implemented into the editor to make it match up with the actual result you'll get when you submit the post. Depending on the editor, it may not even end up being possible to implement some of the changes without major rewriting. Some parts (like the sanitization of HTML that happens after the markdown is processed) would be extremely difficult to duplicate.
It would be a ton of effort for something that's only particularly useful in niche cases.
I wonder how people would handle a split, with a live preview based on the core markdown engine displayed somewhere near the input, plus the tab for the proper preview. We’d have to think of some good terms to distinguish the approximate preview from the full preview. I think it would be useful to get people close enough as they type for the most commonly used markdown, then they can check the final proper render with the tag before submitting. I do see how it could be a bit misleading if we can’t find a way to convey the difference clearly.
Yes, but it's a lot of extra code that
It wouldn't bloat page sizes if it were dynamically loaded. I hear you on #1 though, this is one of the reasons why I have a lot more appreciation for SPAs with the ability of reusing the exact same code paths when rendering things serverside.
My life circumstances have changed significantly since I joined Tildes, and I am now dependent on (relatively fast) wireless broadband with a data cap each month. It's enough for me to do my job and use the internet, but, I've come to appreciate Tildes' small size and lightweightness.
Let's not change that too much.
I feel like you're not hearing the fact that it wouldn't bloat page sizes if it were dynamically loaded.
If it's dynamically loaded, it's still coming down the wire. Just asynchronously. So there's still a net increase in xfer size. Sure, you can cache it, but caches are unreliable (busting, user clearing rules, etc).
So you're getting a markdown engine, which you will load once and which will allow you to do live previews etc; as opposed to getting the entire HTML payload every single time you want to do a preview.
The ROI on it is ridiculously fast. If you care about your data cap, you'll much rather have the JS engine than the serverside HTML one.
RES (reddit enhancement suite) pretty much has live preview no? Which one of those do they use?
Tildes Extended offers that, and it was co-written by @Bauke, so I'm surprised it hasn't be implemented here. This version is nice though, and may be better for mobile.
It helps to have instant feedback as you're typing. A preview on an alternate screen is still helpful, as I said, but a live preview can let you know instantly when you've done something wrong, so you can fix it before you make more mistakes.
The live preview for Tildes Extended seems to actually be broken at the moment, at least when writing text topics or top level comments. The live preview works fine for replying to other comments though.
I just noticed that it isn't working for me, and it was working earlier today, so something having to do with a recent change? Tested on both Firefox and Chrome. @Bauke @crius
Ninja EDIT: It works sporadically, it seems. As soon as I posted this comment and started writing my own top level comment, without refreshing the page, the live preview started working where it hadn't been earlier.
Don't remove the live markdown preview please. It might not be as accurate as the Tildes one, but at least leave it as an option. Live preview is way nicer in most cases.
I don't. I haven't even loaded it on this machine, so obviously I didn't need it that badly.
Agreed with your other comment on the current version here being just fine.
Just a heads up, automatically quoting highlighted text when a user clicks the
Replybutton seems to be broken.I really like this solution, there's just one small annoyance I noticed:
I can't remember the last time I wrote a comment and didn't expand the
textareato see more of what I'd written and when I click thePreviewbutton, thedivthat comes up with the preview isn't the same size as the resizedtextarea. When I clickEditto go back to writing, thetextareacomes back at the same size I had it before viewing the preview, but because the previewdivwasn't the same size as thetextarea, the page height gets pushed and I have to scroll down to see the wholetextareaagain. This happens because thetextareais pretty much always larger than the previewdiv.I'm not really sure how to alleviate this. I'd say that when the
textareagets resized, always display the previewdivas the same size as well, that way the page doesn't get pushed around, but if thetextareaisn't large enough to fit the whole comment, then thedivwould display larger than thetextarea,essentially reversing the issue.EDIT: Actually, no, this would be fine, wouldn't it? Because, even when the
divis larger than thetextarea, it doesn't push the page down when you preview the markdown, and going back to editing the comment doesn't move the page either, unless you're at the bottom of the page, in which case you'll automatically be looking at thetextareaagain anyways, I think. Yeah, that seems correct and would totally be fine I think.So yeah, just resize the preview
divat least as large as thetextareaas a minimum and up to as much space as is needed to display the entire comment as a maximum and everything should be fine.Of course, you could also just match the size of the
textareaand thediv100% of the time, and just make the previewdivscrollable, but that doesn't accurately reflect the actual length of the comment.Either way, I don't know how you would match the size of the preview
divto thetextareaas a minimum value.Whoops, thanks. That part should be fixed now.
Good feedback about the textarea/preview sizes too. I'll tinker with that a bit and see if I can figure out something that works well, thanks!
I'm pretty sure I was editing my comment when you replied, so you might not have seen it and I'll just ask here instead:
Is there any way we could just get a larger default size for the
textareaat the bottom of topics or when replying to comments? I'd be willing to bet (but could totally be wrong) that most users manually click, drag, and expand thetextareaanyways, so having it default to a larger size might be nice and shouldn't get in the way of anything.Haha, well, I'm not sure you're a very typical case. I generally don't change the textarea size most of the time, usually only when I'm writing longer posts like the ~tildes.official announcements.
Just for fun:
It might be possible to make it bigger, but I don't want it to be too huge either. You could also use Stylus or a similar extension to be able to set the size to start out larger on your end as well (I can tell you how to do that if you want).
Ha, alright fair enough, I guess I might not be the most typical case. I knew I had a habit of writing long comments, but I didn't realize it was that bad. That's almost three times longer than the average!
As far as just using Stylus, I didn't even think of that. Here's what I came up with, for anyone else who might be interested:
I tested everywhere I could think of that has a
textareaand they all worked. If anyone needs help setting up the Stylus browser extension and actually creating the custom style, let me know.Yep, that's exactly it. If you want to make sure it only affects the markdown ones specifically you could change it to
.form-markdown textarea.form-inputinstead.Now do me! :P
582 for you.
Thanks! (And to @Bauke as well.)
At least I found one thing I'm above average at... ;)
I did not even know this could be done until this very minute. You learn something every day. Thanks for that!
And, now that I now about this feature, I may use it... but only very occasionally.
I found a bug. Let's say I:
Hello Worldin a comment.Hello Worldwill still be written in the preview.Edit: To make this clearer. You can also remove by pressing Backspace a couple times. In that case, only the
Hwill remain in the preview.Just to clarify this scenario, based on my quick testing of @Apos' description: this happens only if you delete all the text in the comment field. If you delete only part of the text, or delete all the text and type something new, the preview updates correctly. It's only if you delete all the text and leave the text field blank that the preview doesn't update correctly.
Thanks, I'll fix that. (@Algernon_Asimov and @Apos as well)
Edit: should be fixed now.
Now that was some solid teamwork.
Ohhhh, bitchin'! Thanks, @wirelyre!
Aaand now I've disabled Tildes Extended. <3
We need a trophy case and a code monkey trophy to hand out to contributors. Let's just not make the trophy case as lame as reddit's has become. :P
Maybe a ~contributors or something instead of a trophy cabinet? So you can see who did what without cluttering the user profile page. I really like how unfussy it is at the moment. Don't know how feasible that would be if tildes gets big though.
Tildes Gitlab - Repository - Contributors
Yeah, but it'd be nice if that was somewhere on Tildes itself, I think.
Yeah, sorry, I wasn't trying to poo-poo your idea... and I think it would also be nice to visibly reward people for contributions on Tildes itself somehow too. I was just trying to point out there is a place on Gitlab with that information, for anyone curious.
Fantastic contribution @wirelyre, I was just wishing for this yesterday. :-)
Really happy to see this implemented, thanks @wirelyre!