Betterbird wird extrem langsam

[Arno Welzel]

Gerade erlebe ich einen sehr seltsamen Effekt:

Wenn ich auf eine Nachricht antworte oder eine neue Nachricht schreibe,
wird Betterbird (91.12.0-bb35 (64-bit), Windows 10 Pro) zwischendruch
extrem "zäh". Sowohl im Betreff-Feld als auch im Editor dauert es 1-2
Sekunden bis die Tastatureingaben auch verarbeitet sind.

Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
wieder vorbei. Manchmal dauert es auch länger.

Ist der Effekt bekannt?

Nein, neues Profil habe ich noch nicht probiert. Allerdings hat sich
seit gestern abend im Profil nichts geändert und da ging es noch völlig
problemlos. Bei Gelegenheit werde ich es aber auch mal mit einem neuen
Profil testen.

--
Arno Welzel
https://arnowelzel.de

[Franklin Schiftan]

Am 2022-08-19 um 15:16 schrieb Arno Welzel:
> Gerade erlebe ich einen sehr seltsamen Effekt:
>
> Wenn ich auf eine Nachricht antworte oder eine neue Nachricht schreibe,
> wird Betterbird (91.12.0-bb35 (64-bit), Windows 10 Pro) zwischendruch
> extrem "zäh". Sowohl im Betreff-Feld als auch im Editor dauert es 1-2
> Sekunden bis die Tastatureingaben auch verarbeitet sind.
>
> Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
> wieder vorbei. Manchmal dauert es auch länger.
>
> Ist der Effekt bekannt?

M.E. war das in TB schon immer so - wenn in der Zeit etliche NGs
abgerufen wurden.

.... und tschüss

Franklin

[Joerg Lorenz]

Am 19.08.22 um 16:00 schrieb Franklin Schiftan:

Das kann ich hier bestätigen auf Mac und Linux. Ist egal. Bei mir kann
ich das wirklich auf das Polling der Server zurückführen. Das hat sich
noch akzentuiert, seit ich zwei Newsserver verwende. Es betrifft alle
Funktionen. t, n, b usw.



--
De gustibus non est disputandum

[Claus Reibenstein]

Franklin Schiftan schrieb am 19.08.2022 um 16:00:

> Am 2022-08-19 um 15:16 schrieb Arno Welzel:
>
>> Wenn ich auf eine Nachricht antworte oder eine neue Nachricht schreibe,
>> wird Betterbird (91.12.0-bb35 (64-bit), Windows 10 Pro) zwischendruch
>> extrem "zäh". Sowohl im Betreff-Feld als auch im Editor dauert es 1-2
>> Sekunden bis die Tastatureingaben auch verarbeitet sind.
>>
>> Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
>> wieder vorbei. Manchmal dauert es auch länger.
>

> M.E. war das in TB schon immer so - wenn in der Zeit etliche NGs
> abgerufen wurden.

Das war schon (und ist immer noch) im SeaMonkey so. Ist also nichts Neues.

Gruß
Claus

[Claus Reibenstein]

Claus Reibenstein schrieb am 19.08.2022 um 17:10:

> Das war schon (und ist immer noch) im SeaMonkey so. Ist also nichts Neues.

Wahrscheinlich ist das Absicht und soll den User daran erinnern, dass er
schon wieder mal viel zu lange vor dem Bildschirm sitzt und endlich mal
'ne kurze Pause einlegen soll, um sich neuen Kaffee zu besorgen und/oder
den alten zu entsorgen ;-)

SCNR
Claus

[Arno Welzel]

Claus Reibenstein, 2022-08-19 17:10:

"Multithreading not invented here...." ;-)

[Ruediger Lahl]

*Claus Reibenstein* schrieb:

Der Editor ist in TB extrem verbugt. Neben dem hier beschriebenen
Phänomen läst er auch gerne mal getipte Buchstaben aus. Ich kann das
nicht reproduzieren, aber stelle eine gewise Häufung bei
Buchstabenwiederholungen fest, wo dann einer fehlt. Ich habe das in
diesem Absatz mal beispielhaft nachgestelt. :-)

Dazu löscht er auch gerne mal beim Senden Leerzeilen weg.

Hier einigermaßen sicher zu reproduzieren ist, wenn man den Inhalt einer
Zeile im Quote löscht, sie also einfach als Leerzeile nimmt und in der
nächsten Zeile weiter schreibt. Beim Senden wird dann die Leerzeile
gelöscht, aus der man den Text entfernt hatte.

Es gibt noch ein paar schrägere Bugs. Ich muss mir mal die Mühe machen
ihr Verhalten genau zu dokumentieren.

Generell sollte man meinen, dass sie so etwas einfaches wie nen simplen
Texteditor im Griff haben...
--
bis denne

[Jörg Knobloch]

On 19 Aug 2022 15:16, Arno Welzel wrote:
> Wenn ich auf eine Nachricht antworte oder eine neue Nachricht schreibe,
> wird Betterbird (91.12.0-bb35 (64-bit), Windows 10 Pro) zwischendruch
> extrem "zäh". Sowohl im Betreff-Feld als auch im Editor dauert es 1-2
> Sekunden bis die Tastatureingaben auch verarbeitet sind.

Das passiert, wenn neue E-Mail abgerufen wird. Dann stockt der Editor.
Schade, dass das nicht besser gelöst ist. Technische Details, wie man
das in JS besser machen könnte, habe ich ohne Nachforschungen nicht.

> Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
> wieder vorbei. Manchmal dauert es auch länger.

Das könnte die globale Indizierung sein. Habe ich abgeschaltet. Muss Du
mal im Activity Manager gucken, da wird das als Aktivität angezeigt.

--
Viele Grüße, Jörg
Sent with Betterbird. Simply better. www.betterbird.eu

[Claus Reibenstein]

Jörg Knobloch schrieb am 19.08.2022 um 20:38:

> On 19 Aug 2022 15:16, Arno Welzel wrote:
>
>> Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
>> wieder vorbei. Manchmal dauert es auch länger.
>
> Das könnte die globale Indizierung sein.

Wohl kaum.

> Habe ich abgeschaltet.

Eben. Ich auch.

Gruß
Claus

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 19 Aug 2022 15:16, Arno Welzel wrote:

>> Wenn ich auf eine Nachricht antworte oder eine neue Nachricht schreibe,
>> wird Betterbird (91.12.0-bb35 (64-bit), Windows 10 Pro) zwischendruch
>> extrem "zäh". Sowohl im Betreff-Feld als auch im Editor dauert es 1-2
>> Sekunden bis die Tastatureingaben auch verarbeitet sind.

> Das passiert, wenn neue E-Mail abgerufen wird. Dann stockt der Editor.
> Schade, dass das nicht besser gelöst ist. Technische Details, wie man
> das in JS besser machen könnte, habe ich ohne Nachforschungen nicht.

Das Problem an dieser Geschichte ist, dass dieses "Stocken" auch
erheblichen Einfluss auf andere Programme hat. Dieses bedeutet bspw.,
dass in Konstruktionsprogrammen das "Fadenkreuz" plötzlich "hängt".

>> Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
>> wieder vorbei. Manchmal dauert es auch länger.

> Das könnte die globale Indizierung sein. Habe ich abgeschaltet. Muss Du
> mal im Activity Manager gucken, da wird das als Aktivität angezeigt.

Diese ist hier grundsätzlich abgeschaltet.

Thomas 😷
--
== S E N D E Z E I T =================
DATUM : SONNABEND, 20. AUGUST 2022
UHRZEIT: 00:43:17 UHR (MESZ)
== Heute: Tag der Honigbiene =========

[Michael Pachta]

Am 19.08.2022 um 19:56 schrieb Ruediger Lahl:
> Es gibt noch ein paar schrägere Bugs. Ich muss mir mal die Mühe machen
> ihr Verhalten genau zu dokumentieren.

Die Rechtschreibprüfung versagt des Öfteren, d.h. sie tut nichts mehr,
Fehler werden nicht mehr rot unterstrichen. Wobei es sein kann, dass
dies erst auftritt, wenn man eine Rechtschreibprüfung für zwei Sprachen
installiert hat (hier: DE und EN, das Phänomen tritt bei beiden Sprachen
auf).

Drücken von Strg + s (oder klicken auf "Speichern") erweckt sie wieder
zum Leben.

[Joerg Lorenz]

Am 20.08.22 um 08:49 schrieb Michael Pachta:

> Am 19.08.2022 um 19:56 schrieb Ruediger Lahl:
>> Es gibt noch ein paar schrägere Bugs. Ich muss mir mal die Mühe machen
>> ihr Verhalten genau zu dokumentieren.
>
> Die Rechtschreibprüfung versagt des Öfteren, d.h. sie tut nichts mehr,
> Fehler werden nicht mehr rot unterstrichen. Wobei es sein kann, dass
> dies erst auftritt, wenn man eine Rechtschreibprüfung für zwei Sprachen
> installiert hat (hier: DE und EN, das Phänomen tritt bei beiden Sprachen
> auf).

Dann treten die Fehler nicht konsistent auf. Ich habe das noch nie
gesehen und ich habe sogar drei Sprachen installiert (D, E, F). Weder
auf 102 noch auf der 91 und auch auf keinem OS.

> Drücken von Strg + s (oder klicken auf "Speichern") erweckt sie wieder
> zum Leben.

[Jörg Knobloch]

On 20 Aug 2022 08:49, Michael Pachta wrote:
> Die Rechtschreibprüfung versagt des Öfteren, d.h. sie tut nichts mehr,
> Fehler werden nicht mehr rot unterstrichen. Wobei es sein kann, dass
> dies erst auftritt, wenn man eine Rechtschreibprüfung für zwei Sprachen
> installiert hat (hier: DE und EN, das Phänomen tritt bei beiden Sprachen
> auf).
>
> Drücken von Strg + s (oder klicken auf "Speichern") erweckt sie wieder
> zum Leben.

Die Sache ist nicht stabil:
https://bugzilla.mozilla.org/show_bug.cgi?id=1775376
https://bugzilla.mozilla.org/show_bug.cgi?id=1775376#c4
https://bugzilla.mozilla.org/show_bug.cgi?id=1766604#c6

https://www.betterbird.eu/releasenotes/index.html
FIXED - Spellcheck dictionaries not restored when editing draft - Bug
1775376
Ich beobachte das in BB, kann sein, dass es dort auch noch nicht 100%
funktioniert.

Nicht nur "Speichern" sondern auch Wechsel des Fokus auf ein anderes
Fenster und zurück hilft manchmal.

[Helmut Waitzmann]

Ruediger Lahl <ruedig...@gmx.de>:

>Der Editor ist in TB extrem verbugt.
>

[…]

>Dazu löscht er auch gerne mal beim Senden Leerzeilen weg.
>
>Hier einigermaßen sicher zu reproduzieren ist, wenn man den Inhalt
>einer Zeile im Quote löscht, sie also einfach als Leerzeile nimmt
>und in der nächsten Zeile weiter schreibt. Beim Senden wird dann
>die Leerzeile gelöscht, aus der man den Text entfernt hatte.

Schuss ins Blaue:  Tritt das vielleicht
nur dann auf, wenn man Nachrichten im Fließtextformat
(«Content-Type: text/plain; "format=flowed"») verschickt?  Dann
hätte ich einen Verdacht:

Texte im Fließtextformat haben folgende Struktur:

Alle Zeilen innerhalb eines Absatzes müssen dieselbe Quoting‐Tiefe
haben.  Ist das nicht der Fall, hat der Verfasser des Textes einen
Fehler gemacht.  (Newsreader sollten in diesem Fall aber möglichst
sinnvoll handeln.)

Alle Zeilen innerhalb eines Absatzes außer der letzten des Absatzes
erhalten ein Leerzeichen am Zeilenende.  Dadurch erkennt der
Newsreader, dass der Absatz in der nächsten Zeile weiter geht (ich
rücke den Absatz hier nur zur Kenntlichmachung ein):

>Hier ist ein Fließtextabsatz, bestehend aus 3 Zeilen.  Die erste
>Zeile erhält ein Leerzeichen am Zeilenende, ebenso die zweite. 
>Nur die dritte Zeile des Absatzes hat keines am Ende.
>
>Und hier beginnt der nächste Absatz, der auch wieder…


Der empfangende Newsreader, der den Fließtext als Fließtext anzeigen
will, kann folgendermaßen vorgehen:

Bei jeder gequoteten Zeile entfernt er zunächst die Größerzeichen am
Zeilenanfang, merkt sich aber bei jeder Zeile, wie viele es waren. 
Dann geht er vor, wie folgt:

