I'm using Maruku (Ruby) to parse some Markdown formatted text. I have a problem when trying to format a block of code like such:
This is a normal line
# pretend this line is empty
printf("First line of code is OK");
printf("Second line of code (or any line thereafter) appears indented by an extra level, which is incorrect!");
So my first line of code (which I've indented in my md file by 4 spaces (or a tab), renders just as I'd expect. However, my second line of code (indented by exactly the same number of spaces) ends up being indented by an extra 4 spaces when the HTML is generated.
The output looks like this:
This is a normal line
<pre><code>printf("First line of code is OK");
printf("Second line of code (or any line thereafter) appears indented by an extra level, which is incorrect!");</code></pre>
I've tested my Markdown input with Gruber's "Dingus", and it renders as I'd expect (that is, both lines of code in a single block, both indented at the same level). But with Maruku, it's bunk.
I've also tried with RDiscount, but I get the same effect. I'm using Maruku because I need definition lists.
How SO formats it:
This is a normal line
printf("First line of code is OK\n");
printf("Second line of code (or any line thereafter) appears indented by an extra level, which is incorrect!");
It turns out this was not a Maruku problem but a HAML problem.
HAML is fussy when it comes to whitespace and preserving it. The solution was needing to use = preserve #my_html_string when rendering it.
For example, given layout.haml:
!!! 5
%html
%body
= yield
and index.haml
%article
= preserve #my_html_fragment_with_pre_and_code
Then it would render correctly for me.
Related
I'm not sure if this is a web2py problem or a general html problem, but when I create a form in web2py that contains an editable string in a textarea, and the string contains an initial newline, like "\nsecond_line", the textarea does not display or save the newline - it is cut out. It works fine if there is a character before the newline: "firstline\nsecond_line" shows as on two lines. It is also only relevant for the first newline. If I have a string like "\n\nthird_line", then the textarea shows a single newline at the start.
This is with the most recent (non beta) version of web2py, on safari 9.1.3 and chrome 56.0.2924.87.
Ah. "By HTML 4.0 appendix B chapter 3.1, “a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception.”"
I work with mercurial, and use long(ish), multi-line commit comments.
Recently, I've put my project on BitBucket.org, and have noticed that when my commit comments are appended to issue pages (see this SO question for information on how/when that happens), the newlines are replaced with spaces, while double-newlines stay double-newlines.
How should I mark single-newlines in commit messages so that BitBucket acknowledges them? I'd like to do this in the least-obtrusive way for when I read the comments normally from the command line.
Break paragraphs (generating <p> tags) with a blank line. Break lines (generating a <br> tag) by ending the first line with two or more spaces, e.g.
Line one␣␣
Line two
Bitbucket formats comments using Markdown, which has this to say about paragraphs and line breaks:
Paragraphs and Line Breaks
A paragraph is simply one or more consecutive lines of text, separated by one or more blank lines. (A blank line is any line that looks like a blank line — a line containing nothing but spaces or tabs is considered blank.) Normal paragraphs should not be indented with spaces or tabs.
The implication of the "one or more consecutive lines of text" rule is that Markdown supports "hard-wrapped" text paragraphs. This differs significantly from most other text-to-HTML formatters (including Movable Type’s "Convert Line Breaks" option) which translate every line break character in a paragraph into a <br /> tag.
When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return.
Yes, this takes a tad more effort to create a <br />, but a simplistic "every line break is a <br />" rule wouldn’t work for Markdown. Markdown’s email-style blockquoting and multi-paragraph list items work best — and look better — when you format them with hard breaks.
I am using Ruby on Rails 3.2.2 and I would like to know how to "output" / "reproduce" "blank lines" (stored in a database column Type TEXT) in a rendered view file. That is, in my database column Type TEXT I have stored the following data (note: blank lines are really the ones present in the data):
Line 1
Line 2
Line 3
Line 4
...
In order to make the outputted text (in front-end content) to "follows" / "reflects" "spaces" (for the above case) accordingly to data stored in the database, for example, I would like to output some HTML code as like the following:
Line 1<br/>
Line 2<br/><br/>
Line 3<br/><br/><br/>
Line 4
...
... or something else that makes that I would like to accomplish.
In other words, I need some formatting of raw database data to be outputted as much as possible like HTML code would be. How it is possible in a correct and not dangerous (for example, there may be problems related to Cross-Site Request Forgery - CSRF) way?
If you don't need any formatting other than your newlines then you could use a <pre>:
<pre><%= your_text %></pre>
The <%= %> will take care of HTML encoding everything and the <pre> will take care of formatting your line breaks.
Question is very simple but I am not found solution yet - probably it is not possible or very hard to find since it is very trivial.
Question is how to avoid adding spaces in formatted HTML after new line - especially in list of values.
First example see example:
1, 2
It produces required HTML like this:
1, 2
Now another example which not works:
1
,
2
It produces invalid HTML like this:
1 , 2 required is 1, 2
How to achieve same result as in first example but using multiline text layout - I know that we could do it in one line but want to do in many lines to simplify program code (not HTML).
It works as defined: in normal content, a newline is equivalent to a space. There is no way to change this principle in HTML. Just divide you content into lines so that the principle works for you, not against you. That is, break a line only at a point where a space is OK.
I have always used Replace(myString, vbCrLf, "<br/>") to show line breaks when outting something to a page from the database (retaining line breaks). I am now using a DetailsView that has a textarea as one of the fields and uses a LinqDataSource as its datasource. I want to allow users to type line breaks in the textarea and display them on a page (replaced with <br/>'s to show breaks in the HTML). Linq seems to be replacing the line breaks with something else that is now causing the Replace statement to not find the breaks, therefor not inserting the html <br/>. When loading the value from the database to a textarea the line breaks are still there though. I have tried replacing the following with <br> but none of it works.
vbCrLf
vbNewLine
Environment.NewLine
...none of those work... what do I need to find/replace with <br> to show breaks?
TextArea uses different newline characters depending on the browser:
Internet Explorer: \r\n
FireFox: \n
It has also been suggested that \r is used in some cases, although, I haven't come across those cases.
Carriage return is encoded as %0D and Line feed as %0A. So if your text is HTML encoded (as it should be), then you need to replace %0D and/or %0A [depending on your environment] with your <br />
Here is a full discussion on the topic http://www.highdots.com/forums/html/standard-newline-character-264611.html.
Look at the string as a byte array, what values are the line breaks? There are only so many options here, 10, 13, both, none?
This works great for me:
string Output = HttpUtility.HtmlEncode(DirtyText); // HTML Encode it first for safety..
return Output.Replace("\n", "<br />"); // Now replace New Lines with HTML BRs
You end up with a safe encoded output, but also nicely formatted line spacing exactly as entered by the user into a standard textarea.