Using ItemGroup, PropertyGroup (etc) suggestions from the extension results in incorrect indentation

[alexrp]

Let's say I have a file like this:

<Project>
</Project>

If I start to type an item group like

<Project>
    <Item
</Project>

and accept the <ItemGroup> suggestion from the extension, I end up with:

<Project>
 <ItemGroup>
   
 </ItemGroup>

This is with indent_size = 2 in .editorconfig. With indent_size = 4, it instead ends up as:

<Project>
   <ItemGroup>
       
   </ItemGroup>

[tintoy]

Hi, sorry for the late reply - I didn't see the notification email for this until this morning :)

Just checking if I understand correctly: are you saying that it appears to be using the indent size specified in settings (in this case, from .editorconfig), rather than the indent level (i.e. column) where you started typing?

[alexrp]

It seems to respect both the current indent level and indent_size from .editorconfig, but it's always off by one space.

[tintoy]

Sorry, I can see that'd be annoying. I'll look into it and let you know what I find 🙂

[RReverser]

This is still an issue. Did you ever get time to investigate it?

[tintoy]

Hi - sorry, I remember investigating, but I can’t remember what I found. I’ll have another look and see if there is anything obvious.

just as a quick check, does this happen when the file’s language is set to MSBuild as well as when it is set to XML?

[RReverser]

I don't think this extension's autocomplete even works when set to XML? At least I only tried with language set to MSBuild.

[tintoy]

Ok, thanks - that helps to cut down on the possibilities :)

[tintoy]

I wonder if this could be related to tintoy/msbuild-project-tools-server#71…

[tintoy]

I’m still looking into this, but no luck so far. I suspect it maybe be related to how we compute the span of text to be replaced by the completion but it’s tricky to test for.

[RReverser]

This kind of off-by-one error almost seems like something is mixing up 1-based column numbers with 0-based ones.

[tintoy]

While it isn’t impossible, everything uses the same data structures to represent LSP line-and-column vs internal line-and-column (and the translations are always done by the same function), it so may not be all that likely (if that was broken it would be broken everywhere). Worth checking though, so I’ll do that, thanks 🙂

https://github.com/tintoy/msbuild-project-tools-server/blob/e942b1a1180cf8e47ff4aa9584d4adc4204d04f9/src/LanguageServer.Common/Position.cs#L296 (etc)

[tintoy]

I think I've figured this out - it seems a while back, the behaviour changed when completion is triggered via trigger characters (in this case, the last character typed is implicitly treated as part of the current selection, if it triggered completion).