Indenter and formatter fails while typing out body of deftype method

[wevre]

I expect the bodies of methods within deftype to be indented by 2 spaces and when I format the entire deftype form, they do indent properly. But while typing, the body is indenting all the way over to the second term.

(deftype MyType [arg1 arg2]
  IMyProto
  (method1 [this] |(print "hello world")))

Typing enter results in

(deftype MyType [arg1 arg2]
  IMyProto
  (method1 [this]
           |(print "hello world")))

It sort of flashes for a moment in the right spot, then scoots over. Hitting tab does not put it in the right spot. But I did find out something interesting while experimenting. If I hit enter and create a blank line

(deftype MyType [arg1 arg2]
  IMyProto
  (method1 [this]
           
           |(print "hello")))

and then hit backspace, it goes to the correct spot.

(deftype MyType [arg1 arg2]
  IMyProto
  (method1 [this]
    |(print "hello")))

Which is great! But if I hit tab again it will go over to the wrong spot. And as state above, if I format the entire deftype form, the bodies are indented correctly.

Originally posted by @wevre in #1956 (comment)

[PEZ]

Copying comment from #1956 as well: The cause here is that Calva only formats the enclosing form, so deftype is never considered. backspace causes the parent form to be formatted, which is why your trick works. Similar if you format the deftype form.

[PEZ]

I think that the tools to solve this involve:

1. The TokenCursor to identify when we're at the top level of a deftype method.
   • We have a function for determining the current defined function. This one can probably used, if we first move up out of the current enclosing form.
2. The function for formatting the current position has a signature accepting extra options, of which one is depth. It defaults to depth 1, formatting only the current form.

So then when we format the current position we could check if we're on the top level of a deftype method and use depth 2 if so.

[SillyCoon]

I'll try to resolve it, thanks @PEZ!

[SillyCoon]

@wevre @PEZ I guess the issue is no longer valid. I've tested it manually and have added a unit test for this case
#2002

[PEZ]

I can still reproduce this here:

https://github.com/BetterThanTomorrow/calva/blob/dev/test-data/indenter-cases.clj#L37

[PEZ]

@SillyCoon, there are two indentation mechanisms in play for this. The one tested in your PR, which we can call the indenter, and also the formatter.

I don't understand why your test does not expose the problem with the indenter, but for the formatter it is clearer, and due to the depth issue I mentioned above.

[SillyCoon]

Ok, got it, let me take a look at formatter

[PEZ]

This issue is fixed. We must have missed to include a closing commit.

[PEZ]

That said, I am experiencing weird indentation issues quite often lately. Which could be regressions from the fixing of this issue. I'll try figure out a repro. It happens to me in my work project and code I can't share as is.

[SillyCoon]

That said, I am experiencing weird indentation issues quite often lately. Which could be regressions from the fixing of this issue. I'll try figure out a repro. It happens to me in my work project and code I can't share as is.

Hi @PEZ! Plz tag me in the new issue when it'll be ready. I will try to fix it.

[PEZ]

That said, I am experiencing weird indentation issues quite often lately. Which could be regressions from the fixing of this issue. I'll try figure out a repro. It happens to me in my work project and code I can't share as is.

Hi @PEZ! Plz tag me in the new issue when it'll be ready. I will try to fix it.

Thanks, @SillyCoon! It's interesting, the repro for at least one of the strange things I've seen is super simple:

• Indenter and formatter not in agreement about some forms #2032