Last modified: 2008-04-06 17:59:44 UTC
I often mistakenly use the heading markers when filling in the headline in a 'post a comment' box, which results in the == appearing twice in the code, and therefore on-screen. The software should detect this and remove == if found at both ends of an edit comment.
Created attachment 1169 [details] Patch for EditPage.php in HEAD Patch to trigger edit conflict on 'section=new' when the previous edit's username and comment string match; this should get most dupe posts.
Applied to HEAD.
*** Bug 2360 has been marked as a duplicate of this bug. ***
This patch is fixing a different bug to the one stated, so I'm reopening it. Perhaps it's because my original post is not clear enough. The problem I was referring to is that when I post a new comment (i.e. add a new section) I will often enter "== Title ==" (minus quotes) into the subject/heading box. This results in the following string being entered into the wiki markup (again minus quotes): "== == Title == ==", which then needs to be fixed. The suggestion is for the software to spot this situation and not add the heading tags if they are already at both ends of the subject string.
(In reply to comment #4) > This patch is fixing a different bug to the one stated, so I'm reopening it. > Perhaps it's because my original post is not clear enough. I think your description was descriptive enough, but the summary line seems to have got off the point (I've changed it now).
Unneeded change requested from early days of software, this capability is no longer really needed anymore (and everyone has adapted to the current situation, I can't remember the last time I saw something like this happen...).
Agree this is probably not needed.
To be honest, I make this mistake sometimes. :) Reopening.
Created attachment 4149 [details] trims whitespace and =s from summary
Created attachment 4150 [details] trims whitespace and =s from summary, anchored Modification to previous patch, so that the regex is anchored to the start/end of the submitted string. Original patch would mangle headings such as "$Foo == $Bar instead of $Foo === $Bar!".
Created attachment 4151 [details] trims whitespace and =s from summary, anchored, stricter A stricter version, with fewer false positives (for example, it won't alter titles with = symbols on just one side, e.g. "=Text"). Also moved trimming out of regex and into separate trim() statements to stop it matching multiple equals signs separated by spaces. I could make this stricter, e.g. it always removes the same number of = from the start and end (e.g. "=== test ==" becomes "= test") and it doesn't modify the special case of a title that is purely made up of = symbols, if requested. Finally, a question - does this display correctly in the summary preview, or is it only applied on save? I haven't been able to test as I don't have HEAD setup on this machine.
(In reply to comment #11) > Finally, a question - does this display correctly in the summary preview, or is > it only applied on save? I haven't been able to test as I don't have HEAD > setup on this machine. It removes =s on preview.
Created attachment 4152 [details] trims whitespace and =s from summary, anchored, stricter Fix typo
Created attachment 4755 [details] Updated patch against current head, same regex/trim() function
Woohoo! :) Applied in r32376
Reverted the white-space-stripping part of this in r32863, as my commit message says: Partial revert of r32376: don't strip whitespace from summaries. If you do, that means that the default "/* Section name */ " summary loses its trailing space if you hit preview before submitting, which is noticeably inconsistent and annoying. Maybe trim it on save, but I don't know if there's any point.
