B2: Adaptive formating and tabs

[jc44]

I have had intermittent issues with SE becoming confused about whether to indent with tabs or space for a few versions now (several versions ago this seemed to work better).  I have C set to indent with tabs (rather than spaces) by default, but most projects I work on indent with spaces and by and large adaptive formatting spots this and I get spaces, but once in a while, for no obvious reason I find myself using tabs, most commonly when syntax expansion has taken place, but not always.  This has happened sufficiently rarely and unrepeatably that I haven't raised the issue before, but now I finally have a consistent case :-)

asm blocks such as:
static inline uint32_t get_cabac_by22_peek_arm(const CABACContext *const c)
{
    uint32_t rv = c->low &~ 1, tmp;
    __asm__ (
        "cmp      %[inv] , #0                    \n\t"
        "it       ne                             \n\t"
        "umullne  %[tmp] , %[rv] , %[inv], %[rv] \n\t"
        :  // Outputs
             [rv]"+r"(rv),
             [tmp]"=r"(tmp)
        :  // Inputs
             [inv]"r"(c->range)
        :  // Clobbers
                "cc"
    );
    return rv << 1;
}

Will get all their code lines indented with tabs despite this not occurring anywhere else in the source file.

Thanks

John Cox

[patrick]

That's a good testcase, I can reproduce it.  Definitely something unexpected going on with adaptive formatting.  We'll take a look at it.

[patrick]

This ends up not being what I expected.

The only reason I'm getting tabs for that file by itself is because the file is small enough that adaptive formatting doesn't get enough samples it trusts to commit to a decision and just uses your formatting defaults.  You can see what settings adaptive formatting has decided/rejected by running the adaptive-format-stats command with the file opened.

If I make the file bigger by copying that function a few times, then adaptive formatting does decide on 'spaces' for indent.  But then it gets the indent amount wrong.  It's actually probably due to the problem coloring of the asm embedded section you mentioned in another post. 

The coloring you see in the asm sections marks that section as an embedded language, with different lexer and rules. Adaptive formatting knows about embedded languages, and will skip them.  But since the range is screwed up on the embedded section, adaptive formatting is taking indent samples from the inside the _asm_ statements, which throws off the indent calculations.

So we need to look into the coloring of the asm statements first, and then see what adaptive formatting does after that's fixed.

[jc44]

Well that explains why the issue reproduces easily here.  Given your explanation the parser should mark only the contents of the quoted asm as embedded, as that is the only part that actually is.  Outside of the quotes is still part of the "C" file (as are probably the quotes themselves).

But just for the record, my experience varies from yours - the snippet I gave you is part of a much larger source file with no tabs anywhere and I still get tabs when I add lines.

[patrick]

Sounds like there's more to it.  It might be interesting to go the full file, run adaptive-format-stats, hit the statistics button, and see how many times it thinks it saw tabs vs. spaces as indents.  With a decent number of indent samples, it would take more than a few (possibly mistaken) tab indents to push it over the edge into tabs, so without seeing the file, I'm wondering what the balance is like.  Or if it only has a small number of samples for the file for some reason.

[jc44]

Can't think of any reason why you shouldn't have the file - its on a publicly accessible github, so here it is

[patrick]

Thanks.  With the fix of the asm embedded section ranges that Clark put in, adaptive formatting is not coming up with oddball ideas about indent amounts anymore.  That's already in for the next beta drop.  I'll look at this file next and see what's going on.

[patrick]

This should be fixed for the next beta drop as well.  It was related to the asm embedded sections. 

[jc44]

Whilst you are looking at it I do have another data point. I found that I could quite often end up with tabs in my code if I did something to generate them (type something with my cursor in empty space in the middle of the screen) immediately after switching to a new buffer (with my display on a remote X server so display was quite slow).  Is there a race condition between adaptive formatting setup and typing?

[patrick]

Hmm, the adaptive formatting isn't asychronous.  But it _is_ calculated lazily, so my worry would be switching to a newly opened buffer, and having a bug where the editing code doesn't declare early enough that it was using adaptive formatting, so part of the edit uses the default formatting profile.  I'll have to experiment with what you described and see if I can get it to happen.