Er liest die erste Zeile des Absatzes.  Er erkennt das Leerzeichen
am Ende.  Deshalb entfernt er den Zeilenvorschub, der nach dem
Leerzeichen folgt.  Er fügt die zweite Zeile (weil der
Zeilenvorschub fehlt) hinten an die erste an.  Er erkennt auch am
Ende der zweiten Zeile das Leerzeichen.  Deshalb entfernt er den
Zeilenvorschub und fügt die dritte Zeile hinten dran.  Die dritte
Zeile hat kein Leerzeichen am Zeilenende.  Das ist im
Fließformattext das Zeichen, dass der Absatz mit dieser Zeile
endet.  Deshalb entfernt der anzeigende Newsreader auch den
Zeilenvorschub nicht.

Jetzt hat der Newsreader eine sehr lange Zeile (mit Zeilenvorschub
am Ende) vorliegen.  Zur Anzeige bricht er sie so neu um, dass die
angezeigten Zeilen nicht zu lang werden, etwa, dass sie höchstens
genau so lang sind, dass sie in der Breite ins Anzeigefenster
passen, oder, dass sie eine vom Anwender festgelegte Länge nicht
überschreiten.

Im einzelnen tut er dabei folgendes:  Er zieht von der in der
Anzeige verfügbaren Zeilenbreite so viel Platz ab, wie er zur
Darstellung der Quote‐Ebenen (dargestellt durch Größerzeichen,
senkrechte Balken, …) braucht.

Er sucht die Zeile von links beginnend, nach Wörtern ab und bestimmt
das erste Wort, das nicht mehr vollständig in die gewünschte
Zeilenlänge passt.  Das Leerzeichen unmittelbar vor diesem Wort
ersetzt er durch einen Zeilenvorschub, stellt an den Anfang der
Zeile die Darstellung der Quote‐Ebenen und bringt dahinter die Zeile
von links beginnend bis einschließlich des Zeilenvorschubs zur
Anzeige.  Dann fährt er mit dem Rest der Zeile ebenso fort und gibt
sie folglich in der nächsten Zeile der Anzeige aus.  Das wiederholt
er, bis das letzte Stück der ehemals langen Zeile so kurz ist, dass
er es nicht mehr teilen muss.  Das gibt er dann auch noch mit seinem
Zeilenvorschub am Ende in die Anzeige.

Dann liest er die leere Zeile, den Absatz von seinem Nachfolger
trennende, Zeile und verfährt wieder entsprechend:  Sie hat kein
Leerzeichen am Zeilenende, ist also gleichzeitig das Ende eines
Absatzes und ist sicherlich auch kurz genug.  Er gibt sie aus.  Dann
geht er zur nächsten Zeile, die einen neuen Absatz beginnt, weiter:


Das angezeigte Ergebnis könnte beispielsweise mit sehr kurzen Zeilen
(Smartphone, …) so aussehen:

>Hier ist ein Fließtextabsatz, bestehend
>aus 3 Zeilen.  Die erste Zeile erhält
>ein Leerzeichen am Zeilenende, ebenso
>die zweite.  Nur die dritte, letzte,
>Zeile des Absatzes hat keines am Ende.

>Und hier beginnt der nächste Absatz, der
>auch wieder…


Jetzt folgt der Fall, bei dem im Absatz die mittlere Zeile geleert
ist:

Wenn man im oben gezeigten Absatz die mittlere Zeile leert und in
der nächsten weiterschreibt (wie oben in der Anleitung beschrieben),
sieht der Text so aus:

>Hier ist ein Fließtextabsatz, bestehend aus 3 Zeilen.  Die erste

Und hier wird weitergeschrieben.
>Nur die dritte Zeile des Absatzes hat keines am Ende.
>
>Und hier beginnt der nächste Absatz, der auch wieder…


Wieder geht der Newsreader des Empfängers so vor, wie oben
beschrieben:

Er liest die erste Zeile, entfernt den Zeilenvorschub und hängt die
zweite, leere, Zeile, die also nur aus einem Zeilenvorschub besteht,
hinten dran.  Die zweite Zeile hat kein Leerzeichen am Zeilenende,
zeigt also das Ende eines Absatzes an.

Der Newsreader sucht wieder das erste Wort, das nicht mehr in die
gewünschte Ausgabebreite passt und ersetzt das davor stehende
Leerzeichen durch einen Zeilenvorschub und gibt die Zeile bis
einschließlich zum Zeilenvorschub aus.  So fährt er fort, bis er zum
Schlussstück, das so kurz ist, dass es nicht mehr zerteilt werden
muss, kommt.  Er gibt es mitsamt seinem Leerzeichen am Ende und dem
Zeilenvorschub aus.

Dann geht er zur dritten Zeile, die den Anfang eines Absatzes
darstellt.  Im Beispiel ist sie so kurz, dass sie in eine
Ausgabezeile passt.  Sie ist gleichzeitig auch das Ende des
Absatzes.

Dann kümmert er sich um die vierte Zeile, die den Anfang eines
neuen zitierten Absatzes darstellt:  Er zerteilt sie und gibt sie
wieder entsprechend aus.  Das Ergebnis könnte so aussehen:

>Hier ist ein Fließtextabsatz, bestehend
>aus 3 Zeilen.  Die erste
Und hier wird weitergeschrieben.
>Nur die dritte Zeile des Absatzes hat
>keines am Ende.

>Und hier beginnt der nächste Absatz, der
>auch wieder…


Entspricht das dem, was du beobachtet hast?  Verräterisch ist das
Leerzeichen am Ende der zweiten Zeile, und, dass die zweite Zeile
(hier zufällig) nicht so lang ist, wie sie sein könnte.

Hier sind also schon vier Absätze entstanden, aber zwischen dem
ersten und dem zweiten gibt es keine Leerzeile.  Und das ist auch
korrekt so, weil im eingetippten Text der erste Absatz erst mit der
Zeile, die kein Leerzeichen am Ende hat, endet.  Das ist in diesem
Fall die zweite, die Leerzeile.  Dadurch wird die Leerzeile Teil des
Absatzes und verschwindet in ihm.

Würdest du mal so ein Beispiel provozieren und posten?  Ich würde
gerne den Quelltext sehen.

[Thomas Barghahn]

*Ruediger Lahl* meinte:

> Generell sollte man meinen, dass sie so etwas einfaches wie nen simplen
> Texteditor im Griff haben..

Bei solch intelligenten Composern steckt oft mehr Hirn drin, als bei
denen, welche generell davon überzeugt sind, es handelt sich ja nur um
einen "simplen Texteditor".

Aber gut - du hast ja auch vor Jahren hier schon erklärt, die Wiederkehr
von "Mnenhy" sei nur eine Frage von Wochen ...

Thomas 😷
--
== S E N D E Z E I T =================
DATUM : SONNABEND, 20. AUGUST 2022

UHRZEIT: 23:03:24 UHR (MESZ)

[Jörg Knobloch]

On 19 Aug 2022 19:56, Ruediger Lahl wrote:
> Hier einigermaßen sicher zu reproduzieren ist, wenn man den Inhalt einer

> nächsten Zeile weiter schreibt. Beim Senden wird dann die Leerzeile
> gelöscht, aus der man den Text entfernt hatte.

Dokumentiere das mal ordentlich. Hier ist kein Problem. Die zweite Zeile
der Quote wurde gelöscht.

[Ingo Steinbuechel]

Hallo Jörg,

"Jörg Knobloch" <jo...@jorgk.com> schrieb:

>> nächsten Zeile weiter schreibt. Beim Senden wird dann die Leerzeile
>> gelöscht, aus der man den Text entfernt hatte.
> Dokumentiere das mal ordentlich. Hier ist kein Problem.

wirklich nicht? Dann schau Dir Deinen eigenen Beitrag noch einmal ganz
genau an. Hier sehe ich zwischen dem Zitat und Deiner Antwort *keine*
Leerzeile.

Gruß Ingo

--
Threema - Sicherer und privater Messenger: https://threema.ch/de
Meine Threema-ID: https://threema.id/ZV9BWDXK
Warum Threema? https://warumthreema.de/

[Jörg Knobloch]

On 19 Aug 2022 19:56, Ruediger Lahl wrote:

> Hier einigermaßen sicher zu reproduzieren ist, wenn man den Inhalt einer

> nächsten Zeile weiter schreibt. Beim Senden wird dann die Leerzeile
> gelöscht, aus der man den Text entfernt hatte.

Wo ist das Problem. Eine Zeile in der quote gelöscht, eine Leerzeile
nach der quote.

[Arno Welzel]

Arno Welzel, 2022-08-19 15:16:

> Gerade erlebe ich einen sehr seltsamen Effekt:
>
> Wenn ich auf eine Nachricht antworte oder eine neue Nachricht schreibe,
> wird Betterbird (91.12.0-bb35 (64-bit), Windows 10 Pro) zwischendruch
> extrem "zäh". Sowohl im Betreff-Feld als auch im Editor dauert es 1-2
> Sekunden bis die Tastatureingaben auch verarbeitet sind.
>
> Das zieht sich dann ca. 30-60 Sekunden lang so hin, dann ist der Spuk
> wieder vorbei. Manchmal dauert es auch länger.
>
> Ist der Effekt bekannt?

Ja, ich habe die Antworten gelesen, dass das immer schon so war etc. pe
pe - so extrem wie es aber hier aktuell ist, habe ich das noch nie
erlebt. Gerade eben hatte ich wieder ca. 5 Minuten, wo das Ding
praktisch komplett unbenutzbar war.

So bringt mit das nichts. Da wechsele ich lieber auf einen anderen Client.

[Jörg Knobloch]

On 21 Aug 2022 14:44, Arno Welzel wrote:
> Ja, ich habe die Antworten gelesen, dass das immer schon so war etc. pe
> pe - so extrem wie es aber hier aktuell ist, habe ich das noch nie
> erlebt. Gerade eben hatte ich wieder ca. 5 Minuten, wo das Ding
> praktisch komplett unbenutzbar war.

Lösche mal global-messages-db.sqlite und lass es über Nacht
reindizieren. Oder schalte es ganz ab.

[Helmut Waitzmann]

Ingo Steinbuechel <schl...@spamfence.net>:

> "Jörg Knobloch" <jo...@jorgk.com> schrieb:
>
>>> nächsten Zeile weiter schreibt. Beim Senden wird dann die
>>> Leerzeile gelöscht, aus der man den Text entfernt hatte.
>> Dokumentiere das mal ordentlich. Hier ist kein Problem.
>>
>
> wirklich nicht? Dann schau Dir Deinen eigenen Beitrag noch einmal
> ganz genau an. Hier sehe ich zwischen dem Zitat und Deiner Antwort
> *keine* Leerzeile.

Die Fehlerbeschreibung war eine andere:  Wenn man im Zitat eine
Zeile leert und nach der geleerten Zeile eine neue aufmacht und mit
eigenem Text füllt, dann passiere es, dass die geleerte Zeile nach
dem Absenden verschwunden ist.

Nicht erwähnt wurde in der Fehlerbeschreibung, ob die Nachricht, auf
die geantwortet wird, im Fließtextformat vorliegt, und auch nicht,
falls das der Fall ist, ob der Abschnitt, in dem eine Zeile geleert
werden wird, ein Fließtextabschnitt ist.  Ebensowenig wurde erwähnt,
ob die Antwort im Fließtextformat verfasst wird, und auch nicht,
falls das der Fall ist, ob die neue Zeile, die gefüllt wird, Teil
eines Fließtextabschnitts wird.

Beispielsweise ist diese Nachricht im Fließtextformat verfasst, und
alle Abschnitte – egal, ob Zitate oder neuer Text, die
Zuschreibungszeilen am Anfang ausgenommen – sind
Fließtextabschnitte.

[Thomas Barghahn]

*Helmut Waitzmann* meinte:

> Ingo Steinbuechel <schl...@spamfence.net>:
>> "Jörg Knobloch" <jo...@jorgk.com> schrieb:

>>>> nächsten Zeile weiter schreibt. Beim Senden wird dann die
>>>> Leerzeile gelöscht, aus der man den Text entfernt hatte.
>>> Dokumentiere das mal ordentlich. Hier ist kein Problem.


>> wirklich nicht? Dann schau Dir Deinen eigenen Beitrag noch einmal
>> ganz genau an. Hier sehe ich zwischen dem Zitat und Deiner Antwort
>> *keine* Leerzeile.

> Die Fehlerbeschreibung war eine andere:  Wenn man im Zitat eine
> Zeile leert und nach der geleerten Zeile eine neue aufmacht und mit
> eigenem Text füllt, dann passiere es, dass die geleerte Zeile nach
> dem Absenden verschwunden ist.

