Ability to specify to_s format? Or, keep original field order?

[lorenrogers]

One thing that I noticed is that if you have a task like this:

(A) @work +projectname Important task due:2017-01-01 +extra +tags

Once you open it as a Task, the original field ordering gets wiped out in #to_s:

"#{done_string}#{priority_string}#{created_on_string}#{text}#{contexts_string}#{projects_string}#{due_on_string}"

Resulting in:

(A) Important task @work +projectname +extra +tags due:2017-01-01

Although this generally seems like a benefit, (cleaning things up into a standard format,) I could see situations where this would be annoying. For example, I may purposefully want to put the @context first, so that I can easily scan the list. (I do this myself, and noticed this issue because it wiped out the formatting I put in. I put the @context first.)

And, other applications may handle the ordering differently. So, if I open the file with something like todotxt.net, then use this Gem, all the formatting would be changed each time. Though not terrible, it does make tracking in Git a little awkward.

Would it make sense to have an option to have the Task object remember the field order in #initialize? Perhaps a default argument like maintain_field_order=false? When this is set to true, it could extract the order of the components and reproduce it in #to_s. This would definitely be a good amount of effort for a small feature, but I figure I would mention it in case there's shared interest.

[lorenrogers]

Actually, thinking about this a bit more, how would the current behavior handle something like:

Explain +CI to +Mom

Wouldn't you end up with something like this?

Explain to +CI +Mom

Seems like it would make more sense to keep the ordering as-is in the original string. If Task is a simple container for line items, it probably shouldn't do any manipulations unless explicitly told to. (Via something like #clean_formatting!.)

[maetl]

I definitely see the point. Not something I’ve run into in practice, as I tend to use projects and contexts explicitly as tags.

One of the reasons why this library has been able to avoid these kinds of issues up to this point is because it hasn’t actually needed to deal with round-tripping, where the way stuff is written out to a file becomes more of an issue.

This would definitely be a good amount of effort for a small feature

We could consider introducing an optional Todo::Options settings list, in order to document behaviour like this. I suspect the kinds of people who are interested in using tools like this are also the kinds of people who are very very specific about their expectations how the formatting rules should work.

[lorenrogers]

I've actually run into this in other apps as well, and it's pretty annoying personally. I spend all this time getting my tags into a format I like, and the editor wipes them out!

Not to mention things like line-break handling. (Windows vs Unix.) When I go back and forth between my work machine (Windows) and Linux, the line endings change on everything. There's no way to figure out in Git where the real content changes are, since every line changed.

Anyway, I totally agree that an Options class makes sense. I noted this in a couple of the other issues too, where individual app configurations would want to handle things differently.

However, for this particular issue, I think that keeping the given order would be a good default, and that string reformatting should be done explicitly with a mutation method. If we have an Options class, we could allow the ability to have things be sorted automatically during #initialize, which would probably just call whatever the mutation method is.