Modo C ++, confusión de indendación
Hoy me di cuenta de algo extraño que me molesta. Aquí hay un pequeño ejemplo de una función que escribí. Estoy usando armadillo, pero eso no es importante. Aquí, la muesca se ve bien.
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);
}
Ahora, encuentro la inicialización larga E2
y E3
molesta, así que hago un salto de línea entre los dos para una mejor legibilidad. También sangro todo mi búfer.
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);
}
Ahora, Emacs sangra el flotador [...] y la instrucción de retorno a la misma columna que E2
, E3
. Este no fue el caso en el primer ejemplo. En la mente de mi profano, las dos últimas declaraciones pertenecen a la misma columna que la arma::fvec
declaración, como en el primer ejemplo.
¿Hay alguna forma de solucionar este problema?
No pude encontrar nada específico en Internet todavía. Por lo general, estoy usando 'stroustrup' de estilo c. Probé otros estilos sin éxito.
Editar: Lo siento, lo olvidé por completo. Estoy usando emacs 25.2.2, uso helm, y una empresa completa con clang pero ningún paquete en el que pueda pensar modifica las sangrías.
Edit2: También observé el mismo comportamiento con la opción -Q (emacs -Q), por lo que supongo que puedo descartar que mis paquetes sean la causa.
Edit3: la instalación de emacs 27.1 solucionó el problema, pero esto me llevó a una pregunta de seguimiento sobre el resaltado y la sangría.
Ejemplo 3: Ahora, la sangría parece ser correcta pero el resaltado está desactivado (lo estaba antes, pero el problema de la sangría era prioritario).
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);
}
En el ejemplo anterior, Emacs se resalta E2
como una variable pero E3
es el color de texto estándar. Cuando ahora cambio la sangría a Example4:
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);
}
Puede ver que la sangría de E2
difiere de E3
. Creo que la sangría diferente es el resultado de que emacs no se reconoce E3
como una variable. ¿Alguien también observó esto?
Aquí una captura de pantalla para ilustración.

Respuestas
Bien, me puse en contacto con los mantenedores / desarrolladores de CC-Mode y resulta que esto es un error. También se encargaron de ello:https://sourceforge.net/p/cc-mode/mailman/message/37097087/
En la correspondencia encontrará un parche en forma de texto. Para aplicar el parche, copie el texto en un archivo, por ejemplo, patchfile.txt
$ mv patchfile.txt path/to/emacs/share/../lisp/progmodes $ cd path/to/emacs/share/../lisp/progmodes
Si solo tiene cc - *. El.gz y .elc pero no archivos cc- .el en la carpeta progmodes, primero tendrá que extraerlos
$ gunzip cc-*.el
Antes de aplicar el parche, compruebe si habría algún error.
$ patch --dry-run < patchfile.txt
Si el resultado es similar a esto:
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).
Ahora puede aplicar el parche
$ patch < patchfile.txt
[same output as dry-run]
Durante el parcheo, los archivos .orig se crean como copia de seguridad, en caso de que alguna vez necesite volver.
Como último paso, tendrá que compilar los archivos .el en .elc
$ emacs -Q -batch -f batch-byte-compile cc-*.el
Mi salida:
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.
Ahora reinicie emacs.
Debido a la salida ([...] más reciente que la compilación de bytes [...]). Se me pidió que abriera un búfer en emacs en modo cc, escriba
M-: c-recognize-bare-brace-inits
<Return>
Si el área de eco muestra "t", todo debería estar bien. Si no es así, podría considerar usar la copia de seguridad y regresar al estado inicial.
No obstante, en mi caso, el error se resolvió de esta manera. Me imagino que no pasará mucho tiempo hasta que la corrección también esté oficialmente en sourceforge, lo que hará que esta descripción de la corrección sea obsoleta.