Tryb C ++, zamieszanie z indendacjami
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 E2
i E3
denerwują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::fvec
stwierdzenie, 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ę E2
jako zmienna, ale E3
ma 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 E2
różni się od E3
. Uważam, że różne wcięcia są wynikiem nierozpoznawania przez emacsa E3
zmiennej. Czy ktoś też to zauważył?
Tutaj zrzut ekranu dla ilustracji

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