1

Using c++-mode in emacs23.

UPDATE: In response to some early comments, I tested on emacs24 and emacs25, and see exactly the same behavior. I don't have convenient access to emacs26 or emacs27 (25 is the latest version in Ubuntu Bionic LTS).

UPDATE2: The live code in question is here:

https://github.com/jasonrohrer/OneLife/blob/master/gameSource/LivingLifePage.cpp

Grep for "dummyFunctionA" and then try adding some new blocks inside that function. Since it's the function after the gigantic ::step function, editing it is slow. But the next function, ::makeActive, is fast to edit.

ORIGINAL QUESTION:

Got some code that looks like this:

void longComplicatedFunction() {
.....
}


void anotherShorterFunction() {
.....
}

longComplicatedFunction is 6000+ lines. I know that sounds horrible, but it's a main game loop, and I want it that way for many good reasons (I've shipped 19 games...). "Just split it up" would make the code harder to read in this case. If I were going to split it up, it should be for good code/design reasons, and NOT just for "emacs reasons."

I'm finding that typing new blocks inside anotherShorterFunction is very slow, and it seems to be due to auto-indent calculations. This struck me as strange, because anotherShorterFunction starts in the left-most column (it's a top-level block).

In fact, editing new blocks inside anotherShorterFunction is SLOWER than editing new blocks inside longComplicatedFunction.

The really interesting thing happens when I do this:

void longComplicatedFunction() {
.....
}


void dummyFunction() {
}


void anotherShorterFunction() {
.....
}

Now typing new blocks inside dummyFunction is slow, but editing anotherShorterFunction becomes fast again.

Thus, it seems like calculating indents inside a function depends on some kind of complete scan of the previous function? If the previous function is short, then the indent calculation is fast. But if the previous function is long and complicated, then indent calculation becomes slow.

Can anyone explain what's going on here? Why should the previous top-level block matter at all, or need to be scanned, when computing indentation inside a subsequent top-level block?

Note that this is true for any sub-block of anotherShorterFunction, like this:

void anotherShorterFunction() {
    if( true ) {
        int x = 5;
        if( x < 10 ) {
            x = 10;
            }
        }
    }
}

Creating the ( x < 10 ) block is slow if the previous top-level block is long.

And how slow? Well, slow enough that Emacs turns the cursor into a beach-ball sometimes.

  • Why are you using such an ancient version of emacs? The latest stable version of emacs is emacs26. – Chakravarthy Raghunandan Jun 28 '18 at 17:55
  • macOS is known to ship with ancient Emacs versions... – wasamasa Jun 28 '18 at 20:09
  • Seeing exactly the same behavior in Emacs 24.5.1, which is the standard version in Ubuntu Xenial (long-term-support). – Jason Rohrer Jun 28 '18 at 23:18
  • Seeing exactly the same behavior in Emacs 25.2.2, which is the latest version available in Ubuntu Bionic (newer long-term support). – Jason Rohrer Jun 28 '18 at 23:38
  • What all packages do you use for your c++ configuration? Do you have flycheck enabled? Do you observe the same when viewing the file in emacs -Q ? – Chakravarthy Raghunandan Jun 29 '18 at 6:44

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.