> [...]

> Beispielsweise ist diese Nachricht im Fließtextformat verfasst, und
> alle Abschnitte – egal, ob Zitate oder neuer Text, die
> Zuschreibungszeilen am Anfang ausgenommen – sind
> Fließtextabschnitte.

Oft sind es Antworten auf Fließtexte ("format=flowed"). /DAS/ ist aber
A: nur eine subjektive Einschätzung meinerseits und B: es tritt auch bei
Antworten auf Artikel mit "format=fixed" (Standard) auf. Zudem passiert
es immer dann, wenn man es eigentlich gar nicht gebrauchen kann. ;-)

Wenn man dieses "Phänomen der verlorenen aber gewollten Leerzeilen"
nachstellen möchte, so gelingt es oft auch gar nicht. ;-(
Persönlich wäre ich zumindest an der Ursache dieses Phänomens
interessiert, denn momentan habe ich mich auf eine Arbeitsweise
festgelegt, bei welcher ich alle Quotezeichen stehen lasse (gewollte
Leerzeilen gar mit einem Quotezeichen ">" befülle) und diese dann später
vom Hamster wieder entfernen lasse.

Bei diesem Posting unterlasse ich diese Arbeitsweise einmal - vielleicht
klappt es ja nun mit einer Nachstellung - mal schauen ... ;-)

<https://www.barghahn-online.de/Pictures/tb_text_vor_dem_versenden.png>

Thomas 😷
--
== S E N D E Z E I T ======================
DATUM : SONNTAG, 21. AUGUST 2022
UHRZEIT: 19:57:03 UHR (MESZ)
== Heute: Internationaler Geocaching Tag ==

[Arno Welzel]

Jörg Knobloch, 2022-08-21 17:52:

> On 21 Aug 2022 14:44, Arno Welzel wrote:
>> Ja, ich habe die Antworten gelesen, dass das immer schon so war etc. pe
>> pe - so extrem wie es aber hier aktuell ist, habe ich das noch nie
>> erlebt. Gerade eben hatte ich wieder ca. 5 Minuten, wo das Ding
>> praktisch komplett unbenutzbar war.
>
> Lösche mal global-messages-db.sqlite und lass es über Nacht
> reindizieren. Oder schalte es ganz ab.

Prinzipiell nutze ich die globale Suche ja auch, deshalb ist das schon
ok, wenn ein Index angelegt wird.

Ich habe die Ursache auch gefunden - in einem Unterordner eines
IMAP-Accounts sind durch einen Fehler eines Systems (nein, nicht von
mir) in den letzten 3 Tage ca. 35000 Mails eingetroffen. Die habe ich
mittlerweile auf dem Server gelöscht und jetzt läuft es auch wieder.

[Thomas Barghahn]

*Thomas 'Ingrid' Barghahn* meinte:

> [...]

> Bei diesem Posting unterlasse ich diese Arbeitsweise einmal - vielleicht
> klappt es ja nun mit einer Nachstellung - mal schauen ... ;-)

Schade, es hat nicht geklappt. :-( Man müsste sich zu diesem speziellen
Thema einmal in einer Testgruppe verabreden. Zudem wird es Zeit brauchen
um diesem "Phänomen" gezielt "auf dem Pelz zu rücken".

Thomas 😷
--
== S E N D E Z E I T ======================
DATUM : SONNTAG, 21. AUGUST 2022

UHRZEIT: 20:47:04 UHR (MESZ)

[Jörg Knobloch]

On 19 Aug 2022 19:56, Ruediger Lahl wrote:

> Hier einigermaßen sicher zu reproduzieren ist, wenn man den Inhalt einer

Hier neuer Text.

> nächsten Zeile weiter schreibt. Beim Senden wird dann die Leerzeile
> gelöscht, aus der man den Text entfernt hatte.

Also, die Original-Beschreibung war für mich leider unverständlich. Ich
habe jetzt eine Zeile leer gemacht, danach eine neue eingefügt.

[Jörg Knobloch]

On 21 Aug 2022 20:45, Arno Welzel wrote:
> ... und jetzt läuft es auch wieder.

Schön, dass es wieder geht.

TB zu ersetzen ist nicht einfach, deshalb habe ich BB gestartet. Alles
andere, was so am Markt ist, hat nur ein Bruchteil der Funktionalität.

[Tilmann Reh]

Am 21.08.2022 um 19:57 schrieb Thomas Barghahn:
> Wenn man dieses "Phänomen der verlorenen aber gewollten Leerzeilen"
> nachstellen möchte, so gelingt es oft auch gar nicht. ;-(
> Persönlich wäre ich zumindest an der Ursache dieses Phänomens
> interessiert, denn momentan habe ich mich auf eine Arbeitsweise
> festgelegt, bei welcher ich alle Quotezeichen stehen lasse (gewollte
> Leerzeilen gar mit einem Quotezeichen ">" befülle) und diese dann später
> vom Hamster wieder entfernen lasse.

Ich beobachte das auch schon seit langem. Und habe den Eindruck, daß der
Editor manchmal Leerzeilen, die man unmittelbar nach dem Zitat vor dem
eigenen Absatz einfügt, noch dem vorher zitierten Block zuordnet und
dann beim Senden "wegoptimiert". Die verschwundenen Leerzeilen sind
nahezu immer die zwischen dem Zitat und dem neuen, eigenen Text.

Man kann (meistens...) die Zuordnung an der Farbe des Textcursors
erkennen. Ist der noch blau, befindet man sich für den Editor noch im
Zitat. Ist er schwarz, im neuen Text.

Seit ich bewußt darauf achte, daß der Cursor am Anfang der Leerzeile
nach einem Zitat schwarz ist (notfalls noch eine weitere Leerzeile
einfügen und die erste löschen) gibt es deutlich weniger beim Senden
verschluckte Leerzeilen - allerdings kommt das trotzdem noch immer mal
wieder vor... :-\

Tilmann

P.S. ui.caretWidth=2 macht den Cursor und dessen Farbe besser sichtbar.

[Jörg Knobloch]

On 21 Aug 2022 21:23, Tilmann Reh wrote:
> Ich beobachte das auch schon seit langem.

Dann sollte mal jemand die Schritte genau aufschreiben.

Mit Add-on ThunderHTMLedit kann man sehen, welches HTML man gerade im
Editor hat, und ja, plaintext ist auch HTML hinter den Kulissen.

[Tilmann Reh]

Am 21.08.2022 um 21:53 schrieb Jörg Knobloch:
> On 21 Aug 2022 21:23, Tilmann Reh wrote:
>> Ich beobachte das auch schon seit langem.
>
> Dann sollte mal jemand die Schritte genau aufschreiben.
>
> Mit Add-on ThunderHTMLedit kann man sehen, welches HTML man gerade im
> Editor hat, und ja, plaintext ist auch HTML hinter den Kulissen.

Danke für den Hinweis, ich sehe mir das einmal näher an.

Tilmann

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 21 Aug 2022 21:23, Tilmann Reh wrote:

>> Ich beobachte das auch schon seit langem.

> Dann sollte mal jemand die Schritte genau aufschreiben.

> Mit Add-on ThunderHTMLedit kann man sehen, welches HTML man gerade im
> Editor hat, und ja, plaintext ist auch HTML hinter den Kulissen.

Vielen Dank(!), dieses "Teil" könnte bei dem "Aufspüren" des genannten
Problems tatsächlich eine große Hilfe sein. :-)

Schauen wir einmal ... :-)

Thomas 😷
--
== S E N D E Z E I T ======================
DATUM : SONNTAG, 21. AUGUST 2022

UHRZEIT: 22:44:29 UHR (MESZ)

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 21 Aug 2022 21:23, Tilmann Reh wrote:

>> Ich beobachte das auch schon seit langem.

> Dann sollte mal jemand die Schritte genau aufschreiben.

> Mit Add-on ThunderHTMLedit kann man sehen, welches HTML man gerade im
> Editor hat, und ja, plaintext ist auch HTML hinter den Kulissen.

Es gibt Neuigkeiten! :-) Das "Phänomen der verschwundenen Leerzeile
(folgend LZ)" kann jetzt zu jeder Zeit und beliebig oft nachvollzogen
werden. In Worten kann man es nicht wirklich gut beschreiben, daher wird
nun jeder Schritt mit einem Bild versehen.

Bild_1:
Wir haben einen Artikel vor uns, welchen wir beantworten möchten.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_1.png>

Bild_2:
Wir öffnen den Composer mit "Newsgruppe antworten".
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_2.png>

Bild_3:
Wir markieren die Passagen des Textes, welche uninteressant sind.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_3.png>

Bild_4:
Wir eliminieren die markierten Zeilen. *Danach* steht der Cursor (blau)
in einer leeren *aber noch gequoteten* Zeile.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_4.png>

Bild_5:
Wir bewegen den Cursor (ohne etwas zu löschen) eine Zeile tiefer (der
Cursor wird schwarz) und schreiben unseren Text.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_5.png>

Bild_6:
Nun stört uns noch die gequotete Zeile und wir setzen den Cursor in
jener Zeile hinter "> " (greater than & space); der Cursor wird blau.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_6.png>

Bild_7:
Jetzt drücken wir - obwohl nur zwei Zeichen in jener Zeile vorhanden
sind - *dreimal* [BackSpace]! Wir landen mit dem Cursor in der letzten
gequoteten Zeile und unser geschriebener Text rückt nach! Der Cursor ist
am Ende dieser Zeile jetzt blau.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_7.png>

Bild_8:
Wir bemerken unser Missgeschick (*dreimal* [BackSpace]) und drücken
*einmal* [Return]! Der Cursor färbt sich jetzt schwarz! Unser
geschriebener Text steht nun dort, wo wir ihn gerne hätten und eine
Leerzeile wurde wieder eingefügt.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_8.png>

Bild_9:
Wir drücken erneut - warum auch immer - *einmal* [BackSpace]!
*Es passiert nichts auf dem Bildschirm*! Nur in dem weiter oben
genannten Tool "ThunderHTMLedit" verschwindet ein <br> (Break)!
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_9.png>

Bild_10:
Wir versenden unsere Nachricht und betrachte diese nun.
*Es fehlt eine Leerzeile* zwischen dem gequoteten Text und dem Text,
welchen wir geschrieben haben.
<https://www.barghahn-online.de/Pictures/tb_LZ_weg_10.png>

-----

Dieses Szenario ist zu jeder Zeit und immer wieder nachvollziehbar.
Auch mein Test wird jetzt genau und ohne Leerzeile unter dem Zitat von
Jörg "kleben". ;-)

Vielen Dank(!) für eure Aufmerksamkeit! :-)

Thomas 😷
--
== S E N D E Z E I T ==============

DATUM : MONTAG, 22. AUGUST 2022
UHRZEIT: 03:36:59 UHR (MESZ)
== Heute: Tag der Fische ==========

[Ruediger Lahl]

*Tilmann Reh* schrieb:

> Am 21.08.2022 um 19:57 schrieb Thomas Barghahn:
>> Wenn man dieses "Phänomen der verlorenen aber gewollten Leerzeilen"
>> nachstellen möchte, so gelingt es oft auch gar nicht. ;-(
>> Persönlich wäre ich zumindest an der Ursache dieses Phänomens
>> interessiert, denn momentan habe ich mich auf eine Arbeitsweise
>> festgelegt, bei welcher ich alle Quotezeichen stehen lasse (gewollte
>> Leerzeilen gar mit einem Quotezeichen ">" befülle) und diese dann später
>> vom Hamster wieder entfernen lasse.
>
> Ich beobachte das auch schon seit langem. Und habe den Eindruck, daß der
> Editor manchmal Leerzeilen, die man unmittelbar nach dem Zitat vor dem
> eigenen Absatz einfügt, noch dem vorher zitierten Block zuordnet und
> dann beim Senden "wegoptimiert". Die verschwundenen Leerzeilen sind
> nahezu immer die zwischen dem Zitat und dem neuen, eigenen Text.

Beliebt ist auch, dass er beim Senden noch das eine Wort, das er am Ende
des Textes noch in eine neue Zeile schrieb, doch noch an die Zeile davor
anfügt.

> Seit ich bewußt darauf achte, daß der Cursor am Anfang der Leerzeile
> nach einem Zitat schwarz ist (notfalls noch eine weitere Leerzeile
> einfügen und die erste löschen) gibt es deutlich weniger beim Senden
> verschluckte Leerzeilen - allerdings kommt das trotzdem noch immer mal
> wieder vor... :-\

Ähnlich hier. Ich lösche die Leerzeile und setze sie mit Enter neu. Dann
klappts.
--
bis denne

[Tilmann Reh]

Am 22.08.2022 um 06:27 schrieb Ruediger Lahl:
> Beliebt ist auch, dass er beim Senden noch das eine Wort, das er am Ende
> des Textes noch in eine neue Zeile schrieb, doch noch an die Zeile davor
> anfügt.

Ja, stimmt...

>> Seit ich bewußt darauf achte, daß der Cursor am Anfang der Leerzeile
>> nach einem Zitat schwarz ist (notfalls noch eine weitere Leerzeile
>> einfügen und die erste löschen) gibt es deutlich weniger beim Senden
>> verschluckte Leerzeilen - allerdings kommt das trotzdem noch immer mal
>> wieder vor... :-\
>
> Ähnlich hier. Ich lösche die Leerzeile und setze sie mit Enter neu. Dann
> klappts.

Jedenfalls meistens... :-)

