Thema: Texteditor für Windows gesucht [am besten Open Source]

[kirilow]

Eigentlich benutze ich für Plaintextdateien und zum Reingucken in Sourcecodes unter Windows am liebsten Notepad++ und war bisher auch sehr zufrieden damit. Ausser dass er bisweilen unerklärlich träge wird, hat er bisher anstandslos alle meine Wünsche im Alltag erfüllt. Doch nun will ich eine Textdatei für Abenteuer. Korrektur lesen und merke, dass man in der Anzeige den Unterschied zwischen Binde- Geviert und Gedankentrich etc. nicht sieht. Das ist blöd.

Kennt Ihr einen guten (schlanken) Texteditor für Windows, oder muss ich mir wieder den emacs raufklatschen?

Grüße
kirilow

[Haukrinn]

gvim?

Dein Problem wird übrigens kein Texteditor lösen - das ist ein Problem des Textencodings. 

[Woodman]

Mein lieblingstexteditor ist Scite

Dein Problem wird übrigens kein Texteditor lösen - das ist ein Problem des Textencodings.

Oder eins der zur anzeige verwendeten schriftart

[mat-in]

Notepad++
http://notepad-plus.sourceforge.net/de/site.htm

ist open source (spendenfinanziert) und sehr praktisch. Man kann damit schlicht Text schreiben, aber auch für alles mögliche den text markieren lassen, beispielsweise beim editieren von HTML die Tags farbig machen und so. Kleines, handliches tool das gut erweiterbar ist (plugins).

[Wawoozle]

Auch Scite... einer der besten und schnellsten Editoren.

[Bitpicker]

Der Unterschied diverser Binde- und Gedankenstriche ist ein Feature von Textverarbeitungen, nicht von Editoren. Textverarbeitungen setzen, wenn die zugehörige Funktion aktiviert ist, andere Zeichen aus der Schriftart ein, sofern diese ein solches Zeichen an der richtigen Stelle hat. Editoren kümmern sich in der Regel gar nicht um Schriftarten, jedenfalls nicht in dem Umfang, wie eine Textverarbeitung das tut.

Robin

[der.hobbit]

JEdit ist auch noch ganz nett.

[kirilow]

Besten Dank erst einmal für de Hinweise. Werde mich 'mal durchtesten.

Es handelt sich im übrigen nicht um ein Encoding-Problem. Die verschiedenen Striche haben alle Unicode-Codepoints und bleiben auch erhalten. Wenn ich also den Text vom Editor beispielsweise nach Word kopiere, sind alle Gedankenstriche da.
Eher liegt es wohl am Font. Leider bin ich noch nicht darauf gekommen, wie man in notepad++ den Font für Text umstellt. Der Unterschied ist in Monospace-Schriften nicht sher groß, aber er ist eigentlich da!

Grüße
kirilow

[Bombshell]

Hallo,

aber Achtung, bei SciTe hatte ich immer Probleme mit Unicode und speichern. Ist das inzwischen besser geworden?

MfG

Stefan

[Wawoozle]

In der 1.75 wurde was zum Thema Unicode gefixt, im Zweifelsfall aber lieber nochmal ausprobieren.

[Barbara [n/a]]

Ich nutze zum Programmieren emacs.

[Heimdall]

Notepad++
http://notepad-plus.sourceforge.net/de/site.htm

+1

[Stummkraehe]

@URPG + Heimdall:
Nochmal nachgucken, wofür kirilow hier nen Ersatz sucht

[mat-in]

Er soll einfach damit weiterlesen, die Gedankenstriche sind ja oben angesprochen worden - oder eben die Software benutzen, in der auch das Dokument erstellt wurde, das ist wohl der einzige Weg, zu erreichen, daß es auch so aussieht, wie es beim Autor aussieht...

Oder gar... sich ein PDF schicken lassen, dann sieht er es so, wie es gedruckt wird.

[kirilow]

Warum so zickig?

Ich finde mein Ansinnen und meine Frage keineswegs so bekloppt, wie hier getan wird. Ich suchte einen Editor wo verschiedene Stricharten (die auch verschiedene Zeichen sind und verschiedene Unicode-Codepoints haben) auch unterschiedlich dargestellt werden. Das ist doch kein abstruser Wunsch, die Editoren können ja inzwischen mehr als ASCII. Zumal der Quelltext ja auch mit einem Editor erstellt wurde. Es geht nicht um WYSIWYG oder so.
Leider habe ich tatsächlich keinen Editor gefunden, bei dem das gut sichtbar ist. Auch der Emacs hat mich dahingehend enttäuscht (obgleich ich gewiss bin, dass man mit irgendwelcher Lisp-Akrobatik usw. da was machen könnte)

