C ++ - Modus, Verwirrung bei der Identifizierung

Question

Heute habe ich etwas Seltsames bemerkt, das mich stört. Hier ist ein kleines Beispiel für eine Funktion, die ich geschrieben habe. Ich benutze Gürteltier, aber das ist unwichtig. Hier sieht die Einrückung gut aus.

float GetE0()
{
    // Calculate E0 according to Kurfess et. al, 2000
    arma::fvec
        E2 {vertex2X - vertex1X, vertex2Y - vertex1Y, vertex2Z - vertex1Z}, E3 {vertex3X - vertex2X, vertex3Y - vertex2Y, vertex3Z - vertex2Z};
    
    float cosPhi2 = norm_dot(E2,E3);
    
    return Kurfess_Eq5(cosPhi2);
}

Jetzt finde ich die lange Initialisierung von E2und E3ärgerlich, so dass ich zur besseren Lesbarkeit einen Zeilenumbruch zwischen den beiden mache. Ich rücke auch meinen ganzen Puffer ein.

float GetE0()
{
    // Calculate E0 according to Kurfess et. al, 2000
    arma::fvec
        E2 {vertex2X - vertex1X, vertex2Y - vertex1Y, vertex2Z - vertex1Z},
        E3 {vertex3X - vertex2X, vertex3Y - vertex2Y, vertex3Z - vertex2Z};

        float cosPhi2 = norm_dot(E2,E3);

        return Kurfess_Eq5(cosPhi2);
}

Jetzt rückt Emacs den float [...] und die return-Anweisung in dieselbe Spalte wie E2, E3. Dies war im ersten Beispiel nicht der Fall. In den Augen meines Laien gehören die letzten beiden Aussagen zur gleichen Spalte wie die arma::fvecAussage, wie im ersten Beispiel.

Gibt es eine Möglichkeit, dies zu beheben?

Ich konnte noch nichts Spezielles im Internet finden. Normalerweise verwende ich "Stroustrup" im C-Stil. Ich habe andere Stile ohne Erfolg ausprobiert.

Edit: Sorry, ich habe es komplett vergessen. Ich benutze Emacs 25.2.2, ich benutze Helm und eine Firma mit Clang, aber kein Paket, an das ich denken kann, ändert die Einrückungen.

Edit2: Ich habe das gleiche Verhalten auch mit der Option -Q (emacs -Q) beobachtet, daher kann ich wohl ausschließen, dass meine Pakete die Ursache sind.

Edit3: Die Installation von emacs 27.1 hat das Problem behoben, aber dies führte mich zu einer Folgefrage bezüglich Hervorheben und Einrücken.

Beispiel 3: Jetzt scheint die Einrückung korrekt zu sein, aber die Hervorhebung ist deaktiviert (es war vorher, aber das Einrückungsproblem hatte Priorität).

float GetE0()
{
    // Calculate E0 according to Kurfess et. al, 2000
    arma::fvec
        E2 {vertex2X - vertex1X, vertex2Y - vertex1Y, vertex2Z - vertex1Z},
        E3 {vertex3X - vertex2X, vertex3Y - vertex2Y, vertex3Z - vertex2Z};

    float cosPhi2 = norm_dot(E2,E3);
    return Kurfess_Eq5(cosPhi2);
}

Im obigen Beispiel wird Emacs E2als Variable hervorgehoben, hat jedoch E3die Standardtextfarbe. Wenn ich jetzt den Einzug in Beispiel 4 ändere:

float GetE0()
{
    // Calculate E0 according to Kurfess et. al, 2000
    arma::fvec

         E2 {vertex2X - vertex1X,
         vertex2Y - vertex1Y,
         vertex2Z - vertex1Z},

         E3 {vertex3X - vertex2X,
             vertex3Y - vertex2Y,
             vertex3Z - vertex2Z};

    float cosPhi2 = norm_dot(E2,E3);
    return Kurfess_Eq5(cosPhi2);
}

Sie können sehen, dass sich die Einrückung von E2unterscheidet E3. Ich glaube, der unterschiedliche Einzug ist das Ergebnis von Emacs, die nicht E3als Variable erkannt werden. Hat das auch jemand beobachtet?

Hier ein Screenshot zur Veranschaulichung

Answer 1

Okay, ich habe Kontakt mit den Betreuern / Entwicklern von CC-Mode aufgenommen und es stellt sich heraus, dass dies ein Fehler ist. Sie haben sich auch darum gekümmert:https://sourceforge.net/p/cc-mode/mailman/message/37097087/

In der Korrespondenz finden Sie einen Patch in Textform. Um den Patch anzuwenden, kopieren Sie den Text in eine Datei, z. B. patchfile.txt

$ mv patchfile.txt path/to/emacs/share/../lisp/progmodes $ cd path/to/emacs/share/../lisp/progmodes

Wenn Sie nur cc - *. El.gz und .elc, aber keine cc- .el-Dateien im progmodes-Ordner haben, müssen Sie diese zuerst extrahieren

$ gunzip cc-*.el

Überprüfen Sie vor dem Anwenden des Patches, ob Fehler vorliegen

$ patch --dry-run < patchfile.txt

Wenn die Ausgabe ähnlich aussieht:

Hunk #1 succeeded at 9091 (offset -22 lines).
Hunk #2 succeeded at 9144 (offset -22 lines).
Hunk #3 succeeded at 11731 (offset -29 lines).
checking file cc-langs.el
Hunk #1 succeeded at 3684 (offset -9 lines).

Sie können den Patch jetzt anwenden

$ patch < patchfile.txt
[same output as dry-run]

Während des Patchens werden .orig-Dateien als Backup erstellt, falls Sie jemals zurückkehren müssen.

Als letzten Schritt müssen Sie die .el-Dateien zu .elc kompilieren

$ emacs -Q -batch -f batch-byte-compile cc-*.el

Meine Ausgabe:

Source file ‘/opt/emacs/emacs-27.1-install/share/emacs/27.1/lisp/progmodes/cc-langs.el’ newer than byte-compiled file; using older file

In end of data:
cc-styles.el:687:1:Warning: the function ‘c-guess-basic-syntax’ might not be
    defined at runtime.

Starten Sie jetzt Emacs neu.

Wegen der Ausgabe ([...] neuer als bytekompiliert [...]). Ich wurde gebeten, einen Puffer in Emacs im CC-Modus Typ zu öffnen

M-: c-recognize-bare-brace-inits
<Return>

Wenn der Echo-Bereich "t" anzeigt, sollte alles in Ordnung sein. Wenn nicht, können Sie die Sicherung verwenden und zum Ausgangszustand zurückkehren.

In meinem Fall wurde der Fehler jedoch auf diese Weise behoben. Ich könnte mir vorstellen, dass es nicht lange dauern wird, bis der Fix auch offiziell auf SourceForge ist, was diese Fixbeschreibung überflüssig macht.