Most common silly mistakes

To avoid getting into that particular situation, I like to run formatting (usually by saving) whenever I add nontrivial brackets, so I know that they're correct and correctly indented before further editing; and if they aren't correct, undo and try again more carefully. Not the most theoretically efficient strategy, but robust, and seeing even my in-progress code correctly indented code helps me think about what I'm doing and ensure the parser agrees with my understanding of the syntax I'm writing.

1 Like

I dont like either of those. On most keyboards (Im generalizing here) to type either -> or => I have to look down because -/= are on top of keyboard while > is not. This is unlike parenthesis, square or curly braces which are right next to each other.
Anyways, at this point Im just nitpicking.

Something I like about most editors is that when you open any form of brackets it'll automatically insert the closing bracket after the cursor. So as long as you don't move the cursor while typing all the brackets tend to stay in order.

That said, I've messed up brackets when writing large nested struck literals (e.g. for the expected value in a test) and it's been a massive PITA. You can easily waste 10 minutes counting the when curly/square/round brackets open and close.

Next time that happens, I'd like to see a snippet. The parser does its best to recover from bad nesting, but seeing good examples of problems in the wild can be useful to find new strategies to deal with this.

Same goes to everyone else in the thread, of course :slight_smile:

8 Likes

Yeah, what really kills me isn't writing it the first time, but when I modify an existing deeply nested structure. I'm using VIM plugin in IntelliJ. d% is supposed to ensure I only pull a balanced expression. But during the refactoring, I accidentally do a deletion somewhere that causes things to get unbalanced ...

2 Likes

Each time I remove nested parentheses I got trouble. e.g. I want to replace (b(a)) with (b). I remove the a), ok. Then I remove the ( and VSCodium removes the last ) so there is only (b left. Sometimes it takes time to find where is the missing ).

4 Likes

I just ran into a similar situation, except (b(a)) -> (b), I want to do b(a) -> a.

In particular, I want to do Box::new(LONG_EXPR) -> LONG_EXPR.

I can't put the cursor over ( and hit d% because that deletes LONG_EXPR too. Instead, I delete the Box::new(, so now we are left with LONG_EXPR), except it is not so obivous.

LONG_EXPR ends in )}), and after the LONG_EXPR) , we have some })} so now we are hunting for the right ) in BLAH)})})} [not exact, but gist of it]

4 Likes

I suggest familiarizing yourself with

  1. Registers (:help registers)
  2. Text objects (:help text-objects)

Here's how I would probably do that with the cursor starting inside the LONG_EXPR:

"adi(bbbbd%"aP

I tend to use named registers because I can never remember the rules for the numbered ones. But if you do the delete first you can still save it:

di(bbbbd%"2P     (works if the deleted text is more than one line)
di(bbbb"_d%P     (always works)

Since the p is a replacement, you can even do it in visual mode without explicitly using registers:

di(vbbbbp
1 Like
  1. I appreciate the effort. This is not what I could call 'intuitive' though. :slight_smile:

  2. In lisp, the equivalent work would be (|a b) -> b where the | is the cursor. This would be done in 2 commands with paredit. See: Paredit, a Visual Guide - Calva User Guide

  3. delete-sexp: (|a b) -> (|b); raise-sexp: (|b) -> |b; both steps are intuitive and operate on the 'structure' rather than individual text chars

Maybe BxEx workds better here :slight_smile: Duplicate/triplicate B and E if there are spaces inside LONG_EXPR.

The order of async and move in async move { ... }.

EDIT: It is actually move async...

3 Likes

Call me an amateur, but the match arm and function return values mean different things, right?
I like different symbols with different meanings, otherwise things get confusing and you'll see lots of questions like "why can't I write Result<(), ()> in front of { } on my match arm?"
It's good, when people learn, to be able to look up a symbol and know what it's for, rather than have to read n pages of contextual caveats

I don't know why anyone would write something like this, but having the same symbol for -> and => could be confusing (ambiguous? I don't know):

fn foo() {}

match bar {
	_ => foo as fn() -> ()
}

This reminds me that I always mix up fn and Fn in types/traits, and never know where to use dyn.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.