On 18 November 2011 08:35, Martin Pool <m...@canonical.com> 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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
