feat: Improve checklist paste behavior with smart content handling

[Moyf]

PR 描述

🎯 What Changed

Enhanced the prevent-double-checklist-indicator-on-paste rule to provide smarter checklist pasting behavior:

• Empty checklist lines: Paste content directly (removes checkbox from pasted content, just like before)
• Non-empty checklist lines: Create new line with fresh checkbox - [ ]
• Consistent behavior: All new checklist items use unchecked state - [ ] regardless of source checkbox state

Copy this:
- [ ] A task
- [ ] another task

- [ ] Paste to here: |

Old:
- [ ] If there are multiple lines, then create to new line: |A task
- [ ] another task

New:
- [ ] If there are multiple lines, then create to new line: |
- [ ] A task
- [ ] another task

🚀 Why This Improvement Matters

Before: Confusing paste behavior that could create malformed results like - [ ] BCD[ ]A

After: Intuitive, context-aware pasting that matches user expectations:

# Scenario 1: Pasting into empty checklist
Current: "- [ ] "
Paste: "- [x] Buy groceries" 
Result: "- [ ] Buy groceries"  ✅ Clean replacement

# Scenario 2: Pasting into non-empty checklist  
Current: "- [ ] Existing task"
Paste: "- [x] New task"
Result: "- [ ] Existing task\n- [ ] New task"  ✅ New line added

See this video:

bandicam.2025-09-02.13-00-30-205.mp4

---

Summary: This change transforms checklist pasting from a potentially confusing experience into an intuitive, predictable workflow that adapts based on the context of where you're pasting.

---

BTW, I changed the Chineses of "Checklist" from "清单" to "任务列表", because in Obsidian's official localization, it uses "任务列表":

[pjkaufman]

@Moyf , thanks for taking the time to create this PR. Sorry about the delay in responding.

I think it could be a good addition to the Linter. However, there is one change I would say would need to happen. One of the changes listed is that Consistent behavior: All new checklist items use unchecked state - [ ] regardless of source checkbox state. This should be an option that is off by default for the rule that is getting updated instead of it being the default behavior since that is a breaking change and I know there are use cases to copy existing data to a new file and retain the original check list indicators. But I could also be forgetting the conditions for the triggering of this rule. But that is my initial feedback.

Feel free to explain why it would make sense to change that behavior to be the default and why it would not affect copying from one file to another or copying a set of checklists to an existing checklist where you want to retain the original state of the checkbox.

[pjkaufman]

Another scenario that comes to mind is trying to replace the content of an existing checklist item, but pasting in a checklist already. Does that still work or does the new line logic for the pasted content onto a new line instead of on the line you were pasting to?

[Moyf]

@Moyf , thanks for taking the time to create this PR. Sorry about the delay in responding.

I think it could be a good addition to the Linter. However, there is one change I would say would need to happen. One of the changes listed is that Consistent behavior: All new checklist items use unchecked state - [ ] regardless of source checkbox state. This should be an option that is off by default for the rule that is getting updated instead of it being the default behavior since that is a breaking change and I know there are use cases to copy existing data to a new file and retain the original check list indicators. But I could also be forgetting the conditions for the triggering of this rule. But that is my initial feedback.

Feel free to explain why it would make sense to change that behavior to be the default and why it would not affect copying from one file to another or copying a set of checklists to an existing checklist where you want to retain the original state of the checkbox.

Hi, thank you so much for your patient feedback!

The original intention of this PR was to avoid the situation where, when intending to paste a set of tasks into an existing task list, the first item would (unintentionally) merge with the existing item.

Forcing the source state to be changed to an unchecked state is indeed an issue. I usually perform this operation on empty task states and overlooked this scenario. This is a very important improvement point. I will work on enhancing it later—making it preserve the original state (if one exists).

So, the revised expectation might be:

When pasting into an empty item:

Copy:
- [!] something

To:
- [ ] ⬅️

