Make separator between dataview components configurable

[jonas-schulze]

⚠️ Please check that this feature request hasn't been suggested before.

• I searched previous Ideas in Discussions didn't find any similar feature requests.
• I searched previous Issues didn't find any similar feature requests.
• I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

You should add a configuration option to automatically add , instead of in front of dataview components.

✔️ Solution

The added configuration option should affect the following part of the code.

obsidian-tasks/src/TaskSerializer/DataviewTaskSerializer.ts

Lines 129 to 134 in 48e8250

	return shouldMakeInlineField
	? // Having 2 (TWO) leading spaces avoids a rendering issues that makes every other
	// square-bracketed inline-field invisible.
	// See https://github.com/obsidian-tasks-group/obsidian-tasks/issues/1913
	` [${stringComponent.trim()}]`
	: stringComponent;

The default/current behavior could, e.g., be named "Separate by two spaces".
If set to "Separate by comma", above lines should behave like:

return shouldMakeInlineField
    ? `, [${stringComponent.trim()}]`
    : stringComponent;

❓ Alternatives

You could separate by , regardless. Though, I did not consider all the situations where adding a leading comma may be undesirable. Given that #1505 is still open (as of 2024-04-26), I suppose that all dataview fields are at the end of a line. If that is the case, I personally would not mind the initial comma.

📝 Additional Context

Such a configuration option would allow the tasks plugin to play more nicely with the "Remove multiple spaces" option of the linter. In particular, when marking a task done from within a tasks view, the linter is not run over that file to remove the leading spaces of the added [completion:: today]. When the user is later editing that file directly, the linter is removing the duplicate space. This introduces unnecessary changes when synchronizing the vault using Git.

Furthermore, suppose a user manually added , in between two dataview components. After editing that task using the "Tasks: Create or edit task" command/GUI, all the , will be replaced by . For example,

- [ ] foo, [priority:: high], [due:: 2024-04-26]

becomes

- [ ] foo,  [priority:: high]  [due:: 2024-04-26]

when immediately confirming the GUI dialog. Note the two spaces after the comma. Upon saving, the linter replaces the task by

- [ ] foo, [priority:: high] [due:: 2024-04-26]

[claremacrae]

Thanks for the suggestion.

I am concerned about the complications that this would introduce for users who already have space-separated dataview fields in their tasks, and then change the setting.

Please have a read of What do I need to know about the order of items in a task?. A comma between fields would break parsing, currently, as it is not a space.

I can't see a clean (maintainable) way of implementing this suggestion in the current code.

Once #1505 is implemented, this request would be easier to implement.

But I do feel that the right solution is for somebody to take the time to report the underlying Issue on the Obsidian Forum - that Obsidian displays reference-style links incorrectly in Live Preview mode.

[claremacrae]

But I do feel that the right solution is for somebody to take the time to report the underlying Issue on the Obsidian Forum - that Obsidian displays reference-style links incorrectly in Live Preview mode.

I've reflected on this, since writing the above. I am sure that it is the correct solution to the problem. @jonas-schulze, if you want to pair together to work on a Forum bug report, please email me at the address in my GitHub profile.

In view of this size of the backlog for this project, and the demotivating effect of a very long backlog on volunteer energy levels, I'm going through a continual process of reviewing tasks for things that are one or more of the following:

• unlikely to be realistically achievable, from the design of the current code, and the planned future refactorings
• not sufficiently high priority to a broad community of users, based on the feedback I receive from a variety of sources
• do not fit the core purpose of the Tasks plugin
• are better covered by a different plugin - to share the development and maintenance effort

So I'm marking this one as 'not planned'. This doesn't mean 'won't fix' - it means not likely to be done in the foreseeable future.