The try block is necessary to move the cursor onto the next line. If, when inserting characters past the autowrap limit, we only ran the format command then the cursor would remain on the first line when the text you just inserted moves to the next line.

We might be able to simplify the logic a bit with something like: 1. record the column number you are on (call this n) 2. run the formatting command. 3. move n characters into the block of text you just ran the format command on. This way the cursor would (hopefully) be in the right place even when going onto a newline. I'll have a play with this idea and see if I can make it work nicely.

The fundamental problem with using autoformat commands such as fold and par is that they do not know about kakoune selections. If the text under a selection moves to a newline then fold cant tell kak 'please move the selection over here to the newline'.

I've been trying out the following. When the user inserts a character we 1. replace it with a rare unicode symbol (∅ in this case) 2. run par on the paragraph 3. move the cursor back over ∅ 4. replace ∅ with the originally inserted character. This way we are seeking the kakoune cursor positions through the auto formatting command by using ∅ to represent the cursor position. By doing this we can start using more complex formatting commands such as those which know how to handle comments at the start of lines.

define-command -hidden autowrap-cursor %{
    execute-keys -draft "hr∅"
    # we would probably want to replace `par -w80` with %opt{autowrap_fmtcmd}
    execute-keys "<a-;><a-i>p<a-;>|par -w80<ret><a-;>s∅<ret><a-;>l"
    execute-keys -draft "hr%val{hook_param}"
}

The obvious downside of this is that it will break if you actually want to use this unicode character in your paragraph. Also it means when autowrap is enabled your selection will be reduced to a single character wide when you insert text. But apart from that I have found it to be quite robust.

Any thoughts on this idea? I will try using this for a while and see how it goes.

The try block is necessary to move the cursor onto the next line. If, when inserting characters past the autowrap limit, we only ran the format command then the cursor would remain on the first line when the text you just inserted moves to the next line.

Hum, but that try block just contains an execute-keys -draft ... which would not actually impact the catch block as it ran in a draft context and hence did not touch the selections the catch block will work with.

The fundamental problem with using autoformat commands such as fold and par is that they do not know about kakoune selections. If the text under a selection moves to a newline then fold cant tell kak 'please move the selection over here to the newline'.

We could work-around this by extending the current piping diff logic to work on characters instead of lines which should detect that we inserted newlines and correctly preserve selections. This might however prove quite expensive, but may be something to explore.

Thats a great idea, I think extending the piping diff logic is the way to go if turns out to be fast enough.
For my future reference: relevant call subgraph is pipe->apply_diff in src/normal.cc.