Edgewall Software
Modify

Opened 15 years ago

Closed 13 years ago

Last modified 2 years ago

#2914 closed enhancement (fixed)

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

Reported by: wfragg@… Owned by: Christian Boos
Priority: normal Milestone: 0.11
Component: ticket system Version: 0.9.4
Severity: normal Keywords: ticket automatic newlines line break
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (2)

t2914-preserve_newlines.patch (6.5 KB ) - added by Christian Boos 13 years ago.
Make the behavior configurable and try to get a sane default. Patch on r5987.
t2914-preserve_newlines.2.patch (5.9 KB ) - added by Christian Boos 13 years ago.
Updated patch for current trunk (r6139)

Download all attachments as: .zip

Change History (15)

comment:1 by Christian Boos, 14 years ago

Milestone: 0.11
Owner: changed from Jonas Borgström to Christian Boos
Priority: lownormal

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.

comment:2 by Waldemar Kornewald <wkornewald>, 13 years ago

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.

comment:3 by Raphael Jolivet , 13 years ago

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)

in reply to:  3 comment:4 by Emmanuel Blot, 13 years ago

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 ;-)

comment:5 by Christian Boos, 13 years ago

Milestone: 0.11.10.11
Resolution: fixed
Status: newclosed

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.

in reply to:  5 ; comment:6 by Emmanuel Blot, 13 years ago

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?

in reply to:  6 ; comment:7 by Christian Boos, 13 years ago

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):

in reply to:  7 ; comment:8 by Emmanuel Blot, 13 years ago

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…

in reply to:  8 ; comment:9 by Christian Boos, 13 years ago

Resolution: fixed
Status: closedreopened

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.

by Christian Boos, 13 years ago

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

in reply to:  9 comment:10 by Christian Boos, 13 years ago

Status: reopenednew

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.

comment:11 by Christian Boos, 13 years ago

Status: newassigned

(ah, that good old default workflow…)

by Christian Boos, 13 years ago

Updated patch for current trunk (r6139)

comment:12 by Christian Boos, 13 years ago

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?) :-)

comment:13 by Christian Boos, 13 years ago

Resolution: fixed
Status: assignedclosed

Patch applied in r6170.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.