Before this change, samples in the Rust book looked like this:
fn main() {
println!("hello world!");
}
Afterward, it looks like this, which is correct,
fn main() {
println!("hello world");
}
Basically, when you use parse_line, syntect implicitly inserts the line breaks.
This PR attempts to get a syntect implementation that actually works,
by manipulating the scope stack directly instead of trying to post-process
the HTML.
It takes strings like this:
let _t = "interesting string
\# boring string
";
And produces DOMs that look like this:
<span class="syn-source syn-rust">
<span class="syn-storage syn-type syn-rust">let</span>
_t
<span class="syn-keyword syn-operator syn-assignment syn-rust">=</span>
<span class="syn-string syn-quoted syn-double syn-rust">
<span class="syn-punctuation syn-definition syn-string syn-begin syn-rust">"</span>
interesting string
</span>
</span>
<span class="boring">
<span class="syn-source syn-rust">
<span class="syn-string syn-quoted syn-double syn-rust">boring string</span>
</span>
</span>
<span class="syn-source syn-rust">
<span class="syn-string syn-quoted syn-double syn-rust">
<span class="syn-punctuation syn-definition syn-string syn-end syn-rust">"</span>
</span>
<span class="syn-punctuation syn-terminator syn-rust">;</span>
</span>
In other words, it splits it up the same way a WYSIWYG editor might if you tried to apply a block
style to a deeply-nested selection; it maintains the styles, but always ensures "boring" is top-level.
It doesn't produce optimal HTML, but it should always work.
Before, a code block would always end with a final newline. The
newline was added unconditionally by `hide_lines`.
When the code block is syntax highlighted by highlight.js, this is not
a problem, no empty line is added for a final trailing `\n` character.
However, when the code block is editable and thus handled by the ACE
editor, a trailing newline _is_ significant. I believe this issue is
most closely described by https://github.com/ajaxorg/ace/issues/2083
in the upstream repository.
The effect of the way ACE handles newlines is that a code block like
<pre>
Some code
</pre>
will create an editor with _two_ lines, not just one.
By trimming trailing whitespace, we ensure that we don’t accidentally
create more lines in the ACE editor than necessary.
Surprisingly, this fixes the error filed at #1860!
This seems suspicious, perhaps indicative of a bug in Rust's non-lexical
lifetime handling?
The lifetimes in the `handlebars::Renderable::render` method signature
are quite complicated, and its unclear to me whether or not Rust is
catching some new safety edge-case that wasn't previously handled
correctly...
Possibly related to `drop` order, which I *think* is related to the
order of binding statements?