Tilmann

[Tilmann Reh]

Am 22.08.2022 um 03:36 schrieb Thomas Barghahn:
> Es gibt Neuigkeiten! :-) Das "Phänomen der verschwundenen Leerzeile
> (folgend LZ)" kann jetzt zu jeder Zeit und beliebig oft nachvollzogen
> werden. In Worten kann man es nicht wirklich gut beschreiben, daher wird
> nun jeder Schritt mit einem Bild versehen.

> [...]

Möglicherweise geht das auch mit (etwas) weniger Schritten... :-)

Trotzdem gut, den Effekt reproduzierbar zu haben - das bringt die
Entwickler einer Lösung auf jeden Fall erheblich näher.

Danke,
Tilmann

[Jörg Knobloch]

On 22 Aug 2022 03:36, Thomas Barghahn wrote:
> Bild_9:

> Wir drücken erneut - warum auch immer -*einmal* [BackSpace]!

> *Es passiert nichts auf dem Bildschirm*! Nur in dem weiter oben
> genannten Tool "ThunderHTMLedit" verschwindet ein <br> (Break)!
> <https://www.barghahn-online.de/Pictures/tb_LZ_weg_9.png>

Das ist offensichtlich ein Bug, ein Tastenanschlag sollte etwas
bewirken, was auch sichtbar ist. Offenbar wird das <br> entfernt und das
fehlt dann in der gesendeten Nachricht. Ein typisches Mozilla Editor
Problem. Müsste man mal in einen <div contenteditable=true> in Firefox
nachstellen, um die Mozilla-Leute daran zu interessieren.

[Helmut Waitzmann]

Thomas Barghahn <Th.Ba...@t-online.de>:

Das dürfte wohl ein Bedienfehler sein.  Besser wäre es
wahrscheinlich, sich anzugewöhnen, zum Leeren von Zeilen nicht ein
paar Mal (aus Versehen einmal zu viel) [BackSpace], sondern statt
dessen [Home] [Shift]-[End] [Del] (oder auch umgekehrt [End]
[Shift]-[Home] [Del]) zu drücken:  Da muss man nicht zuschauen und
mitzählen, wie oft genau man die Taste zum Löschen drücken muss: 
Man drückt jede Taste genau einmal, egal, wie lang der Text in der
zu leerenden Zeile ist.

>
>Bild_8:
>Wir bemerken unser Missgeschick (*dreimal* [BackSpace]) und drücken
>*einmal* [Return]! Der Cursor färbt sich jetzt schwarz! Unser
>geschriebener Text steht nun dort, wo wir ihn gerne hätten und eine
>Leerzeile wurde wieder eingefügt.
><https://www.barghahn-online.de/Pictures/tb_LZ_weg_8.png>
>
>Bild_9:
>Wir drücken erneut - warum auch immer - *einmal* [BackSpace]!
>*Es passiert nichts auf dem Bildschirm*! Nur in dem weiter oben
>genannten Tool "ThunderHTMLedit" verschwindet ein <br> (Break)!
><https://www.barghahn-online.de/Pictures/tb_LZ_weg_9.png>

Das ist ein ähnlicher Bedienfehler wie der von Bild_7.

>
>Bild_10:
>Wir versenden unsere Nachricht und betrachte diese nun.
>
>*Es fehlt eine Leerzeile* zwischen dem gequoteten Text und dem
>Text, welchen wir geschrieben haben.
><https://www.barghahn-online.de/Pictures/tb_LZ_weg_10.png>

(Ich sehe in der Abbildung eine halbe Leerzeile zwischen dem Zitat
und dem selbstgeschriebenen Text.)

>
>-----
>
>Dieses Szenario ist zu jeder Zeit und immer wieder nachvollziehbar.
>
>Auch mein Test wird jetzt genau und ohne Leerzeile unter dem Zitat
>von Jörg "kleben". ;-)

Ja, das tut er.  Vielen Dank für deine Untersuchung und die
Schritt‐für‐Schritt‐Anleitung, den Effekt zu provozieren!

Müssen zwingend beide Bedienfehler gemacht werden, um den Test zum
«Erfolg» zu bringen?

Oder funktioniert der Test auch, wenn man nur den Bedienfehler von
Bild_7 und die Korrektur von Bild_8 macht? 

Oder funktioniert der Test auch, wenn man nur den Bedienfehler von
Bild_9 macht?

(Ich habe im Moment keinen Thunderbird installiert, deshalb kann ich
das nicht selber probieren.  Aber vielleicht helfen diese Fragen,
die Ursache weiter einzugrenzen?)

Das Verhalten des Thunderbirds in Bild 9 ist jedenfalls ein Defekt: 
Der Thunderbird darf dem Anwender nicht einfach erlauben, dass der
mit der [Backspace]‐ oder der [Del]‐Taste Textstruktur, also
Zitatebenengrenzen oder Fließtextabschnittsgrenzen,
strukturzerstörend löscht.

Entweder, der Thunderbird lässt bei der Operation von Bild_9 das
<br» stehen, auch wenn er anfängt, von hinten ins Zitat
hineinzulöschen, oder, er verbietet dem Anwender gleich von
vorneherein, das zu tun, etwa, indem er das <br> stehen lässt,
nichts löscht, aber (einstellbar:) hupt.  Eventuell wäre da auch ein
aufpoppender Tooltipp mit der Erklärung, dass man am Ende des
vorangehenden Abschnitts nur löschen kann, indem die Schreibmarke in
den Abschnitt (auch am Zeilenende der letzten Zeile des Abschnitts
möglich) positioniert, angebracht?

Zitatebenen‐ oder Fließtextabschnitt‐Grenzen sollte der Anwender
nicht einfach durch bloßes Drücken der [Backspace]‐ oder [Del]‐Taste
löschen können.

Das würde solche überraschenden Fehlbedienungen verhindern.

[Jörg Knobloch]

On 22 Aug 2022 10:12, Jörg Knobloch wrote:
> Ein typisches Mozilla Editor Problem. Müsste man mal in einen <div
> contenteditable=true> in Firefox nachstellen, um die Mozilla-Leute daran
> zu interessieren.

Habe ich mal probiert. Das Problem ist, dass wenn an <Enter> hinter der
Zeile mit "> " drückt, der Mozilla Editor speziellen "Mail"-Code
ausführt, der in Firefox alleine nicht läuft. Ich habe daran früher mal
gearbeitet:
https://bugzilla.mozilla.org/show_bug.cgi?id=1330796
(wurde aber zwischenzeitlich komplett ersetzt, s.u.).

Referenzen:
https://searchfox.org/mozilla-central/rev/9cd1e8cabf67ef5a47e95d70b7f40c9d3ad02ad0/editor/libeditor/HTMLEditSubActionHandler.cpp#2248

https://bugzilla.mozilla.org/show_bug.cgi?id=1761395#c17

So was können nur Spezialisten reparieren, die eigentlich hohe
Tagessätze berechnen sollten, wenn sie nicht aus Liebe zur Sache umsonst
arbeiten (und sich dann noch herber Kritik aussetzen).

[Thomas Barghahn]

*Tilmann Reh* meinte:

> Am 22.08.2022 um 03:36 schrieb Thomas Barghahn:

>> Es gibt Neuigkeiten! :-) Das "Phänomen der verschwundenen Leerzeile
>> (folgend LZ)" kann jetzt zu jeder Zeit und beliebig oft nachvollzogen
>> werden. In Worten kann man es nicht wirklich gut beschreiben, daher wird
>> nun jeder Schritt mit einem Bild versehen.
>> [...]

> Möglicherweise geht das auch mit (etwas) weniger Schritten... :-)

Ja natürlich(!) - einfach nur den Inhalt des Tools "ThunderHTMLedit"
beobachten. In jenem wird jeder Schritt bis ins Detail aufgezeich-
net. ;-)

BTW:
Man sieht auch in diesem Zusammenhang, wie komplex und "intelligent" die
Composer von Mail- und Newsreadern sind und auch sein müssen.

Es handelt sich also *keinesfalls* um "simple Texteditoren", wie sie von
manchen Usern hier genannt werden.

Thomas 😷
--
== S E N D E Z E I T ==============
DATUM : MONTAG, 22. AUGUST 2022

UHRZEIT: 12:30:58 UHR (MESZ)

[Franklin Schiftan]

Am 2022-08-22 um 12:30 schrieb Thomas Barghahn:
> *Tilmann Reh* meinte:
>> Am 22.08.2022 um 03:36 schrieb Thomas Barghahn:
>
>>> Es gibt Neuigkeiten! :-) Das "Phänomen der verschwundenen Leerzeile
>>> (folgend LZ)" kann jetzt zu jeder Zeit und beliebig oft nachvollzogen
>>> werden. In Worten kann man es nicht wirklich gut beschreiben, daher wird
>>> nun jeder Schritt mit einem Bild versehen.
>>> [...]
>
>> Möglicherweise geht das auch mit (etwas) weniger Schritten... :-)
>
> Ja natürlich(!) - einfach nur den Inhalt des Tools "ThunderHTMLedit"
> beobachten. In jenem wird jeder Schritt bis ins Detail aufgezeich-
> net. ;-)
>
> BTW:
> Man sieht auch in diesem Zusammenhang, wie komplex und "intelligent" die
> Composer von Mail- und Newsreadern sind und auch sein müssen.

Was allerdings nur auf HTML-Code zutrifft ...

> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie sie von
> manchen Usern hier genannt werden.

Wenn sie von Plaintext-Mails ausgehen, dürfte diese Kategorisierung gar
nicht mal so unrichtig sein.

> Thomas 😷

.... und tschüss

Franklin

[Thomas Barghahn]

*Franklin Schiftan* meinte:

> Am 2022-08-22 um 12:30 schrieb Thomas Barghahn:

>> BTW:
>> Man sieht auch in diesem Zusammenhang, wie komplex und "intelligent" die
>> Composer von Mail- und Newsreadern sind und auch sein müssen.

> Was allerdings nur auf HTML-Code zutrifft ...

Das ist so nicht richtig. Siehe weiter unten. Zudem kannst du es selber
mit dem Tool "ThunderHTMLedit" im Plain-Text-Composer verfolgen.

>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie sie von
>> manchen Usern hier genannt werden.

> Wenn sie von Plaintext-Mails ausgehen, dürfte diese Kategorisierung gar
> nicht mal so unrichtig sein.

Nun, lies noch einmal den Satz von Jörg K. sehr aufmerksam:

| Mit Add-on ThunderHTMLedit kann man sehen, welches HTML man gerade im
| Editor hat, und ja, plaintext ist auch HTML hinter den Kulissen.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ansonsten wäre mir die Aufzeichnung auch gar nicht gelungen, denn ich
benutze HTML nie.

Thomas 😷
--
== S E N D E Z E I T ==============
DATUM : MONTAG, 22. AUGUST 2022

UHRZEIT: 14:07:26 UHR (MESZ)

[Tilmann Reh]

Am 22.08.2022 um 10:21 schrieb Helmut Waitzmann:
> Thomas Barghahn <Th.Ba...@t-online.de>:

>>Jetzt drücken wir - obwohl nur zwei Zeichen in jener Zeile
>>vorhanden sind - *dreimal* [BackSpace]! Wir landen mit dem Cursor
>>in der letzten gequoteten Zeile und unser geschriebener Text rückt
>>nach! Der Cursor ist am Ende dieser Zeile jetzt blau.
>><https://www.barghahn-online.de/Pictures/tb_LZ_weg_7.png>
>
> Das dürfte wohl ein Bedienfehler sein.  Besser wäre es
> wahrscheinlich, sich anzugewöhnen, zum Leeren von Zeilen nicht ein
> paar Mal (aus Versehen einmal zu viel) [BackSpace], sondern statt
> dessen [Home] [Shift]-[End] [Del] (oder auch umgekehrt [End]
> [Shift]-[Home] [Del]) zu drücken:  Da muss man nicht zuschauen und
> mitzählen, wie oft genau man die Taste zum Löschen drücken muss: 
> Man drückt jede Taste genau einmal, egal, wie lang der Text in der
> zu leerenden Zeile ist.

