Apache Allura™

Examples of all the block & escaping possibilities, with a markdown syntax and html syntax within each.

indented text [#6822] <b>bold</b>

fenced with tildes [#6822] <b>bold</b>

this is pre [#6822] bold


this is code [#6822] bold


this is

an inline pre [#6822] bold 

this is inline backticks [#6822] <b>bold</b> foo

Seems best to wrap content like: ~~~~\n::text\n$ORIG_CONTENT\n~~~~

Downsides: literal ~~~~ will mess it up. And it's monospaced. And that extra syntax will go into plain-text notifications

If it's a "paste code snippet" button that escapes the block of text, I think that'd work out okay. Better than escaping the whole thing with ~~~~ fences which would show up in a few places (like plain text notifications). And then we can add more buttons to add more formatting help too, besides just code blocks.

Other different types of solutions might be: requiring preview before post, so issues are noticed. Or having a 'view original text' button so viewers can see the original text as it was entered (this would be useful too for other cases of viewing "source markdown").

Originally by: fredt

Follow up from [forge:site-support:#3470] which is a blocker for the project "hsqldb".

It is not just code snippets. Technical exchanges have a high inline code and expression content. For example someone might type: "when x > 2 the color is user-defined" but actually using symbols that get confused with markdown symbols. Users need to enter their posts quickly without having to add markup / markdown code.

It is best to have markdown off / on as a configuration property for the whole forum or for individual posts. The default behavior should be plain text with no markdown. SourceForge can of course enhance the markdown support in the future for whoever wants to use it.

If you look at https://sourceforge.net/projects/hsqldb/forums/forum/73674/topic/8714893 you see a simple example with lots of special symbols. Other examples have a wider variety of special symbols.

Hello Fred, I think you're anticipating that Markdown will interfere much more than it actually does. As you may have noticed from your own inline example of "when x > 2 the color is user-defined", there isn't anything there at all that's being affected by markdown formatting.

Further, from the example you cite, it actually comes out quite nicely with the Markdown (dare I say even better than unformatted?). I've copy/pasted the text from that example, which you'll see below:

Given the following:

CREATE TABLE tab ( name VARCHAR_IGNORECASE(255)) INSERT INTO tab VALUES('fileß.txt') <--- Note the 'ß' ! the query: SELECT * FROM tab WHERE name LIKE '%txt%'

returns an empty result set! I would have expected that 'fileß.txt' is returned. Changing the query to:

SELECT * FROM tab WHERE name LIKE '%tx%' <--- Note the final 't' is missing here

returns 'fileß.txt'!

With name defined as VARCHAR (instead of VARCHAR_IGNORECASE) the first query works as expected.

Is this a bug or some misunderstanding?

(using HSQL 2.3.0)

Of course, we can certainly come up with examples where unintended formatting can occur. In particular, the use of *'s which you noted in [forge:site-support:#3470] would probably be the most common case. But in my experience, the number of incidences of unintended formatting are relatively rare and are IMO worth the trade-off (though, I do appreciate that I encounter different text patterns than you regularly do).

Other more common issues are when folks paste in snippets that start with #'s or >'s, but those should be mitigated by options presented in this ticket.

That said, it would be useful to hear your thoughts on our alternative solutions. Like some of the ones Dave mentions in his last comment.

Originally by: fredt

Thanks Chris, you did not miss the garbled example. Other stuff I cited was just to show there are code snippets, not to show exact garbled examples.

As I work in the database software field, my suggestion to you is to add a field to the database table used for storing the messages with initially two options. One option is "no markup" and the next option is "markdown". In the future you could add other options such as "html", "xml", "bbcode" or whatever formatting that might be used. This field dictates how you treat the text for rendering on the web or emails. With "no markup" there is no treatment of special characters as markdown codes.

• Milestone: forge-backlog --> forge-jan-24

• Milestone: forge-jan-24 --> limbo

Originally by: *anonymous

I'll give you two examples:

At StackOverflow there is some possibility for mixup of code snippets and their markup language. Their live preview helps a lot.

Jira (bug tracker used one several Apache projects) has an automatic translation of (N) or something like than into an emoticon. Very annoying "feature".

Good luck with whatever you decide to do.

An editor like https://github.com/lepture/editor which shows some Markdown style rendering as you are editing (not full WYSIWYG though) could be very helpful. Demo at http://lab.lepture.com/editor/

I like this because it doesn't attempt to do a full WYSIWYG exact render, so we don't have to worry about some of our customizations. Yet it does do enough formatting that people will notice if they unintentionally cause formatting with a _ or a *. And it even helps with the sneaky gotcha of a bullet list without a preceding blank line (it doesn't work, it is rendered as italics)