Forced word wrap breaks multiline cursors

[NekoiNemo]

Steps to reproduce

• Type a line that is longer than the tab’s width.
• Type another line below it
• Put cursor at the start of the first line and press keycombo to place another cursor below current

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

For the cursor to appear on the next ==actual== line.

Actual result

Cursor appears on the next fake/virtual/word-wrapped line, in other words ==ON THE ARBITRARY POSITION OF THE SAME REAL LINE==. If the line/paragraph is longer than the user’s screen - it is actually impossible to use the shortcut to place the cursor on the next/previous line.

Environment

SYSTEM INFO:
	Obsidian version: v1.6.7
	Installer version: v1.6.7
	Operating system: #1 SMP PREEMPT_DYNAMIC Mon, 19 Aug 2024 05:13:57 +0000 6.6.47-1-lts
	Login status: not logged in
	Insider build toggle: off
	Live preview: off
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none

---

Additional information

• Making multiline cursors by holding Alt+Shift doesn’t have this issue (but it does occupy the most widely used key combination to change keyboard languages, and can’t be changed in the settings)
• This can be partially solved for short lines with a 4k screen by temporarily opening Obsidian in full screen to get rid of word wrap. But it’s a hacky crutch at best.

This all seem to stem from the same issue of having forced word wrap as the weird, broken and inconsistent Home/End key behavior. For some inexplicable reason, Obsidian treats the fragments of the real line in the document, created from the word wrap, as real lines, and this breaks Home/End keys, multiple cursors, moving cursor around with keyboard, and a lot of other features that i can’t name from the top of my head

Illustration: video

[WhiteNoise]

@NekoiNemo

• Put cursor at the start of the first line and press keycombo to place another cursor below current

Expected result

For the cursor to appear on the next ==actual== line.

Ok, you can open a FR for changing the behavior of the command so that it jumps between actual lines.

@NekoiNemo

This all seem to stem from the same issue of having forced word wrap as the weird, broken and inconsistent Home/End key behavior. For some inexplicable reason, Obsidian treats the fragments of the real line in the document, created from the word wrap, as real lines, and this breaks Home/End keys, multiple cursors, moving cursor around with keyboard, and a lot of other features that i can’t name from the top of my head

This was an intentional design decision from codemirror and we agree with it. You can open a FR for changing it but that’s unlikely to happen! Thanks!

[NekoiNemo]

Hmm, i suppose, i will have to do the feature request then. I guess i could see the reasoning behind forced word wrap, even if i disagree, but the multi-cursor behaviour seems like a bug to me, since there’s no possible benefit in creating a cursor on the next virtual line when that position is ephemeral (as resizing the tab will change it), and the cursor created through the mouse selection does indeed place cursors only on the real lines, like i would expect it to.

Are you sure this isn’t a bug, given that behavior of multi-line cursor is inconsistent between the mouse and keyboard actions?