Ich edititiere die Nachrichten beim Antworten anders (ich füge
Leerzeilen und gleich danach den eigenen Text ein, indem ich am Ende der
letzten zitierten Zeile 2x Enter drücke). Dann habe ich noch gar nichts
gelöscht. Trotzdem ist manchmal der Cursor in der Leerzeile noch blau
und diese Leerzeile wird dann später beim Senden entfernt.

>>*Es fehlt eine Leerzeile* zwischen dem gequoteten Text und dem
>>Text, welchen wir geschrieben haben.
>><https://www.barghahn-online.de/Pictures/tb_LZ_weg_10.png>
>
> (Ich sehe in der Abbildung eine halbe Leerzeile zwischen dem Zitat
> und dem selbstgeschriebenen Text.)

Das ist etwas anderes. Wenn man die Zitatmarkierungen als durchgehende
Linien anzeigen läßt, werden hier zusätzliche Abstände eingefügt. Für
jede Zitatebene etwas mehr.

Tilmann

[Franklin Schiftan]

Am 2022-08-22 um 14:07 schrieb Thomas Barghahn:
> *Franklin Schiftan* meinte:
>> Am 2022-08-22 um 12:30 schrieb Thomas Barghahn:
>
>>> BTW:
>>> Man sieht auch in diesem Zusammenhang, wie komplex und "intelligent" die
>>> Composer von Mail- und Newsreadern sind und auch sein müssen.
>
>> Was allerdings nur auf HTML-Code zutrifft ...
>
> Das ist so nicht richtig. Siehe weiter unten. Zudem kannst du es selber
> mit dem Tool "ThunderHTMLedit" im Plain-Text-Composer verfolgen.
>
>>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie sie von
>>> manchen Usern hier genannt werden.
>
>> Wenn sie von Plaintext-Mails ausgehen, dürfte diese Kategorisierung gar
>> nicht mal so unrichtig sein.
>
> Nun, lies noch einmal den Satz von Jörg K. sehr aufmerksam:
>
> | Mit Add-on ThunderHTMLedit kann man sehen, welches HTML man gerade im

> | Editor hat, und ja, plaintext ist auch HTML hinter den Kulissen > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ach so, ja, muss ich wohl irgendwie etwas verdrängt haben ...

[Helmut Waitzmann]

Franklin Schiftan <fraschi...@arcor.de>:

>Am 2022-08-22 um 12:30 schrieb Thomas Barghahn:
>>
>> Ja natürlich(!) - einfach nur den Inhalt des Tools
>> "ThunderHTMLedit" beobachten. In jenem wird jeder Schritt bis ins

>> Detail aufgezeichnet. ;-)

>>
>> BTW:
>> Man sieht auch in diesem Zusammenhang, wie komplex und
>> "intelligent" die Composer von Mail- und Newsreadern sind und
>> auch sein müssen.
>
>Was allerdings nur auf HTML-Code zutrifft ...
>
>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>> sie von manchen Usern hier genannt werden.
>
>Wenn sie von Plaintext-Mails ausgehen, dürfte diese Kategorisierung
>gar nicht mal so unrichtig sein.
>

Na, dann können «sie» oder du ja kurz beschreiben, was ich erhalte,
wenn ich beim Verfassen dieser Fließtextnachricht hier in dem im
folgenden nochmals zitierten Ausschnitt …

>> BTW:
>> Man sieht auch in diesem Zusammenhang, wie komplex und
>> "intelligent" die Composer von Mail- und Newsreadern sind und
>> auch sein müssen.
>
>Was allerdings nur auf HTML-Code zutrifft ...
>
>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>> sie von manchen Usern hier genannt werden.

… die Schreibmarke hinter das ">"‐Zeichen in der drittletzten Zeile
stelle und so lang die [Backspace]‐Taste wiederholt drücke, bis die
Schreibmarke hinter das Satzende "müssen." in der dritten Zeile
gelangt ist:


Erhalte ich folgendes?

>> BTW:
>> Man sieht auch in diesem Zusammenhang, wie komplex und
>> "intelligent" die Composer von Mail- und Newsreadern sind und
>> auch sein müssen.

>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>> sie von manchen Usern hier genannt werden.

Oder erhalte ich folgendes?

>> BTW:
>> Man sieht auch in diesem Zusammenhang, wie komplex und
>> "intelligent" die Composer von Mail- und Newsreadern sind und
>> auch sein müssen.

>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>> sie von manchen Usern hier genannt werden.

Leser, die ihren Newsreader (beispielsweise ihren Thunderbird) so
eingestellt haben, dass er Fließtext verarbeitet, werden den
Unterschied sehen:  Im ersten Fall löscht das wiederholte Betätigen
der [Backspace]‐Taste die Abschnittsgrenzen weg und beide
">>"‐Zitate verschmelzen.  Im zweiten Fall bleibt die
Abschnittsgrenze stehen und beide ">>"‐Zitate bleiben getrennte
Abschnitte, obwohl sie ohne Leerzeile hinter einander folgen.

Welche von beiden Vorgehensweisen ist für einen «simplen Texteditor»
nun die richtige?  Nur, damit keine Missverständnisse aufkommen: 
Diese Nachricht ist Plaintext im Fließtext‐Format: «Content-Type:
text/plain; format=flowed».

[Franklin Schiftan]

Weder, noch (ganz abgesehen davon, dass ich keinen Unterschied sehe),
sondern:

>>> BTW:
>>> Man sieht auch in diesem Zusammenhang, wie komplex und
>>> "intelligent" die Composer von Mail- und Newsreadern sind und
>>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...
>>
>>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>>> sie von manchen Usern hier genannt werden.

> Leser, die ihren Newsreader (beispielsweise ihren Thunderbird) so
> eingestellt haben, dass er Fließtext verarbeitet, werden den
> Unterschied sehen:  Im ersten Fall löscht das wiederholte Betätigen
> der [Backspace]‐Taste die Abschnittsgrenzen weg und beide
> ">>"‐Zitate verschmelzen.  Im zweiten Fall bleibt die
> Abschnittsgrenze stehen und beide ">>"‐Zitate bleiben getrennte
> Abschnitte, obwohl sie ohne Leerzeile hinter einander folgen.

Hmm, aber ist das eigentlich nicht völlig egal, bzw. ein Streit um des
Kaisers Bart? Weil, üblicherweise bearbeite ich doch meine Beiträge im
Zweifelsfall solange, bis sie so aussehen, wie ich mir das vorstelle. Ob
nun mit Backspace oder Enter oder wie auch immer ...

.... und tschüss

Franklin

[Michael Pachta]

Am 22.08.2022 um 16:30 schrieb Helmut Waitzmann:
> Leser, die ihren Newsreader (beispielsweise ihren Thunderbird) so
> eingestellt haben, dass er Fließtext verarbeitet, werden den
> Unterschied sehen:  Im ersten Fall löscht das wiederholte Betätigen
> der [Backspace]‐Taste die Abschnittsgrenzen weg und beide
> ">>"‐Zitate verschmelzen.  Im zweiten Fall bleibt die
> Abschnittsgrenze stehen und beide ">>"‐Zitate bleiben getrennte
> Abschnitte, obwohl sie ohne Leerzeile hinter einander folgen.
>
> Welche von beiden Vorgehensweisen ist für einen «simplen Texteditor»
> nun die richtige?  Nur, damit keine Missverständnisse aufkommen: 
> Diese Nachricht ist Plaintext im Fließtext‐Format: «Content-Type:
> text/plain; format=flowed».

Interessanterweise sehe ich einen Bug in deinem Posting. Nach jedem
Punkt am Satzende macht dein Newsreader fälschlicherweise zwei
Leerzeichen hin anstelle des korrekten einen. Nach einem Doppelpunkt
macht er das auch. Hast du das mal untersucht?

[Thomas Barghahn]

*Michael Pachta* meinte:

> Am 22.08.2022 um 16:30 schrieb Helmut Waitzmann:

>> [...]

>> Welche von beiden Vorgehensweisen ist für einen «simplen Texteditor»
>> nun die richtige?  Nur, damit keine Missverständnisse aufkommen: 
>> Diese Nachricht ist Plaintext im Fließtext‐Format: «Content-Type:
>> text/plain; format=flowed».

> Interessanterweise sehe ich einen Bug in deinem Posting. Nach jedem
> Punkt am Satzende macht dein Newsreader fälschlicherweise zwei
> Leerzeichen hin anstelle des korrekten einen. Nach einem Doppelpunkt
> macht er das auch. Hast du das mal untersucht?

Das ist gar ein geschütztes Leerzeichen (0xA0) und ein Leerzeichen
(0x20). Was das soll, das habe ich auch noch nicht verstanden.
Nun ja ... - muss man denn auch alles verstehen(?) ... ;-)

Thomas 😷
--
== S E N D E Z E I T ==============
DATUM : MONTAG, 22. AUGUST 2022

UHRZEIT: 19:23:20 UHR (MESZ)

[Helmut Waitzmann]

Franklin Schiftan <fraschi...@arcor.de>:
>Am 2022-08-22 um 16:30 schrieb Helmut Waitzmann:
>> Franklin Schiftan <fraschi...@arcor.de>:
>>> Am 2022-08-22 um 12:30 schrieb Thomas Barghahn:
>
>> Na, dann können «sie» oder du ja kurz beschreiben, was ich erhalte,
>> wenn ich beim Verfassen dieser Fließtextnachricht hier in dem im
>> folgenden nochmals zitierten Ausschnitt …
>>
>>>> BTW:
>>>> Man sieht auch in diesem Zusammenhang, wie komplex und
>>>> "intelligent" die Composer von Mail- und Newsreadern sind und
>>>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...

Was ist denn da passiert?  Wo ist im vorstehenden Zitat das
Abschnittsende hinter «auch sein müssen» geblieben?  Und warum ist
der daran anschließende Satz in die Zitat‐Ebene mit hineingerutscht?

>>>
>>>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>>>> sie von manchen Usern hier genannt werden.
>>
>> … die Schreibmarke hinter das ">"‐Zeichen in der drittletzten Zeile
>> stelle und so lang die [Backspace]‐Taste wiederholt drücke, bis die
>> Schreibmarke hinter das Satzende "müssen." in der dritten Zeile
>> gelangt ist:
>>
>>
>> Erhalte ich folgendes?
>>
>>
>>>> BTW:
>>>> Man sieht auch in diesem Zusammenhang, wie komplex und
>>>> "intelligent" die Composer von Mail- und Newsreadern sind und
>>>> auch sein müssen.
>>>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>>>> sie von manchen Usern hier genannt werden.
>>
>>
>> Oder erhalte ich folgendes?
>>
>>
>>>> BTW:
>>>> Man sieht auch in diesem Zusammenhang, wie komplex und
>>>> "intelligent" die Composer von Mail- und Newsreadern sind und
>>>> auch sein müssen.
>>>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>>>> sie von manchen Usern hier genannt werden.
>
>Weder, noch (ganz abgesehen davon, dass ich keinen Unterschied
>sehe),

Hast du vielleicht die Fließtextdarstellung (beim Nachrichtenlesen)
abgestellt und nur die Fließtexterzeugung (beim
Nachrichtenschreiben) eingeschaltet?  Deine Nachricht ist jedenfalls
im Fließtextformat, hat aber alle Zitate ins Festtextformat
konvertiert.  Das hat dann auch zur Folge, dass die beiden
Ausschnitte, wie du bemerkt hast, gleich aussehen.

>sondern:
>
>>>> BTW:
>>>> Man sieht auch in diesem Zusammenhang, wie komplex und
>>>> "intelligent" die Composer von Mail- und Newsreadern sind und
>>>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...
>>>
>>>> Es handelt sich also *keinesfalls* um "simple Texteditoren", wie
>>>> sie von manchen Usern hier genannt werden.

Du hast also die Schreibmarke hinter das über der Zeile «Es handelt
sich also…» sich befindende «>» gestellt und mit der
[Backspace]‐Taste bis zum Ende des Satzes, der mit «auch sein
müssen.» endet, gelöscht?

