## page was renamed from MoinMoinBugs/FromattingItalicBroken = Description = The wiki parser seems not to be able to use always format italic in a text. I can't reproduce it currently here but it happens on RatingSystemForMoin. Check the last lines there. {{{ Zoran, after seeing some changes in the ratings on my page I'd now like to see on how many votes the rating is based. I'm not really interested in who voted what, but to get a feeling how seriously my opinion differs from the others it would be nice to see how many votes have been collected. -- AnkeHeinrich <> ''You'll need the "who-rated-what-how" at the moment you have devided the others by ABC analysis to more importants and less importants.'' -- ReimarBauer <> }}} ''Reimar, your example above won't reproduce it. It does happen when the closing italic mark is forgotten somewhere LONG before (that spot is not included above), and there is something in between that somehow "radically" changes the output structure (at the moment, I'm not able to express it better), for example a new heading. I fixed that in the text of RatingSystemForMoin, so you cannot reproduce the effect there any more, but I added an example below. -- ZoranIsailovski <>'' == Steps to reproduce == ## Describe the steps needed to reproduce the bug. If we can't reproduce it, we probably can't fix it. 1. do this... == Example == ##Add URL that show the bug, screenshot or test wiki markup that fail... ##URL: ##attachment:screenshot.png ##{{{ ##Example wiki markup that fail ##}}} || Example: Headers in the middle of italic text || ''Some italic text here, bla bla bla... (closing double apostrophes forgotten) === You enter a new heading here === You type and type and everything seem ok (non-italic)... ... until you decide to go italic again for just ''one'' word... ... and continue in normal style... but HEY?!? WHAT'S THIS?!? Do you see it? ... You need to re-close '' the italic mark to cancel the effect. || However, when you indent the text, the effect goes away || ''Some italic text here, bla bla bla... (closing double apostrophes forgotten) === You enter a new heading here === You type and type and everything seem ok (non-italic)... ... until you decide to go italic again for just ''one'' word... ... and continue in normal style... but HEY?!? WHAT'S THIS?!? It DOES NOT HAPPEN NOW?!? ... but then, repeating '' the italic mark does not seem to introduce new italic text, either?!? || The same when you put a table in between: || ''Some italic text here, bla bla bla... (closing double apostrophes forgotten) || Some table here (but NO ITALICS NOW) || You type and type and everything seem ok (non-italic)... ... until you decide to go italic again for just ''one'' word... ... and continue in normal style... but HEY?!? WHAT'S THIS?!? Do you see it? ... You need to re-close '' the italic mark to cancel the effect. || Something similar happens with lists: || ''Some italic text here, bla bla bla... (closing double apostrophes forgotten) * Some list here (still italic) Out of the list again - and all of a sudden: no italics any more... ... until you decide to go italic again for just ''one'' word... ... and continue in normal style... but HEY?!? WHAT'S THIS?!? Do you see it? ... You need to re-close '' the italic mark to cancel the effect. ---- -- ZoranIsailovski <> == Component selection == ## Where you think is this bug happening ? (general, plugin [plugin name], theme [theme name], ... * general == Details == ## If you got a traceback, please save the traceback page as html and attach here: ## attachment:traceback.html ## if the bug is in this wiki, just kill the table and write: This Wiki. ## If a traceback is not available, please fill in the details here: || '''!MoinMoin Version''' || this wiki || || '''OS and Version''' || || || '''Python Version''' || || || '''Server Setup''' || || || '''Server Details''' || || || '''Language you are using the wiki in''' (set in the browser/UserPreferences) || || == Workaround == ## How to deal with the bug until it is fixed = Discussion = In my opinion, you need to exactly define which wiki constructs ''implicitly'' close which other. I have no insight into ''your'' parser (yet), but in a EBNF-driven, top-down recursive descent parser, this would relate to the notions of ''weak symbols'' and ''synchronization symbols''. -- ZoranIsailovski <> After looking closer at the effect, and w/o seeing any code about it yet, I sense a "smell" as if there was some flag in the code that says {{{italic = true/false}}}, and that flag gets out of sync with the actually emitted HTML elements. Because obviously, in the HTML, the {{{}}} is closed before the heading, so your code must be doing some implicit closure on wiki constructs, but forgets to synchronize with other instances - maybe a violation of the [[http://en.wikipedia.org/wiki/DRY_code|DRY principle]]? -- ZoranIsailovski <> = Plan = ## This part is for Moin``Moin developers: * Priority: * Assigned to: * Status: ---- ## If you are a moin core developer, replace the category to Category* in these cases: ## Category MoinMoinNoBug - if this is not a bug. ## Category MoinMoinBugConfirmed - if you can confirm the bug on current code. ## Category MoinMoinBugFixed - after the bug is fixed in current code. CategoryMoinMoinBug