[27.0.1] Adaptive formatting fails to use tabs

[jc44]

[Win11 x64 27.0.1 brief] Adaptive formatting seems to have forgotten how to use tabs in C. With a kernel file like the one attached SE happily indents with spaces and it seems to get case indent wrong too despite both being correct in adaptive-stats @ 100%. (Tab indent should also be 8 rather than 4 but thats much harder to guess.)

To reproduce have indent with spaces & indent case from switch set as defaults, load the attached file, go to line132 (should be a case statement) <num+><insert> to copy the line (brief emulation) and it turns up indented too far using spaces rather than tabs.

This isn't new with 27.0.1 it applies to all 27.x, but I've just gone back to working on hard-tab files so its annoyed me enough to winge. (Adaptive formatting seems to be one of the things that rots on regular basis - we've had releases where it is almost perfect then after a while it isn't anymore.)

[jc44]

As is always the way - I've just found that, for reasons unknown, the adaptive formatting affects tabs box had become unchecked so that fixes that problem (sorry to waste your time), the case indented too far on paste thing is still real though.

[Clark]

I couldn't reproduce the case paste problem you are seeing. Please post your user.cfg.xml. Maybe it's caused by a configuration option.

[jc44]

Here you go. I've swapped the default C formatting style since the original report s.t. tabs are set at "1 9" as having a default of "1 5" and document of "1 9" seemed to confuse smart indenting generally, but the simple copy/paste gets case indent wrong persists.

[Clark]

I added a hot fix for this.

[jc44]

Thanks - I assume from the fact you created a hotfix that you could reproduce it

[Clark]

Yes. Adaptive formatting has to be on to get this problem. There’s a very subtle bug in the scanner which leaves SlickEdit in a potentially confused state.