Wie kommt es dann, dass der Text «Was allerdings nur auf HTML-Code
zutrifft ...» jetzt doch noch zu lesen ist?  Ist er wie von
Geisterhand nach dem Versenden wieder aufgetaucht?  (Das sind keine
rhetorischen Fragen, sondern ernst gemeint:  Einem Editor, der
anscheinend manche Zeilenvorschübe frisst, der könnte auch bereits
gelöschten Text wie von Geisterhand wieder einfügen.)

>
>> Leser, die ihren Newsreader (beispielsweise ihren Thunderbird) so
>> eingestellt haben, dass er Fließtext verarbeitet, werden den
>> Unterschied sehen:  Im ersten Fall löscht das wiederholte Betätigen
>> der [Backspace]‐Taste die Abschnittsgrenzen weg und beide
>> ">>"‐Zitate verschmelzen.  Im zweiten Fall bleibt die
>> Abschnittsgrenze stehen und beide ">>"‐Zitate bleiben getrennte
>> Abschnitte, obwohl sie ohne Leerzeile hinter einander folgen.
>
>Hmm, aber ist das eigentlich nicht völlig egal, bzw. ein Streit um
>des Kaisers Bart? Weil, üblicherweise bearbeite ich doch meine
>Beiträge im Zweifelsfall solange, bis sie so aussehen, wie ich mir
>das vorstelle. Ob nun mit Backspace oder Enter oder wie auch immer
>...

Beim Fließtextformat ist das nicht so einfach:  Da wird bei jedem
Leser jeder Fließtextabschnitt einzeln vom Newsreader des Lesers zum
Anzeigegerät (Schreibtisch‐Monitor, Smartphone, …) passend neu
umbrochen.  Das gilt aber nur für Fließtextabschnitte.  Grenzen
zwischen Fließtextabschnitten bleiben erhalten und
Festtextabschnitte werden nicht neu umbrochen.

Also, wenn du wirklich versucht hast, einen Teil des Ausschnitts,
wie beschrieben, zu löschen und dir der Nachrichteneditor das
Ergebnis vor dem Abschicken auch so angezeigt hat, dann hat der
Thunderbird das grandios versemmelt.

Ausgangspunkt dieser Diskussion war, dass Leute ihren Beitrag (mit
der [Backspace]‐ und der [Return]‐Taste) bearbeitet haben, bis er so
ausgesehen hat, wie sie sich das vorgestellt haben.  Nach dem
Abschicken haben sie beim Lesen ihres Beitrags festgestellt, dass
eine Leerzeile fehlt.  Darum geht es doch die ganze Zeit.

[Michael Pachta]

Am 22.08.2022 um 19:23 schrieb Thomas Barghahn:
> Das ist gar ein geschütztes Leerzeichen (0xA0) und ein Leerzeichen
> (0x20). Was das soll, das habe ich auch noch nicht verstanden.
> Nun ja ... - muss man denn auch alles verstehen(?) ... ;-)

Ah ja. Wenn man in den Quelltext von Helmuts Posting schaut, findet sich
nach einem Punkt am Satzende jeweils"=C2=A0", was anscheinend zusammen
ein geschütztes Leerzeichen darstellt. "Geschützt" heißt hier wohl, dass
dort kein Umbruch stattfinden darf. Warum nach einem Satzende-Punkt kein
Umbruch stattfinden soll, erschließt sich mir auch nicht.

[Jörg Knobloch]

On 22 Aug 2022 14:48, Tilmann Reh wrote:
> Ich edititiere die Nachrichten beim Antworten anders (ich füge
> Leerzeilen und gleich danach den eigenen Text ein, indem ich am Ende der
> letzten zitierten Zeile 2x Enter drücke). Dann habe ich noch gar nichts
> gelöscht. Trotzdem ist manchmal der Cursor in der Leerzeile noch blau
> und diese Leerzeile wird dann später beim Senden entfernt.

Der Bug ist ganz einfach zu reproduzieren.

Cursor ans Ende einer quote Zeile. 2x Enter. In die zweite Zeile etwas
schreiben, dann up-arrow in die erste Zeile, backspace. Keine visuelle
Reaktion obwohl das <br> entfernt wird. Senden. Erste Zeile fehlt.

[Thomas Barghahn]

*Michael Pachta* meinte:

Ich denke schon, dass uns Helmut zu diesem "geschützten Leerzeichen"
noch etwas schreiben wird. Warten wir es also einfach ab. ;-)

Thomas 😷
--
== S E N D E Z E I T ==============
DATUM : MONTAG, 22. AUGUST 2022

UHRZEIT: 21:03:24 UHR (MESZ)

[Helmut Waitzmann]

Thomas Barghahn <Th.Ba...@t-online.de>:

>*Michael Pachta* meinte:
>> Am 22.08.2022 um 19:23 schrieb Thomas Barghahn:
>
>>> Das ist gar ein geschütztes Leerzeichen (0xA0) und ein Leerzeichen
>>> (0x20). Was das soll, das habe ich auch noch nicht verstanden.
>>> Nun ja ... - muss man denn auch alles verstehen(?) ... ;-)
>
>> Ah ja. Wenn man in den Quelltext von Helmuts Posting schaut, findet sich
>> nach einem Punkt am Satzende jeweils"=C2=A0", was anscheinend zusammen
>> ein geschütztes Leerzeichen darstellt. "Geschützt" heißt hier wohl, dass
>> dort kein Umbruch stattfinden darf. Warum nach einem Satzende-Punkt kein
>> Umbruch stattfinden soll, erschließt sich mir auch nicht.
>
>Ich denke schon, dass uns Helmut zu diesem "geschützten Leerzeichen"
>noch etwas schreiben wird. Warten wir es also einfach ab. ;-)

Ich möchte zwischen je zwei Sätzen zwei Leerzeichen haben.  Das
erleichtert mir, auf einen Blick Satzenden von Abkürzungen wie
z. B. etc. u. a. innerhalb eines Satzes zu unterscheiden.  Ein
geschütztes Leerzeichen hinter dem Satzende bewirkt, dass auch bei
einem automatischen Neuumbruch des Texts die zwei Leerzeichen nicht
zu einem verschmelzen, sondern erhalten bleiben.  Ein Zeilenumbruch
kann dann statt dem normalen Leerzeichen, das dem geschützten
Leerzeichen folgt, stattfinden.  (Das geschützte Leerzeichen bleibt
dann am Zeilenende stehen.  Das ist vielleicht nicht optimal, fällt
optisch aber wenigstens nicht sehr auf.)

Hinter Abkürzungen setze ich – solange sie innerhalb eines Satzes
stehen und ihnen kein Satzzeichen folgt – nur ein geschütztes
Leerzeichen ohne ein weiteres normales Leerzeichen, ehe das nächste
Wort im Satz folgt.  Das hat den Effekt, dass die Abkürzung auch bei
Neuumbrechen des Texts immer das nächste Wort im Satz «hinter sich
herzieht» und deshalb nie ans Zeilenende gerät, wo sie mit dem
Satzende verwechselt werden könnte.

Crosspost & Followup-To: de.comp.text.misc (bei Bedarf ändern).

[Franklin Schiftan]

Am 2022-08-22 um 19:22 schrieb Helmut Waitzmann:

> Ausgangspunkt dieser Diskussion war, dass Leute ihren Beitrag (mit
> der [Backspace]‐ und der [Return]‐Taste) bearbeitet haben, bis er so
> ausgesehen hat, wie sie sich das vorgestellt haben. Nach dem
> Abschicken haben sie beim Lesen ihres Beitrags festgestellt, dass
> eine Leerzeile fehlt. Darum geht es doch die ganze Zeit.

Also, ich kann mich nicht erinnern, dass das mir schon mal passiert ist
... insofern wäre möglicherweise ein anderer Tester sinnvoller ...

.... und tschüss

Franklin

[Thomas Barghahn]

*Helmut Waitzmann* meinte:
> Thomas Barghahn <Th.Ba...@t-online.de>:

[...]

>>Ich denke schon, dass uns Helmut zu diesem "geschützten Leerzeichen"
>>noch etwas schreiben wird. Warten wir es also einfach ab. ;-)

> Ich möchte zwischen je zwei Sätzen zwei Leerzeichen haben. [...]

Dank(!) für all deine Hinweise und Empfehlungen. Beschäftigt habe ich
mich mit "f=f" den gestrigen Abend mal etwas intensiver. Persönlich sehe
ich darin aber keinen entscheidenden Vorteil gegenüber "format=fixed".

Das Argument "Handy" lasse ich nicht gelten, denn wenn man auf einem
Handy (quer gehalten) liest, dann passen auch dort locker 80 Zeichen in
einer Zeile. Zudem ist ein Handy nicht wirklich "das Gerät", über
welchem man seine komplette Kommunikation führen sollte - und das schon
gar nicht im UseNet. OK - auch das ist nur mein persönliches Empfinden.

Wie schon geschrieben - deine Beiträge zu diesem Thema waren und sind
wiedereinmal sehr interessant und lesenswert! :-)

> Crosspost & Followup-To: de.comp.text.misc (bei Bedarf ändern).

Sorry! Ignoriert, da ich dort nicht lese.

Thomas 😷
--
== S E N D E Z E I T ================
DATUM : DIENSTAG, 23. AUGUST 2022
UHRZEIT: 11:55:29 UHR (MESZ)
== Heute: 'Reite den Wind' Tag ======

[Thomas Barghahn]

*Franklin Schiftan* meinte:

Dann schau dir bitte einmal dein Posting vom 22.08.2022 17:24 an!
Dort findest du folgende Passage:

| >>> BTW:
| >>> Man sieht auch in diesem Zusammenhang, wie komplex und
| >>> "intelligent" die Composer von Mail- und Newsreadern sind und
| >>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...

^^^^^^^^^^^^^^^^ =========================================

^^^^ ==> *mein Text*!
==== ==> *DEIN Kommentar aus dem Vorposting*, der an meinem Text klebt!

Jetzt kannst du nicht mehr schreiben: "ich kann mich nicht erinnern,
dass das mir schon mal passiert ist" ;-)

Thomas 😷
--

== S E N D E Z E I T ================
DATUM : DIENSTAG, 23. AUGUST 2022

UHRZEIT: 13:03:31 UHR (MESZ)

[Franklin Schiftan]

Am 2022-08-23 um 13:03 schrieb Thomas Barghahn:
> *Franklin Schiftan* meinte:
>> Am 2022-08-22 um 19:22 schrieb Helmut Waitzmann:
>
>>> Ausgangspunkt dieser Diskussion war, dass Leute ihren Beitrag (mit
>>> der [Backspace]‐ und der [Return]‐Taste) bearbeitet haben, bis er so
>>> ausgesehen hat, wie sie sich das vorgestellt haben. Nach dem
>>> Abschicken haben sie beim Lesen ihres Beitrags festgestellt, dass
>>> eine Leerzeile fehlt. Darum geht es doch die ganze Zeit.
>
>> Also, ich kann mich nicht erinnern, dass das mir schon mal passiert ist
>> ... insofern wäre möglicherweise ein anderer Tester sinnvoller ...
>
> Dann schau dir bitte einmal dein Posting vom 22.08.2022 17:24 an!
> Dort findest du folgende Passage:
>
> | >>> BTW:
> | >>> Man sieht auch in diesem Zusammenhang, wie komplex und
> | >>> "intelligent" die Composer von Mail- und Newsreadern sind und
> | >>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...
> ^^^^^^^^^^^^^^^^ =========================================
>
> ^^^^ ==> *mein Text*!
> ==== ==> *DEIN Kommentar aus dem Vorposting*, der an meinem Text klebt!
>
> Jetzt kannst du nicht mehr schreiben: "ich kann mich nicht erinnern,
> dass das mir schon mal passiert ist" ;-)

Doch natürlich, denn diese Leerzeile fehlte auch schon bereits vor dem
Abschicken, nachdem ich die von Helmut vorgeschlagenen Tastendrücke
vollzogen hatte - Das Posting ist also genau so angekommen, wie ich's
abgeschickt hatte.
[Wie gesagt, würde ich normalerweise einen Beitrag so nicht abschicken,
das war nur wegen Helmuts Testanweisungen so.]

> Thomas 😷

[Thomas Barghahn]

*Franklin Schiftan* meinte:

> Am 2022-08-23 um 13:03 schrieb Thomas Barghahn:

[...]

>> | >>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...
>> ^^^^^^^^^^^^^^^^ =========================================

>> ^^^^ ==> *mein Text*!
>> ==== ==> *DEIN Kommentar aus dem Vorposting*, der an meinem Text klebt!