Result:
- [ ] something
<!-- combined -->

Then it will be pasted as an unchecked state—this aligns with the intuition of "pasting into an empty task list," in my opinion.

When pasting into a task list that already has content—which was the initial problem I wanted to solve—it would be:

Copy:
- [!] something

To:
- [ ] already got text⬅️

Result:
- [ ] already got text
- [!] something
<!-- keep the status -->

What do you think about this improvement, is it a reasonable and user-expected behavior?

(By the way, this only involves the "first line." If the copied content contains multiple task items, they will remain unchanged.)

[Moyf]

Another scenario that comes to mind is trying to replace the content of an existing checklist item, but pasting in a checklist already. Does that still work or does the new line logic for the pasted content onto a new line instead of on the line you were pasting to?

It depends on whether you copy the full line of text (including - [ ]) or only the body content.

The current behavior is—when you copy a full line:

• If only the body of the target task list is selected: pasting it into a new line leaves an empty item (maybe it would be better to delete it?).
• If the full target list (including - [ ]) is selected: it replaces the content entirely.

If only the body is selected—since it is not considered "pasting a task item," there is no special handling:

---

By the way, do you think that after we finalize the solution, we should also provide similar features for the native "list" in addition to the "checklist"?

[pjkaufman]

Hey, so I think some of what you are thinking makes sense to me, but some of it I would leave up to the user.

For example, the scenario you mentioned

When pasting into an empty item:

Copy:
- [!] something

To:
- [ ] ⬅️

Result:
- [ ] something
<!-- combined -->

Then it will be pasted as an unchecked state—this aligns with the intuition of "pasting into an empty task list," in my opinion.

I would make this a user setting where the default is whatever currently happens. But then the user can decide to set the logic to work the other way. For example I think there are a couple of options that could work here:

• Retain the checkbox status of the pasted value
• Retain the checkbox status of the current checkbox line
• Retain the current checkbox status when both checkbox statuses are set but otherwise use the pasted value
• Always make checkbox status empty

Hopefully that gives an idea of what I am thinking for how the rule would allow the user to specify what way the past behavior would work for that first line with the overlap.

As for the second scenario:

When pasting into a task list that already has content—which was the initial problem I wanted to solve—it would be:

Copy:
- [!] something

To:
- [ ] already got text⬅️

Result:
- [ ] already got text
- [!] something
<!-- keep the status -->

I believe that this would be fine as a change since it is pasting into a checkbox that already has a value.

[pjkaufman]

For the current behavior with this addition you mentioned that

• If only the body of the target task list is selected: pasting it into a new line leaves an empty item (maybe it would be better to delete it?).

It really should not try to add a newline to the content if the entire body of the checklist is selected as a part of the paste. That would prevent the need to delete the line content.

As for the comment about doing this for the list logic as well:

By the way, do you think that after we finalize the solution, we should also provide similar features for the native "list" in addition to the "checklist"?

I believe that it is possible to also do this for lists as well so long as we come to a good solution for making the paste behavior more intuitive/better for users.

[Moyf]

I would make this a user setting where the default is whatever currently happens. But then the user can decide to set the logic to work the other way. For example I think there are a couple of options that could work here:

• Retain the checkbox status of the pasted value
• Retain the checkbox status of the current checkbox line
• Retain the current checkbox status when both checkbox statuses are set but otherwise use the pasted value
• Always make checkbox status empty

Hopefully that gives an idea of what I am thinking for how the rule would allow the user to specify what way the past behavior would work for that first line with the overlap.

So, what about adding an option that only appears when the "Removes starting checklist..." option is enabled?
Like this:

As for lists, since they don't have a "status", things will be easier and there's no need to add this extra option.

[pjkaufman]

I would be fine with a dropdown that only shows up when the rule is enabled (though this is the default behavior for settings). I could also see just a boolean working as well for saying always use file's checklist value instead of pasted value.