Ability to limit the "skipping closing pair"?

[alexherbo2]

Ability to limit the "skipping closing pair"?

[maximbaz]

Could you give some more specific examples where auto-pairs behaves sub-optimally? It's a bit difficult to evaluate your suggested rules without knowing what you are trying to solve.

We could even turn your examples in unit tests 😉

[dpc]

Example:

I want to fix this (missing }):

hook global ModeChange insert:normal %{
    evaluate-commands -no-hooks %{ try %{ write  } 
    }
}

I go the end of the line, I press } and now I jump to the following line instead. I can press } again, but that break formatting etc., so is more work than help.

[dpc]

Or I'm trying to edit code and instead of a have foo(a):

fn main() {
   call_function(a);
}

I start inserting after ( and before a, I type foo( and I get call_function(foo()a);. Again, I have to delete additional stuff, and when I press ) I get into another problems.

I don't know ... maybe it is just not for me. I like this extension when I'm typing-in new code like a prose, but 90% of the time I am actually editing or extending existing code, and not writing new files from top to bottom...

[maximbaz]

With the first example I agree 100%, in general I would even say that autopairs should limit itself to the current line and not attempt to close bracket by jumping to the next line. @alexherbo2 what would you say?

For the second example I'm less convinced, by the way you should try surround feature 😉 select inside brackets, go to surround mode and type foo(, this should achieve foo(a) for you.

[maximbaz]

@dpc make sure to try out 3b922ad

[alexherbo2]

Ping @dpc

[daboross]

@alexherbo2 I'm not the OP, but I think this is definitely still an issue. With today's auto-pairs.kak, I still get the issue described in #23 (comment), with a slight difference.

If I type foo(, the code does correctly become call_function(foo(a);. But when I try to type the final ), it still just "overwrites" the existing ), rather than adding a new one, and I have to type two )) to fix it. I guess part of me expects it to know that there's an unmatched brace there?

But that isn't that high-impact. It's worse when working with code covering multiple lines. For instance, this is a piece of code from a codebase I'm working on:

                                    RunSuccess::Return(return_instance) => {
                                        ErasedRunResult::Return(
                                            MassProcessReturn::$name(return_instance)
                                        )
                                    }

Say I'm replacing $name(return_instance) with $name(Box::new(return_instance)). First, I type Box::new(, and that works great. I get:

                                    RunSuccess::Return(return_instance) => {
                                        ErasedRunResult::Return(
                                            MassProcessReturn::$name(Box::new(return_instance)
                                        )
                                    }

Next I use ww so my cursor directly after instance. I know I need to do )) to actually insert a new brace, so I do that.

But rather than creating a new brace, I end up with:

                                    RunSuccess::Return(return_instance) => {
                                        ErasedRunResult::Return(
                                            MassProcessReturn::$name(Box::new(return_instance)
                                            )
                                    }

with my cursor on the brace on the following line. I need to type ) again to insert a new brace, and now the formatting is all messed up.

                                    RunSuccess::Return(return_instance) => {
                                        ErasedRunResult::Return(
                                            MassProcessReturn::$name(Box::new(return_instance)
                                            ))
                                    }

If I want to fix this, I need to manually delete the newline and whitespace before the second ) and reinsert it before the final ), because there's no way deleting that ) and typing it again above will fix anything. If I had multiple levels of closing braces on different indentations, it'd be even worse, since I'd have to go to the end of the last one.

Sorry if this feels like a bit of a rant? I like the project, and am using it despite this issue. Just want to see if I can illustrate the extent of the problem this can be.

I'd help out if I had a better understanding of kakoune scripts, but at the moment working on them is a bit daunting. If there's a good way to detect unmatched braces, maybe the jump-to-closing-pair could be disabled when the closest opening bracket or brace is unmatched?

Maybe I should just learn to select the word I want to surround with braces before inserting the opening brace...

[alexherbo2]

@daboross Sorry for the late answer. I stopped working on plugins since a while. Please see #26 for updates.