>> Jetzt kannst du nicht mehr schreiben: "ich kann mich nicht erinnern,
>> dass das mir schon mal passiert ist" ;-)

> Doch natürlich, denn diese Leerzeile fehlte auch schon bereits vor dem
> Abschicken, nachdem ich die von Helmut vorgeschlagenen Tastendrücke
> vollzogen hatte - Das Posting ist also genau so angekommen, wie ich's
> abgeschickt hatte.
> [Wie gesagt, würde ich normalerweise einen Beitrag so nicht abschicken,
> das war nur wegen Helmuts Testanweisungen so.]

OK(!) - dann habe ich hier etwas falsch verstanden. Sorry!

Thomas 😷
--
== S E N D E Z E I T ================
DATUM : DIENSTAG, 23. AUGUST 2022

UHRZEIT: 13:54:37 UHR (MESZ)

[Helmut Waitzmann]

Franklin Schiftan <fraschi...@arcor.de>:

>Am 2022-08-23 um 13:03 schrieb Thomas Barghahn:
>> *Franklin Schiftan* meinte:
>>> Am 2022-08-22 um 19:22 schrieb Helmut Waitzmann:
>>
>>>> Ausgangspunkt dieser Diskussion war, dass Leute ihren Beitrag (mit
>>>> der [Backspace]‐ und der [Return]‐Taste) bearbeitet haben, bis er so
>>>> ausgesehen hat, wie sie sich das vorgestellt haben. Nach dem
>>>> Abschicken haben sie beim Lesen ihres Beitrags festgestellt, dass
>>>> eine Leerzeile fehlt. Darum geht es doch die ganze Zeit.
>>
>>> Also, ich kann mich nicht erinnern, dass das mir schon mal passiert ist
>>> ... insofern wäre möglicherweise ein anderer Tester sinnvoller ...
>>
>> Dann schau dir bitte einmal dein Posting vom 22.08.2022 17:24 an!
>> Dort findest du folgende Passage:
>>
>> | >>> BTW:
>> | >>> Man sieht auch in diesem Zusammenhang, wie komplex und
>> | >>> "intelligent" die Composer von Mail- und Newsreadern sind und
>> | >>> auch sein müssen. Was allerdings nur auf HTML-Code zutrifft ...
>> ^^^^^^^^^^^^^^^^ =========================================
>>
>> ^^^^ ==> *mein Text*!
>> ==== ==> *DEIN Kommentar aus dem Vorposting*, der an meinem Text klebt!
>>
>> Jetzt kannst du nicht mehr schreiben: "ich kann mich nicht erinnern,
>> dass das mir schon mal passiert ist" ;-)
>
> Doch natürlich, denn diese Leerzeile fehlte auch schon bereits vor
> dem Abschicken, nachdem ich die von Helmut vorgeschlagenen
> Tastendrücke vollzogen hatte -

Das waren nicht die von mir vorgeschlagenen Tastendrücke.  Ich habe
vorgeschlagen, dass du mit der [Backspace]‐Taste soviel Text
löschst, bis du zum Ende der Zeile mit dem Satzende «auch sein
müssen.» gekommen bist.  Du hast aber anscheinend vorher damit
aufgehört: beim Ende deines von Thomas mit «====» markierten
Kommentars.

[Franklin Schiftan]

Nein, mein Kommentar stand nach den Tastendrücken hinter dem Cursor.

.... und tschüss

Franklin

[Helmut Waitzmann]

Franklin Schiftan <fraschi...@arcor.de>:

Und du hast wirklich, wie in


Subject: Re: Betterbird wird extrem langsam
From: Helmut Waitzmann <nn.th...@xoxy.net>
Newsgroups: de.comm.software.mozilla.mailnews
Date: Mon, 22 Aug 2022 16:30:45 +0200
Message-ID: <8335do2...@helmutwaitzmann.news.arcor.de>

beschrieben, die Schreibmarke ans Ende der Zeile, die deinem
Kommentar

«Was allerdings nur auf HTML-Code zutrifft ...»


folgt – ich habe sie damals als die drittletzte Zeile bezeichnet –
gestellt, und die [Backspace]‐Taste so lange wiederholt gedrückt
oder festgehalten, bis sie am Zeilenende der Zeile, die mit «auch
sein müssen.» schließt, angekommen ist?  Dabei müsste sie
eigentlich auch deinen Kommentar erwischt haben.  Und sie hat ihn
trotzdem stehen lassen?

Nochmal übersichtlicher gezeigt (mit fiktiven Zitaten A…, B… und
C…):

>> A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 A16
>> A17 A18 A19 A20
>
> B01 B02 B03 B04 B05 B06 B07 B08 B09 B10
>
>> C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11 C12 C13 C14 C15 C16
>> C17 C18 C19 C20

Mein Versuch war folgender:  Man stellt die Schreibmarke ans Ende
der Zeile zwischen den Zeilen B… und C….  Dann betätigt man die
[Backspace]‐Taste so oft (oder hält sie fest), bis die Schreibmarke
am Ende der Zeile mit dem A20 angekommen ist.

Möglicherweise erhält man unterschiedliche Ergebnisse, je nachdem,
ob man beim Thunderbird Fließtextverarbeitung beim Artikel‐Lesen
und/oder beim Artikel‐Schreiben ein‐ oder ausgeschaltet hat.

Von älteren Thunderbirds ist mir bekannt, dass man im
Konfigurationseditor

Fließtextverarbeitung beim Lesen einschalten kann, indem man
«mailnews.display.disable_format_flowed_support» auf «false» stellt,

Fließtextverarbeitung beim Lesen abschalten kann, indem man
«mailnews.display.disable_format_flowed_support» auf «true» stellt,

Fließtextverarbeitung beim Verfassen einschalten kann, indem man
«mailnews.send_plaintext_flowed» auf «true» stellt, und

Fließtextverarbeitung beim Verfassen abschalten kann, indem man
«mailnews.send_plaintext_flowed» auf «false» stellt.

[Franklin Schiftan]

Vermutlich nicht.

> folgt – ich habe sie damals als die drittletzte Zeile bezeichnet –

Das war dann hier wohl ein anderer Punkt ...

> gestellt, und die [Backspace]‐Taste so lange wiederholt gedrückt
> oder festgehalten, bis sie am Zeilenende der Zeile, die mit «auch
> sein müssen.» schließt, angekommen ist?  Dabei müsste sie
> eigentlich auch deinen Kommentar erwischt haben.  Und sie hat ihn
> trotzdem stehen lassen?
>
> Nochmal übersichtlicher gezeigt (mit fiktiven Zitaten A…, B… und
> C…):
>
>>> A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 A16
>>> A17 A18 A19 A20

>>> C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11 C12 C13 C14 C15 C16
>>> C17 C18 C19 C20
>
> Mein Versuch war folgender:  Man stellt die Schreibmarke ans Ende
> der Zeile zwischen den Zeilen B… und C….  Dann betätigt man die
> [Backspace]‐Taste so oft (oder hält sie fest), bis die Schreibmarke
> am Ende der Zeile mit dem A20 angekommen ist.

Dann ist zwischen A20 und C01 natürlich keine Leerzeile mehr, die also
auch nicht verschwinden könnte.

.... und tschüss

Franklin

[Helmut Waitzmann]

Ja.  Es hätte (je nach Implementierung) aber sogar sein können, dass
die Abschnittsgrenze hinter A20 ebenfalls mit weggelöscht worden
wäre.  Dann wären dadurch zwei an einander angrenzende
Fließformat‐Abschnitte möglicherweise zu einem zusammengeschmolzen. 
Das hätte dann beispielsweise so aussehen können:

>>>> A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 A16
>>>> A17 A18 A19 A20 C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11 C12
>>>> C13 C14 C15 C16 C17 C18 C19 C20

Hast du während der Durchführung des Versuchs Fließformatverwendung
zum Lesen ein‐ oder ausgeschaltet gehabt?  Zum Schreiben scheinst du
sie (gemäß deinem Nachrichtenvorspannfeld «Content-Type»)
eingeschaltet gehabt zu haben.

[Franklin Schiftan]

Hmm, also 'mailnews.display.disable_format_flowed_support' steht hier
auf true.

> Zum Schreiben scheinst du sie (gemäß deinem Nachrichtenvorspannfeld
> «Content-Type») eingeschaltet gehabt zu haben.

.... und tschüss

Franklin

[Jörg Knobloch]

On 22 Aug 2022 10:50, Jörg Knobloch wrote:
> So was können nur Spezialisten reparieren, die eigentlich hohe
> Tagessätze berechnen sollten, wenn sie nicht aus Liebe zur Sache umsonst
> arbeiten (und sich dann noch herber Kritik aussetzen).

Wir haben das Problem hier gemeldet:
https://bugzilla.mozilla.org/show_bug.cgi?id=1787577

Mal sehen, ob es wie das Problem beim Antworten auf space-stuffed f=f
https://bugzilla.mozilla.org/show_bug.cgi?id=341282
auch 16 Jahre liegen bleibt.

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 22 Aug 2022 10:50, Jörg Knobloch wrote:
>> So was können nur Spezialisten reparieren, die eigentlich hohe

>> Tagessätze berechnen sollten, wenn sie nicht aus Liebe zur Sache
>> umsonst arbeiten (und sich dann noch herber Kritik aussetzen).
>
> Wir haben das Problem hier gemeldet:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1787577

Danke!

>
> Mal sehen, ob es wie das Problem beim Antworten auf space-stuffed f=f
> https://bugzilla.mozilla.org/show_bug.cgi?id=341282
> auch 16 Jahre liegen bleibt.
>

Das dürfte für so einige User hier (mich eingeschlossen) mit dem Erleben
dann doch schon reichlich knapp werden. ;-)

Thomas 😷
--
== S E N D E Z E I T =================
DATUM : SONNABEND, 27. AUGUST 2022
UHRZEIT: 02:25:19 UHR (MESZ)
== Heute: Tag der Bananenliebhaber ===

[Jörg Knobloch]

On 27 Aug 2022 02:25, Thomas Barghahn wrote:
> Das dürfte für so einige User hier (mich eingeschlossen) mit dem Erleben
> dann doch schon reichlich knapp werden.

Ich weiß, der Altersdurchschnitt in den News-Gruppen wurde schon
vielfach diskutiert.

https://bugzilla.mozilla.org/show_bug.cgi?id=341282 werde ich bei
Gelegenheit mal angucken (f=f, space-stuffing, antworten), das ist
Thunderbird-Code, https://bugzilla.mozilla.org/show_bug.cgi?id=1787577
ist viel schwerer, das betrifft die Mozilla-Plattform, obwohl dieser
Code in Firefox nicht läuft. Der ist nur historisch (Netscape) dort.

[Arno Welzel]

Jörg Knobloch, 2022-08-27 01:19:

> On 22 Aug 2022 10:50, Jörg Knobloch wrote:
>> So was können nur Spezialisten reparieren, die eigentlich hohe
>> Tagessätze berechnen sollten, wenn sie nicht aus Liebe zur Sache umsonst
>> arbeiten (und sich dann noch herber Kritik aussetzen).
>
> Wir haben das Problem hier gemeldet:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1787577

Wer ist "wir"?


--
Arno Welzel
https://arnowelzel.de

[Jörg Knobloch]

On 27 Aug 2022 18:58, Arno Welzel wrote:
>> Wir haben das Problem hier gemeldet:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1787577
> Wer ist "wir"?

Ist das wichtig? Jemand von BB.

[Helmut Waitzmann]

Franklin Schiftan <fraschi...@arcor.de>:

Also ist die Fließformatverwendung beim Lesen ausgeschaltet.  Ich
vermute, dass dann folgendes geschieht:

Wenn man nun mit einem so konfigurierten Thunderbird einen
Folgebeitrag verfasst, nimmt der Thunderbird jede gelesene
Zitatzeile als eigenen Festformat‐Absatz (weil er das Fließformat
als Festformat interpretiert) und sieht davon ab, sie neu zu
umbrechen, obwohl das vom Zitierten ausdrücklich empfohlen worden
war.

=> Die Vorteile, die damit einhergehen sollten, dass derjenige, auf
den der Folgebeitrag geht, das Fließformat verwendet hat, kommen
nicht zum Tragen.

Statt dessen werden space‐stuffing‐bedingte Leerzeichen in den
Zitaten vom Thunderbird für bare Münze genommen (denn er weiß ohne
Fließformateinstellung beim Lesen nichts vom space‐stuffing).  Das
ergibt dann die zusätzlich erscheinenden Leerzeichen an zitierten
Zeilenanfängen, die manche dann dem Fließformat in die Schuhe
schieben anstatt der inkonsistenten Thunderbirdkonfiguration, die
beim Lesen das Fließformat ignoriert und beim Schreiben befiehlt.

