[Comments] Automatically apply conversion when switching styles? Topic is solved

[fjeronimo]

Hi Dan,

At present, ToDoList removes all formatting when you switch between comment styles in the editor.

SwitchingCommentStyles.png (14.21 KiB) Viewed 1211 times

I was wondering if it would be possible instead to automatically apply conversion (even if this is a preference option turned off by default) when doing so. On a personal level, this can be handy during migration from RTF-->HTML when I want to see how individual tasks look instead of tackling everything in bulk.

Given your comments on how comment plugins fit in ToDoList's overall architecture, this might be one of those suggestions that is impossible to implement from within the tool itself.

Even if it were feasible, it also raises the question on how to deal if you switch from a formatting-friendly style (e.g. RTF) to Simple Text (where no formatting exists) and then back to another formatting-friendly style (e.g. HTML) -- perhaps the Undo/Redo stacks could prove useful if that information is not cached elsewhere?

Thanks,

Frederico

[abstr]

Hi Frederico

>> this might be one of those suggestions that is impossible to implement from within the tool itself.

Short answer: Correct
Long answer: There is nothing that actually prevents me doing this except the knowledge of where that particular journey always ends.

Here's a way to think about it:

Imagine a piece of software with 4 modules, each of which has 3 components.

Now imagine that each of the 3 components connects to all the others within its module: that's 3 connections per module = 12 connections.
Now imagine that each of the 4 modules connects to all the other modules by a single pathway: that's 6 more connections = 18 connections in total.

Now, instead of that, imagine that each component is allowed to connect to any other component in any of the modules: that's ((12 * 11) / 2) possible connections = 66 connections (excluding the 6 module-to-module connections).

And that what happens to software where no boundaries either exist or are enforced - the internal complexity rages out of control ultimately dooming the project.

But of course there is also a price to pay for enforcing the boundaries - some features are not possible or profoundly difficult. Hence the converter having to exist wholly outside the software itself so as not to pollute the application code.