Das von mir letztlich verwendete Verfahren sah übrigens so aus:
in notepad++ öffnen --> c+p zu Word --> überarbeiten --> c+p zu notepad++ --> speichern. 
Grund: Bei Word sieht man zwar die Unterschiede, aber diese Information geht beim speichern als txt verloren. in n++ sieht man die Striche nicht, aber sie werden richtig geladen und gespeichert.
cool, wa?

Übrigens schön zu lesen, dass es hier noch weitere Freunde von n++ gibt.

Grüße
kirilow

[Haukrinn]

Bleiben wir doch mal bei Notepad++, weil ich den auch gerade offen habe:

Unter Einstellungen->Stile einfach mal eine Schrift einstellen, die Unicode kann (z.B. Arial Unicode MS oder Calibri)? Das funktioniert bei mir ohne Probleme, zumindest für Bindestrich, Minus und Gedankenstrich. Die Darstellung ist tadellos.

[kirilow]

Unter Einstellungen->Stile einfach mal eine Schrift einstellen, die Unicode kann (z.B. Arial Unicode MS oder Calibri)? Das funktioniert bei mir ohne Probleme, zumindest für Bindestrich, Minus und Gedankenstrich. Die Darstellung ist tadellos.

Cool, besten Dank! Wo findet man denn bei den Stilen die Einstellungen für Plaintextdateien? Daran bin ich nämlich gescheitert.

Grüße
kirilow

[Bitpicker]

Editoren, die zum Programmieren gedacht sind, beschränken sich meines Wissens auf den zuverlässig darstellbaren Bereich des ASCII-Zeichensatzes, also die ersten 127 Zeichen, vielleicht die ersten 255 Zeichen, also alles, was schon lange mehr oder weniger Standard ist. Die zusätzlichen Striche dürften außerhalb dieses Bereiches liegen. Auf jeden Fall gilt das für Plaintext, denn Plaintext enthält ja keine Schriftinformationen.

Robin

[kirilow]

Lieber Robin,

das stimmt allerdings schon länger nicht mehr (obgleich es schlau ist, sich als Programmierer darauf zu beschränken). Viele Programmierprachen unterstützen ja auch inzwischen Unicode (allerdinsg vielleicht nicht in jedem Encoding). Nur als Beispiel:
Der emacs (der nun allerdings auch zu mehr als zum Programmieren taugt) gibt bei mir für
M-x list-coding-systems

Code: [Auswählen]

###############################################
# List of coding systems in the following format:
# MNEMONIC-LETTER -- CODING-SYSTEM-NAME
#   DOC-STRING
1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
  ISO 2022 based 8-bit encoding for Latin-1 (MIME:ISO-8859-1).
0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
  ISO 2022 based 8-bit encoding for Latin-9 (MIME:ISO-8859-15).
* -- windows-1252 (alias: cp1252 cp1252)
  windows-1252 encoding
B -- chinese-big5 (alias: big5 cn-big5 cp950)
  BIG5 8-bit encoding for Chinese (MIME:Big5).
J -- iso-2022-jp (alias: junet)
  ISO 2022 based 7bit encoding for Japanese (MIME:ISO-2022-JP).
S -- japanese-shift-jis (alias: shift_jis sjis cp932)
  Shift-JIS 8-bit encoding for Japanese (MIME:SHIFT_JIS).
u -- mule-utf-8 (alias: utf-8)
  UTF-8 encoding for Emacs-supported Unicode characters.
2 -- iso-latin-2 (alias: iso-8859-2 latin-2)
  ISO 2022 based 8-bit encoding for Latin-2 (MIME:ISO-8859-2).
3 -- iso-latin-3 (alias: iso-8859-3 latin-3)
  ISO 2022 based 8-bit encoding for Latin-3 (MIME:ISO-8859-3).
4 -- iso-latin-4 (alias: iso-8859-4 latin-4)
  ISO 2022 based 8-bit encoding for Latin-4 (MIME:ISO-8859-4).