[Franklin Schiftan]

Am 2022-08-28 um 11:05 schrieb Helmut Waitzmann:
> Franklin Schiftan <fraschi...@arcor.de>:
>> Am 2022-08-26 um 02:11 schrieb Helmut Waitzmann:
>>> Ja. Es hätte (je nach Implementierung) aber sogar sein können,
>>> dass die Abschnittsgrenze hinter A20 ebenfalls mit weggelöscht
>>> worden wäre. Dann wären dadurch zwei an einander angrenzende
>>> Fließformat‐Abschnitte möglicherweise zu einem
>>> zusammengeschmolzen. Das hätte dann beispielsweise so aussehen
>>> können:
>>>
>>>>>>> A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14
>>>>>>> A15 A16 A17 A18 A19 A20 C01 C02 C03 C04 C05 C06 C07 C08
>>>>>>> C09 C10 C11 C12 C13 C14 C15 C16 C17 C18 C19 C20
>>>
>>> Hast du während der Durchführung des Versuchs
>>> Fließformatverwendung zum Lesen ein‐ oder ausgeschaltet gehabt?
>>
>> Hmm, also 'mailnews.display.disable_format_flowed_support' steht
>> hier auf true.
>
> Also ist die Fließformatverwendung beim Lesen ausgeschaltet. Ich
> vermute, dass dann folgendes geschieht:
>
> Wenn man nun mit einem so konfigurierten Thunderbird einen
> Folgebeitrag verfasst, nimmt der Thunderbird jede gelesene
> Zitatzeile als eigenen Festformat‐Absatz (weil er das Fließformat als
> Festformat interpretiert) und sieht davon ab, sie neu zu umbrechen,
> obwohl das vom Zitierten ausdrücklich empfohlen worden war.

Deswegen habe ich mir womöglich angewöhnt, im Zweifelsfall immer erst
mal <strg><r> zu drücken.

.... und tschüss

Franklin

[Arno Welzel]

Jörg Knobloch, 2022-08-27 18:59:

> On 27 Aug 2022 18:58, Arno Welzel wrote:
>>> Wir haben das Problem hier gemeldet:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1787577
>> Wer ist "wir"?
>
> Ist das wichtig? Jemand von BB.

Ja, sonst hätte ich nicht gefragt.

Laut <https://github.com/Betterbird/thunderbird-patches> - das einzige
Repository von <https://github.com/Betterbird/> - gibt es acht Personen,
die irgendwann mal etwas committed haben.

Aber da das nicht das "Betterbird-Team" sondern einfach nur Leute, die
irgendwann mal irgendwas zum Code beigetragen haben und sei es auch nur
eine winzige Änderung irgendwann seit Bestehen des Projektes.

Wenn man sich die Commit-Historie ansieht, merkt man schnell, dass es
eigentlich nur eine Person ist, die die Haupt-Arbeit erledigt, wobe
zwschendurch auch mal zwei andere Leute kurzzeitig ebenfalls mehr
gemacht haben, als nur ein paar einzelne kleine Änderungen beizutragen.

Das ist auch nicht verwerflich - aber Du solltest nicht den Eindruck
erwecken, als hättest Du irgendein größeres "Team" hinter Dir und "ihr"
habt entschieden, einen Bug zu melden. Das wirkt eher sehr bemüht um
Anerkennung, weil ein "Team" halt mehr Gewicht hat, als "Einzelkämpfer".

[Jörg Knobloch]

On 22 Aug 2022 10:12, Jörg Knobloch wrote:
> On 22 Aug 2022 03:36, Thomas Barghahn wrote:
>> Bild_9:
>> Wir drücken erneut - warum auch immer -*einmal*  [BackSpace]!
>> *Es passiert nichts auf dem Bildschirm*! Nur in dem weiter oben
>> genannten Tool "ThunderHTMLedit" verschwindet ein <br> (Break)!
>> <https://www.barghahn-online.de/Pictures/tb_LZ_weg_9.png>
>
> Das ist offensichtlich ein Bug, ein Tastenanschlag sollte etwas
> bewirken, was auch sichtbar ist. Offenbar wird das <br> entfernt und das
> fehlt dann in der gesendeten Nachricht. Ein typisches Mozilla Editor
> Problem.

Wie gesagt, ich hatte es damals als
https://bugzilla.mozilla.org/show_bug.cgi?id=1787577
gemeldet.

Aus einem anderen Grund habe ich mir das heute noch einmal angeguckt.
Das Problem wurde mittlerweile im Mozilla Editor gelöst und sollte ab TB
123 beta nicht mehr vorhanden sein.

Für alle, die es schon in 115 haben wollen, habe ich es dort auch
repariert, wen es interessiert, kann es testen:

http://www.betterbird.eu/downloads2/betterbird-115.7.0-bb23-latest-build2.en-US.win64.installer.exe

Das Thema wurde auch hier <k5k6tfF...@mid.individual.net> mit dem
Betreff "TB frisst Leerzeilen :-(" wieder aufgenommen.

--
Viele Grüße, Jörg
Sent with Betterbird. Simply better.

www.betterbird.eu - www.betterbird.eu/#featuretable
Es ist immer wieder erstaunlich: Kaum macht man's richtig, schon
funktioniert's!

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 22 Aug 2022 10:12, Jörg Knobloch wrote:
>> On 22 Aug 2022 03:36, Thomas Barghahn wrote:
>>>

>>> [leerzeilenfressender TB/BB]
>>
>> Das ist offensichtlich ein Bug, [...]

>
> Wie gesagt, ich hatte es damals als
> https://bugzilla.mozilla.org/show_bug.cgi?id=1787577 gemeldet.

Dieses Phänomen habe ich schon längere Zeit nicht mehr beobachten
können. Allerdings kann dieses aber auch an meiner dem Bug angepassten
Arbeitsweise liegen.

BTW:
Was ist in diesem Zusammenhang eigentlich aus dem Tool "ThunderHTMLedit"
geworden? Gibt es dieses überhaupt noch irgendwo für die aktuellen
Versionen von TB/BB?

Thomas 😷
--
== S E N D E Z E I T ==================
  DATUM : Donnerstag, 25. Januar 2024
  UHRZEIT: 13:44:44 UHR (MEZ)
== Heute: Tag der Wetterbeobachtung ===

[Jörg Knobloch]

On 25 Jan 2024 13:44, Thomas Barghahn wrote:
> Dieses Phänomen habe ich schon längere Zeit nicht mehr beobachten
> können. Allerdings kann dieses aber auch an meiner dem Bug angepassten
> Arbeitsweise liegen.

Du kannst ja die Test-Version mal probieren.

> BTW:
> Was ist in diesem Zusammenhang eigentlich aus dem Tool "ThunderHTMLedit"
> geworden? Gibt es dieses überhaupt noch irgendwo für die aktuellen
> Versionen von TB/BB?

https://www.betterbird.eu/addons/index.html#ThunderHTMLedit

[Jörg Knobloch]

On 25 Jan 2024 14:23, Jörg Knobloch wrote:
> On 25 Jan 2024 13:44, Thomas Barghahn wrote:
> > Dieses Phänomen habe ich schon längere Zeit nicht mehr beobachten
> > können. Allerdings kann dieses aber auch an meiner dem Bug angepassten
> > Arbeitsweise liegen.
>
> Du kannst ja die Test-Version mal probieren.

Oder vielleicht lieber nicht, siehe Problem oben :-(

[Thomas Barghahn]

*Jörg Knobloch* meinte:

>
> Oder vielleicht lieber nicht, siehe Problem oben :-(

Ja, dieses Tool "zerhacktfleischt" irgendwie die Zitate. Schade
eigentlich, denn "es war einmal" ein sehr zuverlässiger "Spürhund", was
die Fehleranalyse betraf.

Thomas 😷
--
== S E N D E Z E I T ==================
  DATUM : Donnerstag, 25. Januar 2024

  UHRZEIT: 15:02:14 UHR (MEZ)

[Jörg Knobloch]

On 25 Jan 2024 15:02, Thomas Barghahn wrote:
> Ja, dieses Tool "zerhacktfleischt" irgendwie die Zitate. Schade
> eigentlich, denn "es war einmal" ein sehr zuverlässiger "Spürhund", was
> die Fehleranalyse betraf.

Wie bitte? Meine BB-Testversion ist kaputt. ThunderHTMLedit hat kein
Problem.

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 25 Jan 2024 15:02, Thomas Barghahn wrote:
>
>> Ja, dieses Tool "zerhacktfleischt" irgendwie die Zitate.
>

> Wie bitte? Meine BB-Testversion ist kaputt. ThunderHTMLedit hat kein
> Problem.

Ach so! Ich bezog deinen Hinweis: "Oder vielleicht lieber nicht, siehe
Problem oben" auf jenes Tool. Na dann werde ich einmal schauen ... :-)

Bezog sich dein Hinweis vielleicht auf das Herunterladen der
"latest‑build2" (bb115.7.0-bb23)?

Thomas 😷
--
== S E N D E Z E I T ==================
  DATUM : Donnerstag, 25. Januar 2024

  UHRZEIT: 15:36:14 UHR (MEZ)

[Thomas Barghahn]

*Thomas 'Ingrid' Barghahn* meinte:

>
> Bezog sich dein Hinweis vielleicht auf das Herunterladen der
> "latest‑build2" (bb115.7.0-bb23)?

natürlich bezog sich dein Hinweis auf jene Version. Wer das Lesen
beherrscht ... ;-) Sorry.

Thomas 😷
--
== S E N D E Z E I T ==================
  DATUM : Donnerstag, 25. Januar 2024

  UHRZEIT: 15:48:35 UHR (MEZ)

[Jörg Knobloch]

On 25 Jan 2024 15:48, Thomas Barghahn wrote:
> natürlich bezog sich dein Hinweis auf jene Version. Wer das Lesen

> beherrscht ... 😉 Sorry.

Richtig. Jetzt habe ich eine neue Version, da geht es wieder.

[Thomas Barghahn]

*Jörg Knobloch* meinte:

>
> Richtig. Jetzt habe ich eine neue Version, da geht es wieder.

"404 - You hate it :-(" Wohl wahr.

Thomas 😷
--
== S E N D E Z E I T ===================
  DATUM : Freitag, 26. Januar 2024
  UHRZEIT: 09:02:46 UHR (MEZ)
== Heute: 'Versteck einen Kuchen' Tag ==

[Jörg Knobloch]

On 26 Jan 2024 09:02, Thomas Barghahn wrote:
> "404 - You hate it :-(" Wohl wahr.

Genau, die neue Version ist natürlich nicht unter dem alten Link, gell?

https://www.betterbird.eu/downloads/WindowsInstaller/betterbird-115.7.0-bb23-latest-build3.en-US.win64.installer.exe

[Thomas Barghahn]

*Jörg Knobloch* meinte:

> On 26 Jan 2024 09:02, Thomas Barghahn wrote:
>>
>> "404 - You hate it :-(" Wohl wahr.
> Genau, die neue Version ist natürlich nicht unter dem alten Link, gell?
>

> betterbird-115.7.0-bb23-latest-build3.en-US.win64.installer.exe

Auch diese Version hat erheblich Schwierigkeiten mit dem Zitieren. So
entsteht aus längeren Absätzen, gerade auch dann, wenn sie "f=f"
formatiert sind, schon im Editor ein Aussehen, welches dem bekannten
"Kammquoting" sehr nahe kommt.
Ein Arbeiten mit obiger Version ist also gar nicht möglich.

Erfreulicherweise funktioniert das Tool "ThunderHTMLedit" in seiner
jetzigen Version hingegen ausgezeichnet. :-)

Thomas 😷
--
== S E N D E Z E I T ==============

  DATUM : Montag, 29. Januar 2024
  UHRZEIT: 16:12:24 UHR (MEZ)
== Heute: Tag des Puzzles =========

[Jörg Knobloch]

On 29 Jan 2024 16:12, Thomas Barghahn wrote:
> Auch diese Version hat erheblich Schwierigkeiten mit dem Zitieren. So
> entsteht aus längeren Absätzen, gerade auch dann, wenn sie "f=f"
> formatiert sind, schon im Editor ein Aussehen, welches dem bekannten
> "Kammquoting" sehr nahe kommt.
> Ein Arbeiten mit obiger Version ist also gar nicht möglich.

Genau, probiere mal

betterbird-115.7.0-bb23-latest-build4.en-US.win64.installer.exe