1106: Markup for text fields

nikolai.pr**********@gmai***** (Google Code) (Is this you? Claim this profile.)
Dec. 9, 2013 
What version are you running?
1.0rc1

What steps will reproduce the problem?
1. Take a comment field
2. Enter some marked up text ('This is a *strong* _italic_ text')
3. Click OK

What is the expected output? What do you see instead?

The word "strong" should have been in bold, "italic" in italics. Instead,
markup is shown as is.

Please provide any additional information below.
Should be easy to implement, for example with the MarkdownTextField from
djangosnippets. But any markup language will do.
david
#1 david
  • -Type-Defect
    -Priority-Medium
    +Type-Enhancement
    +Priority-Low
#2 eduardo********@gmai***** (Google Code) (Is this you? Claim this profile.) 
This is a feature request, not a defect. But I can see Markdown being used in big fields 
and comments. It would be useful. But no HTML markup.
chipx86
#3 chipx86 
It definitely could, though we need to be careful not to break out existing text
linkification code, and render proposed code incorrectly.

Also, this must work in JavaScript, so using MarkdownTextField won't work for us.

This is going to be a lot harder than it sounds.
#4 eduardo********@gmai***** (Google Code) (Is this you? Claim this profile.) 
Why this must work in Javascript? You mean that the conversion should be done client-
side?
Several webapps use this pretty well. We could at least provide a small subset of 
Markdown, the same that www.stackoverflow.com provides, for instance. That site is 
also code oriented, and has a nice set of features.
chipx86
#5 chipx86 
When the user modifies a field client-side, we post to the server and then save the
field and do any necessary post-processing. Right now that includes linkifying
certain text, handling comma-separated fields in some fields, etc.

We probably could have the server do this down the road, though we'll need to update
the current API to *optionally* take a parameter saying what format we'd like the
data returned in (so that we don't force clients to parse HTML if they don't want to,
say for console apps).
  • +Confirmed
  • +Component-Reviews
#6 nikolai.pr**********@gmai***** (Google Code) (Is this you? Claim this profile.) 
I've tried implementing this using markup filter in the templates and failed, since
RB lets the user edit text blobs directly, i.e. innerHTML is sanitized and put into a
text field. This will have to change to implement this, i.e. submit text field
contents to server on each save and retrieve i from server on each edit. Otherwise
using filters in templates worked.
david
#7 david 
The more I think about this, the more it seems like it's way too much complexity. SCMs generally don't let you use markups in change descriptions and I don't think we should either.
  • -Confirmed
    +WontFix
chipx86
#8 chipx86 
So it was pointed out to me that we have this bug, which I forgot all about, but good news! This feature is being developed and is coming along nicely.
  • -WontFix
    +Started
  • -Priority-Low
    +Priority-Medium
    +Milestone-Release1.8
chipx86
#9 chipx86 
See http://reviews.reviewboard.org/r/3892/
david
#10 david
  • -Started
    +Fixed