5 -- cyrillic-iso-8bit (alias: iso-8859-5)
  ISO 2022 based 8-bit encoding for Cyrillic script (MIME:ISO-8859-5).
7 -- greek-iso-8bit (alias: iso-8859-7)
  ISO 2022 based 8-bit encoding for Greek (MIME:ISO-8859-7).
8 -- hebrew-iso-8bit (alias: iso-8859-8 iso-8859-8-e iso-8859-8-i)
  ISO 2022 based 8-bit encoding for Hebrew (MIME:ISO-8859-8).

<snip>

L -- lao-with-esc
  Same as lao but can handle any charsets by ISO's escape sequences.
Q -- tibetan-iso-8bit-with-esc
  Same as tibetan-iso-8bit but can handle any charsets by ISO's escape sequences.
T -- thai-tis620-with-esc
  Same as thai-tis620 but can handle any charsets by ISO's escape sequences.
W -- iso-latin-8-with-esc
  Same as iso-latin-8 but can handle any charsets by ISO's escape sequences.
E -- japanese-iso-8bit-with-esc
  Same as japanese-iso-8bit but can handle any charsets by ISO's escape sequences.
####################################################
# The following coding systems are not yet loaded. #
####################################################
utf-7-mac
utf-7-dos
utf-7-unix
utf-7

weit über 100 Einträge zurück. Das Problem liegt wohl eher in den verwendeten Monospace Fonts, in denen die Unterschiede kaum (oder nicht) sichtbar sind.
Umlaute u.ä. lassen sich ja auch problemlos eingeben.

Viele Grüße
kirilow

[Woodman]

Dann solltest du vielleicht mal die typographen profis hier fragen welches monospace font gut unterscheidbare striche hat, oder halt ein nicht monospace font benutzen (wenn man nicht gerade programmiert ist das ja nicht so schlimm)

[mieserwicht im Forum]

Ich denke auch, dass die Lösung Deines Problems in der Wahl der Schriftart liegt. Wenn es Fliestext ist, dann wechsel am Besten wie schon vorgeschlagen auf eine Schrift wie Arial oder Times. Ansonsten betätige mal eine Suchmaschine deiner Wahl nach Monospaceschriften. Die verwendet man typischerweise für Quellcode und ähnliches. Da gibt es viele Leute die sich da mal Gedanken drüber gemacht haben. Und vielleicht ist sogar eine Schrift dabei, welche die Striche unterschiedlich darstellt. Wobei meiner Erfahrung nach die Unterschiede bei Monospace Schriften primär auf der Unterscheidbarkeit von O und 0 sowie l und I liegen.

[Hr. Rabe]

Dein Problem hat (glaub ich) eben auch ein wenig damit zu tun, das eine mono-schrift sich eben dadurch definiert, daß jedes Zeichen exakt ein virtuelles 'Kästchen' ausfüllt.

Da du die drei verschiedenen Bindestriche eigendlich mit 1 (-), 2 (ndash) und 3 (mdash) Kästchen darstellen müstest, läuft das irgendwie dem Gedanken einer mono-schrift zuwider, oder?

[kirilow]

Ja, das Problem ist mir schon klar. Tatächlich unterscheiden z. B. Lucida Console und Courier New Gedanken- und Bindestriche durch Dicke und Form. Diese Unterschiede sind nur arg subtil.

Die Tücke ist allerdings, dass das Format (RST – ReStructuredText) in nicht-Monospace doof aussieht.
Mein momentaner Traum: Eine Emacs-'Extension' (oder auch für n++), die diese Unterschiede einfach farblich hervorhebt. Leider sind meine elisp-Kenntnisse zu bescheiden (eigentlich nichtexistent) für so etwas.

Grüße
kirilow

[mat-in]

In welchem format sind denn die Rohdaten? vielleicht fällt uns was anderes ein?

[Bombshell]

Hallo,

In welchem format sind denn die Rohdaten? vielleicht fällt uns was anderes ein?

Hat er doch gesagt: reStructuredText. Das Problem ist mMn nicht unbedingt die Darstellung sondern der angestrebte Arbeitsablauf. Man kann reST ohne Probleme in ein Format bringen, in dem man die unterschiedlichen Striche unterscheiden kann, aber dann muss man wohl immer das Quelltextdokument mit dem formatierten Dokument synchronisieren und das ist umständlich.

MfG

Stefan