Tryb C ++, zamieszanie z indendacjami

Aug 16 2020

Dziś zdałem sobie sprawę z czegoś dziwnego, co mnie niepokoi. Oto mały przykład funkcji, którą napisałem. Używam pancernika, ale to nieważne. Tutaj wcięcie wygląda dobrze.

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);
}

Teraz uważam, że długa inicjalizacja E2i E3denerwująca, więc robię przerwę między nimi dla lepszej czytelności. Wcinam też cały bufor.

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);
}

Teraz Emacs wcięcie pływaka [...] oraz oświadczenie powrotną do tej samej kolumnie co E2, E3. Tak nie było w pierwszym przykładzie. W moim umyśle laika ostatnie dwa stwierdzenia należą do tej samej kolumny, co arma::fvecstwierdzenie, tak jak było w pierwszym przykładzie.

Czy jest sposób, aby to naprawić?

Nie udało mi się jeszcze znaleźć nic konkretnego w internecie. Zwykle używam „stroustrup” w stylu C. Próbowałem innych stylów bez powodzenia.

Edycja: Przepraszam, zupełnie zapomniałem. Używam emacsa 25.2.2, używam helm, a firma z clangiem, ale żaden pakiet, o którym myślę, nie modyfikuje wcięć.

Edit2: Zaobserwowałem również to samo zachowanie z opcją -Q (emacs -Q), dlatego myślę, że mogę wykluczyć, że przyczyną są moje pakiety.

Edit3: Zainstalowanie emacsa 27.1 rozwiązało problem, ale doprowadziło mnie to do pytania uzupełniającego dotyczącego podświetlania i wcięć.

Przykład 3: Teraz wcięcie wydaje się być poprawne, ale wyróżnianie jest wyłączone (było wcześniej, ale kwestia wcięć była priorytetem).

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);
}

W powyższym przykładzie Emacs wyróżnia się E2jako zmienna, ale E3ma standardowy kolor tekstu. Kiedy teraz zmienię wcięcie na Przykład 4:

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);
}

Widać, że wcięcie E2różni się od E3. Uważam, że różne wcięcia są wynikiem nierozpoznawania przez emacsa E3zmiennej. Czy ktoś też to zauważył?

Tutaj zrzut ekranu dla ilustracji

Odpowiedzi

Andi Aug 31 2020 at 01:08

OK, więc skontaktowałem się z opiekunami / programistami CC-Mode i okazuje się, że to błąd. Zadbali też o to:https://sourceforge.net/p/cc-mode/mailman/message/37097087/

W korespondencji znajdziesz naszywkę w formie tekstowej. Aby zastosować łatkę, skopiuj tekst do pliku np. Patchfile.txt

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

Jeśli masz tylko cc - *. El.gz i .elc, ale nie masz plików cc- .el w folderze progmodes, najpierw musisz je rozpakować

$ gunzip cc-*.el

Przed nałożeniem łatki sprawdź, czy nie ma błędów

$ patch --dry-run < patchfile.txt

Jeśli wynik wygląda podobnie do tego:

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).

Możesz teraz nałożyć łatkę

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

Podczas łatania pliki .orig są tworzone jako kopia zapasowa na wypadek, gdybyś kiedykolwiek musiał wrócić.

Na koniec będziesz musiał skompilować pliki .el do .elc

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

Mój wynik:

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.

Teraz zrestartuj emacsa.

Ze względu na dane wyjściowe ([...] nowsze niż kompilowane bajtowo [...]). Poproszono mnie o otwarcie bufora w emacsie w trybie cc, wpisz

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

Jeśli obszar echa wyświetla „t”, wszystko powinno być w porządku. Jeśli nie, możesz rozważyć użycie kopii zapasowej i powrót do stanu początkowego.

Niemniej jednak w moim przypadku błąd został rozwiązany w ten sposób. Mogę sobie wyobrazić, że nie zajmie to dużo czasu, zanim poprawka zostanie również oficjalnie udostępniona na sourceforge, co spowoduje, że opis poprawki stanie się przestarzały.