Option to Move Openinig Brace to the Next Line in "Insert new indented line after Return"

[Balrrach]

As stated in the feature pressing <CR> inside brackets places the second brace and the cursor conveniently:

input:
function{|} (press <CR> at |)
output:
function{
    |
}

Some of us prefer the first brace to be separated from the function/function paramerters. Would it be possible to add a feature so that there is an option to obtain such behabiour:

input:
function{|} (press <CR> at |)
output:
function
{
    |
}

[LunarWatcher]

I have mixed feelings about this.

Implementing only that is trivial, but unless you want to end up with

function
(
    ...
)
{
    ...
}

there's going to be some awkward config. I can set it up, I just don't really see the advantage. Would complicate pair initialization, or cause weird artifacts like the example above otherwise. Doesn't particularly help that context and personal preferences play in a lot more. Also seems like a thing a proper formatter should handle, in my opinion, but that depends on languages, other plugins, and other Fun Stuff:tm:.

But applying formatters on a bigger range does have its cons. Off the top of my head, with C++ and clang-format, it's possible to configure it to have empty or short functions collapse. Formatting on the example you gave with that setting enabled would cancel out the <CR>. Formatters are fun, eh?

4.0.0 has been fairly stale so far (largely because it's hard to rework all the code), but this feels like a good candidate for that. Configuration is the main issue, and I do plan to rework parts of the config system for pairs. The original configuration system leaves a lot to be desired, and while 3.0.0 does work on the "backend" for that, it still lacks a sane, user-facing API with easy operations.

Gonna chalk this down to 4.0.0 for now, and further investigation when I actually start making actual progress on 4.0.0. Still got mixed feelings about it, but I'm not sure how much of that comes from the awkward config system inherited from jiangmiao and my brain more or less noping at the thought of setting it up, so not gonna shoot it down for now.

[Balrrach]

If it's a design issue that's making things complicated I can only say from experience that, the sooner one tackles it, the better. Anyway, I understand your points and thank you for the fast answer.

[LunarWatcher]

I know, which is why I've scheduled a rewrite for 4.0.0. v3 ended up being features, and along with initial design issues inherited from jiangmiao, the configuration is periodically awkward. It's a lot better than it used to be at least. The main obstacle at this point is time (occupied with a lot of other stuff), and not really being sure how else to design it. Seems I forgot to say this explicitly, but this issue did bring up a few ideas for how I can go about that.

4.0.0 is, in either case, a while away. There's a lot of technical debt to sort out, and taking care of it isn't gonna be fun :')

[LunarWatcher]

This has now been implemented on the 4.0.0 branch. Turned out to be deceptively easy to do.

Both the options for expansions are admittedly very aggressive, and expand independently of context. There is an option for disabling expansion in strings, and I plan to expand it to comments, and possibly arbitrary syntax groups for flexibility. Aside that, ignoring insertions is also an option, and so is temporarily toggling auto-pairs.

If you've already defined g:AutoPairsAutoLineBreak and want to use that same list for automatically inserting enter before the open character, you can add let g:AutoPairsSyncAutoBreakOptions = 1. When you then switch to the 4.0.0 branch, if you haven't already, it should expand the way you want