Make softwrap respect indentation, i.e. wrapped lines inherit indentation

[KronosTheLate]

This issue is essentially the same as this issue for the xed text editor. I do not know if the teams can collaborate.

A picture says more than a thousand words. Current behaviour:

Desired behavior, demonstrated in VSCode:

[jonas-frey]

I would prefer having the soft-wrapped text being indendented further than the current indent level, say by 4 chars or a configurable amount.

[jrc03c]

Same! Also, I'm adding the phrase "hanging indent" because it's relevant and I searched for it in the issues but couldn't find it. :)

[dustdfg]

Same! Also, I'm adding the phrase "hanging indent" because it's relevant and I searched for it in the issues but couldn't find it. :)

I would also add "smart indent" or "smart softwrap" because I searched for it ;)

[dustdfg]

Just copying previous space/tab indentations is a good idea but sometimes I would like more smart soft wrapping. For example in markdown list, I would prefer 1 sub item style

[metastork]

This would be a lovely feature, my eyes are really missing it! I'm personally in the OPs camp regarding preferences :)

Had a quick look in the VSCodium config for how it's handled there, and there the config option is apparently called 'Wrapping Indent'. From defaultSettings.json:

// Controls the indentation of wrapped lines.
// - none: No indentation. Wrapped lines begin at column 1.
// - same: Wrapped lines get the same indentation as the parent.
// - indent: Wrapped lines get +1 indentation toward the parent.
// - deepIndent: Wrapped lines get +2 indentation toward the parent.
"editor.wrappingIndent": "same",

'None' would be the current micro behaviour, 'same' would be OP's @KronosTheLate, while 'indent' and 'deepIndent' would appear to cover part of @jonas-frey's requirement.

To fully cover @jonas-frey's use-case, it might be possible to represent these options more flexibly with a numerical config like wrappingindentspaces: -1 for 'none', 0 for 'same', and 1 or 2 for 'indent' or 'deepIndent' (or any other higher number, as preferred).

@dustdfg: VSCodium uses the 2nd sub-item type - I imagine the first type might actually be more complicated to implement in micro as it's very syntax dependent (i.e., it is probably hard for micro to know that markdown lists start with * or -, without hardcoding specific rules for the markdown syntax?)

[dustdfg]

@dustdfg: VSCodium uses the 2nd sub-item type - I imagine the first type might actually be more complicated to implement in micro as it's very syntax dependent (i.e., it is probably hard for micro to know that markdown lists start with * or -, without hardcoding specific rules for the markdown syntax?)

It was just a description of the perfect situation.

Honestly I have a solution but it is too complicated... We can attach to each file format it is own formatting function (somewhere in lua) that will tell what indentation must be used in which case. It is too complicated, it is more complicated than hardcoding :)

[metastork]

Have hacked together a basic implementation, roughly as described above for personal use with pull request #3107. , It seems to work ok but would appreciate feedback, if it works for you and suggestions for improvements / edits.

[metastork]

Honestly I have a solution but it is too complicated... We can attach to each file format it is own formatting function (somewhere in lua) that will tell what indentation must be used in which case. It is too complicated, it is more complicated than hardcoding :)

Yeah, good point - it might make more sense to define it in a Lua plugin.

Another simpler but slightly cruder alternative could be a config option, where you could define characters to count as 'whitespace' for the purposes of the indents, along the lines of:

"wrapindentchars": "\s\t-*"

By default this could be "\s\t" (space and tab), to maintain backwards compatibility (but is perhaps slight config option overload and duplication / confusing with respect to other whitespace options - not sure whether if there are any project preferences regarding adding new options vs plugins etc).

[dustdfg]

By default this could be "\s\t" (space and tab), to maintain backwards compatibility (but is perhaps slight config option overload and duplication / confusing with respect to other whitespace options - not sure whether if there are any project preferences regarding adding new options vs plugins etc).

I am not sure that I understood how it will help. I mean how it will help to distinguish subitem1 and subitem2 styles?

[metastork]

I am not sure that I understood how it will help. I mean how it will help to distinguish subitem1 and subitem2 styles?

Haven't looked into it in detail, but I was speculating that you could tell the editor to effectively treat a leading '-' or '*' other configurable characters as equivalent to leading spaces, just like a normal space or tab, for the purposes of counting leading whitespace. So micro would just think that a line starting with 'tab*space' or 'tab-space' is a tab plus two space, and automatically indent the next wrapped indent line by tab + 2 spaces.

But it's just theoretical, not sure if it would work well or is a good idea like that.