launchpad-dev team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 18 November 2011 08:35, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> It would be nice if user text within Launchpad could be more than just
> plain monospace. <https://bugs.launchpad.net/launchpad/+bug/391780>

+1

(How many times has each of us said this? We've got to do this for the
sanity of the team if nothing else.)

[...]
> http://github.github.com/github-flavored-markdown/ shows how github do
> it and I think many of their tweaks make a lot of sense for comments
> about code or coming in through web forms.  Some of these at least are
> already in python-markdown.

GFM seems cool, with one exception: their handling of newlines is
bonkers, though I can see the rationale, and would not work well for
most emailed-in content.

> Proposal:
>
>  * Add python-markdown as an egg
>  * Hook it up as a TAL renderer
>  * At first do this only for, say, project descriptions, and only
> behind a feature flag.
>  * If that works, roll it out over larger scopes.

Sounds good.

> Some issues:
>
>  * People are going to tend to make mistakes typing markup, especially
> when they are new to it.  So it is problematic to put it into any of
> the several text things in Launchpad that are immutable once created,
> like bug comments.  I propose to handle this by using it at first only
> for editable text, and then to make all text be editable, at least for
> a few minutes (which is a popular bug in its own right,
> http://pad.lv/80895.)

In a previous life I solved this by having a automatically updated
preview pane next to the text area. If the user stopped typing for a
certain amount of time the content was sent to the server for
rendering and put into the preview pane.

Alternatively we could do this with a preview overlay triggered by a
button next to all relevant text areas.

>  * There's a lot of existing text in Launchpad that was entered with
> no concept of it being rendered as markup, which may look weird if we
> change it that way.  I propose to handle it by, in the first instance,
> seeing how much of it does actually look bad.  If it's a serious
> problem, then we can update the database to put everything affected in
> to a literal block.  Or, we can perhaps do some schema change to say
> "this text is pre-markup" but that seems like it's going to need lots
> of one-off changes.

We may find that LFM (Launchpad Flavoured Markdown) is not quite what
is needed, and so need to iterate to LFMv2 or to something else
entirely, or simply give users the choice of plain text, LFM or even
reST. Storing a content type along with the content might be a way of
solving these problems.

Gavin.