Preview after clicking "save post" is incorrect about forem

[JoshCheek]

^_^ awesome, ty!

[benhalpern]

I'm hesitant to allow arbitrary styles into the final post because of how easy it would be for publishers to create articles that look bad, especially across platforms and screen sizes and future site-wide design changes.

Under this current system of sanitizing styles, it's the client side preview that is wrong.

But, of course, the style of your post, in that exact format, is not possible. We could implement some custom classes that map to style adjustments. It might even make sense to use known classes from a popular library like bootstrap to dictate this.

[JoshCheek]

But, of course, the style of your post, in that exact format, is not possible.

Not sure I understand.

Under this current system of sanitizing styles, it's the client side preview that is wrong.

Given the non-standardness of Markdown, it might make sense to use the same lib for both server-side and client-side rendering, or always delegate to the client, or settle on a given specification such as common markdown (though even that could be fragile).

It might even make sense to use known classes from a popular library like bootstrap to dictate this.

Prob best to avoid anything externally specified, otherwise we couple the content to some version of some CSS framework, and then changing anything becomes difficult (ie all content from all time has to continue working, so if the framework releases a new version that is not backwards compatible, then we have to continue using the old version or perform some error-prone content transformation or record which version to serve with each post)

We could implement some custom classes that map to style adjustments.

That could work. Generally, I'm fine with letting the site control styling, I mostly expect it to do a better job than I will, and that decreases fragility as the site changes over time. In this case, it's not styling I'm trying to change so much as layout. If I had a way to specify this layout, I'd have no need to try manually styling:

Though it's worth noting that I have a sample point of 1 (just me, only one post), so this shouldn't be considered a comprehensive analysis. Eg it could be that I want to do something fancy at some point (Medium accommodates this with "embeds", I haven't explored their flexibility).

---

FWIW, I do like the idea of tracking the stylesheet with the content, then we could provide users with several stylesheet options, and they could choose the one that best matches their content (eg prose tends to go well with serif fonts, and technical content tends to go best with sans-serif fonts).

Given the site is targeted at devs creating and consuming dev-oriented content, it seems reasonable to expect them to have content whose presentation requires more control. Eg is it possible to write a post like this or this without sacrificing convenience in the common cases?

[benhalpern]

Yeah, right now we use showdown on the client preview and redcarpet on the server. It's been good enough so far, but since this is pretty core to what we're doing it will be a focus to improve this.

That's why our first open source extraction project is around the markdown. Depending on where this conversation goes, may make sense to break things up and discuss in that project space.

Wholeheartedly agree with the idea that devs creating and consuming dev-oriented content can guide a lot of our decisions and assumptions and is why I want to make it possible to build richer content, I still want to ensure we do it safely and steadily and not rush into any assumptions about usability and compatibility.

[JoshCheek]

I still have this issue after updating the post to remove all the HTML except a few strong tags (b/c they weren't highlighting correctly in Atom Editor, and that worried me that they were ambiguous, the <strong> seemed less ambiguous)

Further, when I published it and went to the page, it was displaying only the summary. ie the renderer for published posts is showdown, the incorrect one. Note that when I entere the content into the showdown demo, and it works correctly.

---
title:       Write a REPL in Ruby
published:   false
description: Lets build a REPL!
cover_image: 
tags: 
---

[Pry](http://pryrepl.org/), [IRB](http://ruby-doc.org/stdlib-2.3.1/libdoc/irb/rdoc/IRB.html),
and [RIPL](https://rubygems.org/gems/ripl) are popular Ruby REPLs, but, just for funsies,
lets see what it takes to build our own! Code snippets are
[here](https://gist.github.com/JoshCheek/baab86f3258ff98c468f3dbc032dc9c5).

---

Simple beginnings
-----------------

A <strong>REPL</strong> must "<strong>R</strong>ead" input from the user,
"<strong>E</strong>val"uate that input as code, "<strong>P</strong>rint"
the result, and "<strong>L</strong>oop" back to the first step to do it
all over again. So, lets start with those four steps.

![screenshot](https://cdn-images-1.medium.com/max/600/1*qWygoGudYFcFuPVMDUDKFw.png)


---


Persist local variables
-----------------------

The problem with our REPL at present is it forgets local variables 😝 That’s because
local variables are stored in "bindings" on the callstack. When we call `eval`,
it makes a new binding to evaluate the code in, and when `eval` is finished,
it pops that binding off the callstack discarding our variables. To retain the
variables between invocations, we need to evaluate them in the same binding every time.

![screenshot](https://cdn-images-1.medium.com/max/600/1*XxwgW544hDGlwXRTJ17pHQ.png)


---


Readline input
--------------

Our input is... not good 😜 But, Ruby ships with [`Readline`](https://ruby-doc.org/stdlib-2.3.3/libdoc/readline/rdoc/Readline.html),
which is like `gets`, but adds a prompt, kill ring, fancy movement/editing, cycling through previous inputs, etc.

![animated screenshot](https://cdn-images-1.medium.com/max/600/1*hy59uAXv3wTGRhQMPQ8Eqw.gif)


---


Highlight output
----------------

Looks good, lets syntax highlight our output. [Rouge](https://rubygems.org/gems/rouge)
is the way to go these days, but [CodeRay](https://rubygems.org/gems/coderay)
has a simpler interface. We just pass it through CodeRay between inspecting and printing.

![screenshot](https://cdn-images-1.medium.com/max/600/1*SH_f_Dg9qTCtzNuBcN3mHg.png)


---


Handle EOF
----------

Currently, if we hit the end of the input stream (eg user presses `control-d`),
we explode in `eval`. This is because `input` is `nil`.
Lets stop the loop in this situation.

![screenshot](https://cdn-images-1.medium.com/max/600/1*BuCkA9WP0_gePukpFDM8dA.png)


---


Handle Errors
-------------

It would also be nice to handle errors in the input, so lets rescue and display
them! The `\e[31m` is the [ANSI escape code](https://en.wikipedia.org/wiki/ANSI_escape_code)
to turn the foreground red and the `\e[0m` will turn off the red. Note that,
while common, these codes aren’t portable.

![screenshot](https://cdn-images-1.medium.com/max/600/1*eAJf1FkG56qilcqkuI-40w.png)


---


Where to go from here?
----------------------

So, in 10 lines of code, we’ve constructed a fairly respectable REPL! If you found that fun, try adding some additional functionality:

* Save the previous result in `_` (probably `Binding#local_variable_set`)
* Handle large objects better, eg `{foo: 42, bar: {baz: 1, buz: 2, fuz: 3}, wibble: {magic_word: "sha"+"z"*20+"am"}}}` could get formatted very nicely if, you replace `inspect` with [`pretty_inspect`](http://www.rubydoc.info/stdlib/pp/Kernel#pretty_inspect-instance_method) from `pp.rb`, in the standard library.
* Remember history across invocations (check the [Readline](https://ruby-doc.org/stdlib-2.3.3/libdoc/readline/rdoc/Readline.html) docs)
* Syntax highlight the input (there’s probably a [Readline](https://ruby-doc.org/stdlib-2.3.3/libdoc/readline/rdoc/Readline.html) method to let you swap it out after it’s been entered)
* Add some commands like pry’s `ls` (search around for a list of reflection methods in order to get the information) and show-source (check these humans’ gems: [bannister](https://rubygems.org/profiles/banister), [ConradIrwin](https://rubygems.org/profiles/ConradIrwin), [ryanf](https://rubygems.org/profiles/ryanf), [kyrylo](https://rubygems.org/profiles/kyrylo))
* Separate the REPL’s variables from the user’s. Enter `local_variables`, and you’ll see you’re sharing them with the program. You’ll have to get a binding that doesn’t come from that context. Possibly useful: `TOPLEVEL_BINDING`, `eval` on a string, define a method on the singleton class then remove it, `Kernel#load`, and that JavaScript idiom of defining a lambda you immediately call.
* What would it take to make this testable? You’d probably want to be able to pass it the binding and IO streams. Readline looks plainful, IDK how it’s storing its state, but it’s going to be fragile or broken. You’ll want to segregate it from the rest of your program as much as possible, and if you want 100% coverage, you may need [PTY](http://www.rubydoc.info/stdlib/pty/PTY)s

[JoshCheek]

Oh, I just realized what the issue is. Three dashes in Markdown is a <hr> tag, but that's also what the frontmatter is using as a delimiter. It's probably pulling all the content up to the last --- as frontmatter (if it were a regex, it's the difference between * and *?)

[jessleenyc]

@JoshCheek we made some changes on our end to make sure preview & saved posts are the same. I'm closing this but moving your multiple stylesheet suggestion to our private repo for some internal discussion. Thanks for being awesome and giving feedback, we really appreciate it.