ASCII Text Editoren

Es gibt 167 Antworten in diesem Thema, welches 5.270 mal aufgerufen wurde. Der letzte Beitrag (18. Oktober 2025 um 18:28) ist von Jammet.

  • Zitat

    Ist PAB-Edit wirklich ein ASCII Editor? Das wäre wirklich wichtig. Ich persönlich würde den im PRG Format von Datenträgern aller Art aufrufen.

    Nein, PAB-Edit ist ein PETSCII Editor, zugeschnitten auf den C64.

    Zitat

    Muss gestehen, die Tastaturkürzel sind nicht so meins, wirkt archaisch wenn man sich anschaut wie z.B. Retrofan und Korodny das in Mockups so zeigen. Das ist natürlich subjektiv.

    Ja, man kann alles viel schöner machen. PAB-Edit war ein Proof of Concept um einen einfachen Texteditor auf dem C64 in PABasic zu erstellen. Einen anderen Anspruch hatte ich an das Programm nicht :-)

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Warum muss das ganze eigentlich unbedingt ASCII auf dem C64 sein ? Wenn man seine auf dem C64 getippten Texte am PC wirklich weiter verarbeiten will, muss man die Datei doch eh noch auf den PC übertragen, im Zuge dessen kann man die Datei auch einfach einmal durch Bitte melde dich an, um diesen Link zu sehen. jagen und fertig :nixwiss:

    Ich will hier um gottes Willen niemanden davon abhalten einen ASCII Editor für den C64 zu schreiben aber warum das Rad neu erfinden ? Ein weiterer Vorteil von Bitte melde dich an, um diesen Link zu sehen. ist, dass man am C64 mit dem Editor seiner Wahl arbeiten kann denn PETSCII Editoren gibt es ja genug :thumbsup:

    "Werter Pöbel, wertes Gesocks ... aus dem Arsche zieht euch den Stock ..."

  • Warum muss das ganze eigentlich unbedingt ASCII auf dem C64 sein ? Wenn man seine auf dem C64 getippten Texte am PC wirklich weiter verarbeiten will, muss man die Datei doch eh noch auf den PC übertragen, im Zuge dessen kann man die Datei auch einfach einmal durch Bitte melde dich an, um diesen Link zu sehen. jagen und fertig

    Wenn du ausschließlich englische Texte bearbeiten willst, geht das natürlich - auch wenn mich persönlich jeder zusätzliche Bearbeitungsschritt nerven würde. In dem Moment wo du Umlaute benutzen möchtest, musst du aber sowieso eine neue Kodierung nehmen. Dann bietet sich ein etablierter Standard an.

    Ein weiterer Vorteil von Bitte melde dich an, um diesen Link zu sehen. ist, dass man am C64 mit dem Editor seiner Wahl arbeiten kann denn PETSCII Editoren gibt es ja genug :thumbsup:

    Nenn doch mal ein paar? So viele Vorschläge kamen hier ja nicht, als noch im RAUM stand es ginge um PETSCII.

  • Wenn du ausschließlich englische Texte bearbeiten willst, geht das natürlich - auch wenn mich persönlich jeder zusätzliche Bearbeitungsschritt nerven würde. In dem Moment wo du Umlaute benutzen möchtest, musst du aber sowieso eine neue Kodierung nehmen.

    Wenn ich Texte am C64 erstelle, ist mir ja schon klar dass es keine Umlaute gibt ... hab ich auch nie vermisst.

    Nenn doch mal ein paar?

    Ich benutze tatsächlich PAB-EDIT :thumbsup:

    Ansonsten gibts noch : SVICC, Speedscript, Paperclip, VizaWrite, Easy Script, Easy-Text Editor usw.

    "Werter Pöbel, wertes Gesocks ... aus dem Arsche zieht euch den Stock ..."

  • Ich hab ehrlich gesagt keine Lust immer wieder auf's neue zu erklären weshalb ich gerne einen ASCII Editor benutzen möchte. Lest doch bitte den Thread ^^. Sorry.

  • im Zuge dessen kann man die Datei auch einfach einmal durch Petcat jagen und fertig :nixwiss:

    Das ist vielleicht noch praktikabel, wenn man den Text nur einmal von A noch B bekommen möchte. Wenn du aber den Text abwechselnd am C64 und PC weiter bearbeiten willst, macht das irgendwann keinen Spaß mehr. Und Umlaute und Sonderzeichen sind dann zumeist auch weg.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Muss gestehen, die Tastaturkürzel sind nicht so meins, wirkt archaisch

    Hm? Ich bin jetzt nicht mit der Belegung jedes einzelnen Shortcuts einverstanden, aber im Großen und Ganzen bedient man so Texteditoren auf modernen Systemen mit graphischer Benutzeroberfläche. Die Menge an Nutzern, die das gewöhnt ist, dürfte erheblich größer sein als die der Leute mit vi(m)-Erfahrung.

    Und vi ist in den Augen vieler Leute unbenutzbar, weil sie nicht wissen [...]

    vim ist ein Profi-Wekzeug für Leute die bereit sind, sich wirklich einzuarbeiten und sich an der "archaischen" Trennung in vier verschiedene Modi nicht stören. Als Vorbild für einen C64-Texteditor, der möglichst viele Leute anspricht, taugt das m.E. nicht.

  • Lest doch bitte den Thread ^^. Sorry.

    Hab ich, mehrfach, danke ...

    Das ist vielleicht noch praktikabel, wenn man den Text nur einmal von A noch B bekommen möchte. Wenn du aber den Text abwechselnd am C64 und PC weiter bearbeiten willst, macht das irgendwann keinen Spaß mehr. Und Umlaute und Sonderzeichen sind dann zumeist auch weg.

    Ja, da stimme ich dir zu ! Aber : wer macht das tatsächlich so intensiv ?

    Ich schreibe wirklich viel Text auf alten Computern, auch auf PETSCII Rechnern und ich bin da noch nie an Grenzen gestoßen. Rezepte, D&D Abenteuer, Notizen, Konzepte usw. erstelle ich alle auf dem C64.

    Wenn man komfortabel (!) sowohl auf PC als auch auf dem C64 eine (einzelne) Textdatei bearbeiten möchte, sollte man eh über eine Art "Cloud-Lösung" z.B. über das WiC nachdenken, ansonsten muss man die Datei wie schon erwähnt immer und immer wieder hin und her übertragen, dann fällt es auch nicht mehr ins Gewicht diese Datei jedes Mal umwandeln zu müssen (BAT erstellen, Datei draufstehen, fertig, Beispiel im Bitte melde dich an, um diesen Link zu sehen. ) ...

    Zu bedenken ist auch, dass wenn es ein reiner ASCII Editor wird, dass dieser dann zu allen anderen C64 Editoren inkompatibel ist, hier sollte man dann also mMn auch eine Umwandlung direkt am C64 in Betracht ziehen.

    "Werter Pöbel, wertes Gesocks ... aus dem Arsche zieht euch den Stock ..."

  • Ich benutze tatsächlich PAB-EDIT :thumbsup:

    Ansonsten gibts noch : SVICC, Speedscript, Paperclip, VizaWrite, Easy Script, Easy-Text Editor usw.

    SVICC kannte ich noch gar nicht, danke.

    Speedscript ist kein PETSCII, ich kann mich aber nicht mehr erinnern was da genutzt wurde (vermutlich Screen-Codes? keine Ahnung). VizaWrite speichert PETSCII, aber inklusive diverser VW-spezifischer Control-Codes - keine Ahnung was petcat daraus macht. Easy-Text-Editor ist ein Notemaker, der speichert überhaupt nicht? Paperclip und Easy Script kenne ich nicht, aber aufgrund der bisherigen Trefferquote fehlt mir die Motivation, mir die anzuschauen ;)

  • Korodny

    Ich hatte die alle mal in den Fingern um mal ein paar Zeilen zu tippen, load/save und ob es PETSCII ist waren für mich da erstmal nebensächlich ;)

    Easy-Text Editor speichert glaube ich auch Bildschirmweise so wie NOVA-Pic ...

    "Werter Pöbel, wertes Gesocks ... aus dem Arsche zieht euch den Stock ..."

  • Und vi ist in den Augen vieler Leute unbenutzbar, weil sie nicht wissen, wie man zwischen Operationsmodus und Eingabmodus wechselt, oder das Ding beendet, oder was speichert...

    Meine erste Erfahrung mit vi war (wenn ich mich richtig erinnere) unter Coherent Linux. Ich habe den gestartet und musste den Rechner neu starten, weil ich aus dem Programm nicht mehr raus kam. Ich wusste da natürlich auch nicht, wie man unter Coherent einen Task abschießt. Hätte vermutlich auch funktioniert.

    Wenn man zu dem Zeitpunkt schon viele Jahre Computererfahrung hat (mit CBMs, CP/M und MS-DOS), prägen solche Erlebnisse. Und man weiß dann, dass es nicht an der mangelnden eigenen Erfahrung liegt, dass sowas passiert.

    Ich habe damals schon konsequent die Meinung vertreten, dass sich der Computer mir und meinen Gewohnheiten anzupassen hat und nicht umgekehrt. Ich habe ihn gekauft und nicht er mich. ;)

    Also selbst auf dem C64, tut man sich sowas freiwillig an, wenn es Alternativen gibt? Das ist doch reiner Masochismus. :sm:

  • Muss gestehen, die Tastaturkürzel sind nicht so meins, wirkt archaisch

    Hm? Ich bin jetzt nicht mit der Belegung jedes einzelnen Shortcuts einverstanden, aber im Großen und Ganzen bedient man so Texteditoren auf modernen Systemen mit graphischer Benutzeroberfläche. Die Menge an Nutzern, die das gewöhnt ist, dürfte erheblich größer sein als die der Leute mit vi(m)-Erfahrung.

    Und vi ist in den Augen vieler Leute unbenutzbar, weil sie nicht wissen [...]

    vim ist ein Profi-Wekzeug für Leute die bereit sind, sich wirklich einzuarbeiten und sich an der "archaischen" Trennung in vier verschiedene Modi nicht stören. Als Vorbild für einen C64-Texteditor, der möglichst viele Leute anspricht, taugt das m.E. nicht.

    Kurz vorweg: ich komme mit diesem Zitat Werkzeug im Editor echt schlecht klar. Tut mir leid wenn ich da bärenmäßig viel Text zitiere den ich eigentlich gerne abkürzen würde.
    In meinem Bekanntenkreis benutzen erstaunlich viele noch vi(m) für alltägliches. Ich hatte schon kurz vorher geschrieben: ich komm mit dem Ding zwar auch klar, aber nicht so gut, wie die anderen, und ich würde das auch der breiten Masse niemals zumuten wollen, vielleicht hab ich mich da vorher nicht sehr klar ausgedrückt. Das Ding ist erst recht von der Zeit überholt worden, es sei denn man arbeitet an einer Workstation aus den 70ern oder sowas.

    Verstanden hab ich die Shortcuts auch. Ich finde sie, wie schrieb, subjektiv, nicht leicht zu lernen und würde einfach gerne andere benützen. Das ist alles. Das hätte ich nicht zu erwähnen brauchen, aber ich fühlte mich gefragt, "Warum benutzt du nicht meinen?" und nebst ASCII wäre das meine Antwort gewesen.

  • In meinem Bekanntenkreis benutzen erstaunlich viele noch vi(m) für alltägliches. ... Das Ding ist erst recht von der Zeit überholt worden, es sei denn man arbeitet an einer Workstation aus den 70ern oder sowas.

    Es ist nie verkehrt, mit vi umgehen zu können. Das wird auch die nächsten 50 Jahre so bleiben :)

  • Aber : wer macht das tatsächlich so intensiv ?

    Nun ja, einige! Die Sache ist doch die: Die, die es anders machen (also z.B. wie von dir aufgezeigt), die haben doch schon Lösungen (PETSCII-Editoren plus Konverter in beide Richtungen). Hier geht es um die, die bisher, trotz über 40 Jahren C64, noch nicht "abgeholt" wurden. Lass es 10 Leute sein, 20 oder 200. Wer weiß das schon und ich finde das in unserer Bubble auch nicht wichtig. Letztlich ist es so, dass es einen (gewissen) Bedarf gibt, der bisher nicht abgedeckt wurde. Statt also irgendwas zu programmieren, nach dem "niemand" gefragt hat, kann es vielleicht sinnvoll sein, etwas zu programmieren, nach dem "jemand" gefragt hat.

    Es gibt ja keinen Zwang. Wenn es niemand programmieren will, dann ist das eben so. Aber wenn es jemand tun will, wer sollte darunter leiden? Ich persönlich fände es klasse, erstmalig ganz "normale" (also mit Umlauten, Sonderzeichen usw.) PC-Texte ohne Konvertierung auf dem C64 lesen/öffnen zu können und genauso den umgekehrten Weg. Also eigentlich nur das, was wir seit vielen Jahren zwischen unterschiedlichen Plattformen haben/anstreben.

    Wenn man komfortabel (!) sowohl auf PC als auch auf dem C64 eine (einzelne) Textdatei bearbeiten möchte, sollte man eh über eine Art "Cloud-Lösung" z.B. über das WiC nachdenke

    Das bleibt in Bezug auf den hier angemeldeten Bedarf vollkommen unbeeinflusst. Ein C64-Editor, der ohne externen Konverter kompatibel zu heutigen PC/Mac-Formaten ist, ist die Grundvoraussetzung (oder zumindest die einfachste Lösung) für sowas. Ob man am Ende die Daten per SD-Karte oder übers WLAN austauscht/teilt, ändert nichts am grundsätzlichen Wunsch der Daten-Kompatibilität.

    hier sollte man dann also mMn auch eine Umwandlung direkt am C64 in Betracht ziehen.

    Das hatte ich ja schon als Wunsch geäußert. Eine Umwandlung hin zu PETSCII (oder eine Runtime zum Ansehen der ISO/UTF-Texte) wäre natürlich schön. Das kann mE aber auch extern, durch einen C64-Konverter, geschehen und muss nicht Teil des Editor-Programms sein. Ausnahmsweise würde bei diesem neuen Editor (sollte es ihn geben) die Kompatibilität zur C64-Außenwelt das Key-Feature sein.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • ALeX hat jetzt doch weniger Lust, einen Editor zu programmieren, als anfangs angenommen. Trotzdem möchte ich ein wenig Vorarbeit leisten, um ihn vielleicht doch noch zu überzeugen. Ein Knackpunkt ist die nötige Zeilen- bzw. Absatzlänge (also bis zum nächsten "Return"). Wie gehen damit typische C64-Textverarbeitungen um? Gibt es da Beschränkungen (über den freien Speicherplatz hinaus)?

    Was passiert, wenn man in einem längeren Absatz am Anfang Zeichen einfügt? Muss dann der gesamte Folgetext im Speicher Byte-weise verschoben werden? Kann der C64 das (ohne Tricks) schnell genug?

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • ALeX hat jetzt doch weniger Lust, einen Editor zu programmieren, als anfangs angenommen. Trotzdem möchte ich ein wenig Vorarbeit leisten, um ihn vielleicht doch noch zu überzeugen. Ein Knackpunkt ist die nötige Zeilen- bzw. Absatzlänge (also bis zum nächsten "Return"). Wie gehen damit typischen C64-Textverarbeitungen um? Gibt es da Beschränkungen (über den freien Speicherplatz hinaus)?

    Was passiert, wenn man in einem längeren Absatz am Anfang Zeichen einfügt? Muss dann der gesamte Folgetext im Speicher Byte-weise verschoben werden? Kann der C64 das (ohne Tricks) schnell genug?


    Ich kann leider nicht folgen was du mit dem ersten Problem meinst. Tabulator einrückung? Wieviele Leerstellen? Ich glaube es sind oft 8, aber manchmal auch 4. Viele hauen einfach viermal auf die Leertaste. Automatisches einrücken bei Folge-Absätzen nach einem Druck auf Enter ist fast schon gehobene Klasse automatischer Vorformatierung, falls du sowas meinst. Sicher schön zu haben, und Texte formatieren und ordentlich visuell gestalten macht Spass.
    Aber vielleicht meintest du ja auch etwas komplett anderes. Die Beschränkung auf nur 40 Zeichen wäre schade, gerade wo es um ein Hin und Her zwischen den Welten geht, wäre es gut, wenn man das zumindest umstellen könnte zwischen Wordwrapping bei 40, oder 80 Zeichen.

    Was du mit dem zweiten Problem genau meinst, da bin ich mir auch nicht so ganz sicher.

    Text Flow? Also Word Wrapping "around the corner", vollständiges weiterschubsen aller Wörter in allen darunterliegenden Zeilen? Das kann vielleicht sehr anspruchsvoll und langsam werden, wenn die Absätze wirklich sehr lang werden. Vielleicht kann man das Deckeln, und den Absatz ab einer bestimmten Schwelle dann, wenn es einmal passig ist, nicht mehr einpassen sondern nur noch stumpf weiter nach unten drücken. Oder, man lässt das, und baut dafür eine Funktion ein wie, "markierten Text formatieren" (justify) (Blocksatz, od. Blocksatz mit Tabstopp).

  • Ich kann leider nicht folgen was du mit dem ersten Problem meinst.

    Was du mit dem zweiten Problem genau meinst, da bin ich mir auch nicht so ganz sicher.

    Die Fragen waren auch eher an die programmierenden Thread-Teilnehmer gerichtet.

    Mich interessiert halt, wie die C64-Bestands-Textverarbeitungen (vermutlich) arbeiteten und mit den Möglichkeiten wirtschafteten. ALeX ging anfangs von einer Art Quelltext-Editor aus, der eine maximale "Zeilen"-Länge hat, wie z.B. der Basic V2-Editor mit seiner 80 Zeichen-Beschränkung (oder wie lang das damals war – ich meine, 2 Bildschirmzeilen).

    Da gibt/gab es das Problem nicht, dass "lange" Absätze von z.B. 5000 Zeichen Byteweise verschoben werden müssen, weil man ein Wort am Anfang editiert.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Ein Knackpunkt ist die nötige Zeilen- bzw. Absatzlänge (also bis zum nächsten "Return"). Wie gehen damit typischen C64-Textverarbeitungen um? Gibt es da Beschränkungen (über den freien Speicherplatz hinaus)?

    Was passiert, wenn man in einem längeren Absatz am Anfang Zeichen einfügt? Muss dann der gesamte Folgetext im Speicher Byte-weise verschoben werden? Kann der C64 das (ohne Tricks) schnell genug?

    Wie das beim zed-Editor gemacht wurde, beschreibt der Autor hier: Bitte melde dich an, um diesen Link zu sehen.

  • Wie das beim zed-Editor gemacht wurde, beschreibt der Autor hier

    Danke schonmal – ich reiche das weiter. Gerne noch mehr Quellen/Infos.

    Korodny wird ja auch eine Idee haben, wie er den Text im Speicher verwalten würde.

    Wir kommen zwar offensichtlich beim Thema UI nicht zusammen (ich sehe da aber auch keinen Bedarf eines Konsenses, macht halt jeder wie er es für richtig hält) aber seine Idee mit dem "dynamischen Encoding" (so nenne ich das jetzt mal) fand ich letztlich gar nicht schlecht.

    Jede Art des konstruktiven Gedankenaustauschs würde uns dem Ziel (C64 Plaintext-Editor mit hoher PC-Kompatibilität) ein Stück näher bringen.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Ein Knackpunkt ist die nötige Zeilen- bzw. Absatzlänge (also bis zum nächsten "Return"). Wie gehen damit typischen C64-Textverarbeitungen um? Gibt es da Beschränkungen (über den freien Speicherplatz hinaus)?

    Mir sind keine bekannt. Nicht dass ich mich erinnern könnte, je besonders lange Absätze verfasst zu haben - aber in Handbüchern oder in der Praxis ist mir nie eine Einschränkung begegnet.

    Ich kenne drei Ansätze:

    1. Text wird formatiert im Speicher abgelegt, die Zeilen sind alle gleich lang - sie werden einfach mit SPACE o.ä. aufgefüllt, bis 40/80 Zeichen voll sind. Startexter macht das bspw. so, Vizawrite WIMRE teilweise auch. Vorteile: schnellstmögliche Darstellung (jede Zeile liegt im Speicher an Position Zeilennummer*Zeilenlänge, Zeilen können direkt ohne irgendwelche Checks in den Bildschirmspeicher geschrieben werden), Folgetext muss beim Einfügen von Buchstaben in der Mitte sehr viel weniger verschoben werden. Nachteil: Man verschwendet in jeder Zeile, die nicht ganz bis ans Ende vollgeschrieben ist, ein paar Bytes.
    2. Text wird formatiert im Speicher abgelegt, Zeilen haben ein Kennbyte für "Zeilenende" (nicht Absatzende). Wie oben ist die Formatierung auf die Texteingabe verlegt, d.h. Ausgabe etwas beschleunigt. Nachteil: bei jedem irgendwo eingefügten Zeichen muss der komplette Folgetext verschoben werden, außerdem muss viel mit Zeigern hantiert werden (s.u.)
    3. Die Textverarbeitung formatiert tatsächlich erst bei der Ausgabe, sie speichert also "Absätze", nicht "Zeilen". Jasword macht das (WIMRE) so. Braucht einiges an Meta-Information (nehme ich an), bspw. um aus "Absatz X" wieder die aktuelle Zeilennummer ermitteln zu können. Der Vorteil dieser Methode ist, dass man verschiedene Absatz-Typen definieren kann, die man dann separat konfigurieren kann, und die Darstellung aller Absätze dieses Typs wird automatisch angepasst - ähnlich den Stilvorlagen in einer modernen Textverarbeitung. Ist also eher ein "Textverarbeitungs"- als ein "Texteditor"-Ding.

    Unterschiedliche Zeilenlängen (Ansatz 2 und 3 in der Liste) bedeuten allerdings, dass das Programm sich beim Abarbeiten/Anzeigen von Text an Verknüpfungen entlang hangeln muss: Jede Zeile/jeder Absatz enthält auch zwei Zeiger: auf den Anfang der nächsten und vorherigen Zeile (bzw. Absatz).

    Eine Beschränkung der Absatzgröße gäbe es ja nur bei Option 3 (die anderen beiden Optionen kennen "Absätze" eigentlich gar nicht wirklich): Wenn der Zeiger nur ein Byte ist, dürfen Absätze nur 256 Zeichen lang sein. Das ist natürlich absurd, weswegen man ein paar Bit mehr benutzen würde. Aber selbst wenn man nur 10- oder 11-Bit-Zeiger nutzen würde, ist man da schnell bei Absatzgrößen von mehren Kilobyte...

    Was passiert, wenn man in einem längeren Absatz am Anfang Zeichen einfügt? Muss dann der gesamte Folgetext im Speicher Byte-weise verschoben werden? Kann der C64 das (ohne Tricks) schnell genug?

    Das ist unabhängig von der Länge des Absatzes notwendig, es sei denn man nutzt den oben erwähnten Ansatz mit lauter gleichlangen Linien: Startexter muss den Folgetext nur so weit verändern bis er auf eine Zeile trifft, wo am Ende noch genug Leerstellen sind damit kein weiterer Zeilenumbruch notwendig ist. Wer stattdessen mit variablen Zeilen- oder Absatzlängen hantiert, muss immer kopieren.

    C64-Textverarbeitungen werden alle unerträglich langsam, wenn ein langer Text geändert wird. Es empfiehlt sich deswegen, von der Möglichkeit der Verkettung von Texten - das bieten fast alle an - ausgiebigen Gebrauch zu machen.