would be nice to have optional automatic line breaks in ticket descriptions and comments

[wfragg@…]

It would be very usefull to have a way to turn automatic newlines during the ticket creation. E.g, some kind of checkbox "Manual line breaks" that automatically. This could be implemented the same way as in one of the proposals in the #1507 - by automatically adding processing instruction at the beginning of the description. Or by appending all newlines with [[BR]].

See #1507 for some additional details.

[Christian Boos]

For tickets, I think we could have a configuration option to simply globally respect newlines, as we already systematically do now for changeset messages. This setting would apply for all ticket descriptions and comments

Could be:

[ticket]
wiki_respect_linebreaks = true

Would default to false.

This could help for the ​PythonTracker …

See also #3307 for the processing instruction suggestion.

[Waldemar Kornewald <wkornewald>]

I think this should not be limited to newlines. Tickets should also ignore wiki words for missing pages. Otherwise many bug reports look very bad because they have backtraces with CamelCaseFunctionNames. Forcing the user to escape something is not a solution because most bug reporters don't want to learn the wiki syntax. They just want to report the bug.

IMHO, this should become the default behavior. Commit logs shouldn't use any wiki syntax, by default, either. This all is unexpected behavior for Trac newbies.

[Raphael Jolivet]

Absolutely.

I came it to open a similar ticket, but I see that some already add the same thoughts ! I think that using Wiki formatting isn't good in a ticket description.

I mean, generally, this is not a good idea to spread one paradigm everywhere : Each concept has its limited target. Wiki is good for … wiki : Don't put it everywhere!

When I create a ticket, I expect that it looks how I wrote it : Wiki formatting shouldn't add more work for the bug reporter. It should be an optionnal facility to enable simple formatting. (like putting pseudo html <b></b> in comments) and the author of the ticket should be able to activate/inhibate the feature (if he wants to paste some complex code and don't want the wiki engine to mess up things)

[Emmanuel Blot]

Replying to Raphael Jolivet :

I mean, generally, this is not a good idea to spread one paradigm everywhere : Each concept has its limited target. Wiki is good for … wiki : Don't put it everywhere!

Well, I think this is one of the major feature of Trac: being able to use Wiki syntax in tickets, in commit log messages, … everywhere ;-)

[Christian Boos]

Ok, fulfilling the original request (respecting line breaks) is a simple enough change and I think it'll make a nice addition for 0.11. Done in r5819.

In future release, we can make configurable which formatter to use for the description and comments. See TracDev/Proposals/WikiParserFormatterSplit#FormatterIssues.

But for now, I don't see a real need to make this feature configurable (as in comment:1), because I've never heard anyone objecting against it.

[Emmanuel Blot]

Replying to cboos:

But for now, I don't see a real need to make this feature configurable (as in comment:1), because I've never heard anyone objecting against it.

Question:
What about existing ticket that contains a

[[br]] \n

sequence (with * spaces between [[br]] and \n): is the Wiki engine able to strip down the combination into a single line break?

[Christian Boos]

Replying to eblot:

Question:
What about existing ticket that contains a [[br]] \n (i.e. at the end of line) … is the Wiki engine able to strip down the combination into a single line break?

No. But if that's not what the user wanted, he'll make the error at most once, hopefully when doing the preview ;-)

The help string could be make that clearer as well, like saying:

Full description (you may use WikiFormatting here; line breaks are preserved):

and

Comment (you may use WikiFormatting here; line breaks are preserved):

[Emmanuel Blot]

Replying to cboos:

No. But if that's not what the user wanted, he'll make the error at most once, hopefully when doing the preview ;-)

So this is an "unacceptable" change that will break all the existing tickets, if my understanding is correct. This new wiki rendering should not be enforced for existing tickets, which means that an option should enable/disable this new behaviour.

Previewing will not help to fix existing DB…

[Christian Boos]

Replying to eblot:

Replying to cboos:

No. But if that's not what the user wanted, he'll make the error at most once, hopefully when doing the preview ;-)

So this is an "unacceptable" change that will break all the existing tickets, if my understanding is correct. This new wiki rendering should not be enforced for existing tickets, which means that an option should enable/disable this new behaviour.

Ok, that's an argument for a configurable behavior… people thinking it's unacceptable to break old tickets can continue like it always was, people willing to get the new behavior can turn it on. It would be nice to have a different default whether it's a new environment or not, but that's not currently possible.

[Christian Boos]

Make the behavior configurable and try to get a sane default. Patch on r5987.

[Christian Boos]

Replying to cboos:

… It would be nice to have a different default whether it's a new environment or not, but that's not currently possible.

The proposed patch makes this possible by storing in the system table the database version at the time of creation, using the initial_database_version key. That way, the code can determine a sane default based on the fact that the environment is a new 0.11 one or an upgraded one.

[Christian Boos]

(ah, that good old default workflow…)

[Christian Boos]

Updated patch for current trunk (r6139)

[Christian Boos]

Updated patch for current trunk (attachment:t2914-preserve_newlines.2.patch​). Feedback appreciated.

(who needs git when it's so easy to manually version patches on a ticket?) :-)

[Christian Boos]

Patch applied in r6170.