Es gibt im Jahr 2021 absolut keinen Grund mehr, Latin-1 bzw. ISO 8859-1 und dergleichen zu benutzen. Verwendet gefälligst UTF-8 oder eine der anderen Kodierungen für Unicode. Wer noch Latin-1 oder ähnliches benutzt, der macht etwas falsch. Es gibt keinen Verwendungszweck dafür. Unicode wird dieses Jahr 30 Jahre alt. UTF-8 gibt es seit 1996. Unterstützung dafür gibt es in Betriebsystemen und Anwendersoftware dafür bestimmt seit 20 Jahren. Wenn irgendwelche Software heutzutage kein Unicode kann, dann ist das ein schwerwiegender Mangel. Wer auf solche Software angewiesen ist, der sollte sich mal nach Alternativen umsehen.
Es ist besorgniserregend, wie oft ich bei XNEdit irgendwelche Anfragen kriege, ob ich nicht irgendwelche Encoding-Features implementieren könnte. Zum Beispiel passt manchen Leuten offenbar UTF-8 als Default nicht. Auch wenn ich sowas jetzt immer implementiert habe, finde ich das einfach nur falsch. Einfach für alle Textdateien UTF-8 benutzen oder UTF-16 mit Byte Order Mark, wenn es sich anbietet.
Damit dies nicht ein völlig unkonstruktiver Rant ist, gibt es hier noch eine kleine Hilfe, um falsch kodierte Dateien zu finden.
find . -type f -name "*" -exec file --mime-encoding {} \; | grep -v "utf\|ascii\|binary"
Bei Bedarf statt * einen Filter einsetzen, damit nicht zu viele Dateien unnötig überprüft werden. Das ganze liefert euch eine Liste der Dateien, die ihr besser umkodieren solltet. Das Umkodieren macht dieser Oneliner jedoch nicht, das muss manuell oder mit einem extra Script gemacht werden, das ich jetzt hier nicht mitliefern wollte, da die Liste hoffentlich eh nur aus bedauerlichen Einzelfällen bestehen wird.
Finde den Syntax-Fehler in folgendem C-Code:
#include <stdio.h>
int main(int argc, char **argv) {
int a = 3;
switch(a) {
case 1:
printf("1\n");
break;
case 2:
printf("2\n");
int c2 = 0;
break;
case 3:
int c3 = 3;
printf("%d\n", c3);
break;
}
return 0;
}
Ein ähnlicher Fall wie hier im Beispiel hatte sich bei mir zugetragen. Der Compiler bemängelte die Variablendeklaration nach dem Case. Das heißt, hier im Beispiel ist die fehlerhafte Zeile die Variablendeklaration im Case 3.
Ich gebe zu, dass mich dies erstmal verwirrt hat und ich dachte, ich hätte versehentlich im C90-Modus kompiliert. Der Grund, wieso dies einen Fehler wirft, ist, dass ein Case nichts anderes als ein Label ist und Variablendeklarationen in C nicht mit einem Label versehen werden können.
Für das gelegentliche Rechnen liefern die meisten Desktops irgendeine Art von Calculator-Anwendung und aus irgend einem Grund imitieren diese meistens Taschenrechner aus dem Real-Life, und zwar immer diese billigen Teile die nichts können. Besonders nervig ist, dass diese immer nur Zwischenergebnisse anzeigen und man nicht eine längere Expression eingeben kann die dann auch mathematisch korrekt ausgewertet wird.
Neben all den unbrauchbaren Rechnern, wie der von Windows oder macOS, aber auch diverse aus dem Open Source Lager, gibt es auch einige positive Beispiele, z.B. war ich eigentlich ganz zufrieden mit dem Gnome Calculator. Da ich allerdings Gnome nicht mehr benutze musste Ersatz her. Meinen inneren Drang alles selbst zu programmieren konnte ich glücklicherweise unterdrücken und meine Wahl viel auf SpeedCrunch.
SpeedCrunch ist eine QT-Anwendung und auf allen gängigen Plattformen verfügbar. Das Interface ist eher minimalistisch, standardmäßig werden gar keine Buttons für die Ziffern und Operatoren angezeigt, weil man das ja auch nicht braucht, die Berechnung kann wesentlich effizienter direkt über die Tastatur eingegeben werden.
Praktischerweise hat man dann auch einen Verlauf der bisherigen Berechnungen.
Natürlich hat SpeedCrunch dann auch alle möglichen erweiterten Features: Variablen, Konstanten, Funktionen, Einheiten und eine Formelsammlung. Natürlich kann man auch Binär-, Oktal und Hexadezimalzahlen ein- und ausgeben.
Also insgesammt alle Features die man so braucht und mehr, verpackt in einem wesentlich sinnvolleren GUI-Konzept.
Installieren kann man SpeedCrunch auf vielen Distributionen direkt über die Paketverwaltung, ansonsten gibt es auf der Webseite Downloads.
Dieser Empfehlung kann ich mich nur anschließen.
Kontext
Ich habe ein neues XNEdit-Release veröffentlicht. XNEdit ist mein Fork des Editors NEdit, da dieser nicht mehr weiterentwickelt wird, aber wichtige Features wie Unterstützung für Unicode fehlen.
XNEdit 1.2 bringt einige GUI-Verbesserungen, hauptsächlich im Umgang mit Encodings und dem Öffnen von Dateien. So können nun z.B. Dateien aus Dateimanagern wie Nautilus per Drag'n'Drop geöffnet werden.
Ein wichtiges neues Feature ist außerdem, dass nun bei Encoding-Fehlern recht unkompliziert die Datei mit einer anderen Encoding neugeladen werden kann. Außerdem wurde auch die Erkennung der Encoding verbessert.
Damit hat sich hoffentlich der Umgang in XNEdit mit unterschiedlichen kodierten Dateien drastisch verbessert. Da ich selber praktisch nur UTF-8 nutze und auch alte Dateien schon lange konvertiert habe, hatte ich das bisher nicht so auf dem Schirm, wie nervig das sein kann.
XNEdit auf Sourceforge