Jag förstår inte varför Disgen använder sig av egna påhittade "radbrytstecken" som ¶ och ¥.

Normalt använder de flesta "plain text" program/gränssnitt radbyte som just radbyte, och eventuellt två radbyten efter varandra som paragrafbyte. Vad jag förstår använder GEDCOM just den metoden med dubbla radbyten.

*OM* nu Disgen ska använda egna "radbrytstecken", *BÖR* Disgen omarbeta texten vid urklippsformaten CF_TEXT och CF_UNICODETEXT vid både "kopiera" och "klistra in", liksom alla andra Windows-program gör.

Funktionen bör vara sådan, att uppreppade kopiera och klistra in, fram och tillbaka, mellan Disgen och Anteckningar, inte ska förändra texten eller hur radbyten fungerar.

Det enklaste hade varit om Disgen behandlade CR-LF som ett vanligt radbyte, liksom alla andra. Jag förstår inte varför det inte är så, men det har kanske någon historisk orsak (bakåtkompatibilitet).

Hade Disgen varit mitt program, hade jag nog övervägt att i en ny release (version av databasen) ersätta alla sekvenser av "¥ CR LF" med "CR LF" och "¥ NUL" med "NUL", och sedan behandlat "CR LF" som radbyte. Vem har utnyttjat att Ctrl-Enter ger ett i Disgen synligt radbyte som vid export/presentation tas bort? I så fall borde man vända på det och låta "¥" betyda "bind ihop med nästa rad". Det hade varit mer naturligt.

Redigeringskommandon inom < och >, språkval efter $ och vilka andra koder som kan finnas, är en annan historia, de kan vara orörda som de är vid Copy & Paste. Jämför med hur man redigerar ett inlägg här i forumet.

(Jag har yrkesmässigt jobbat med programutveckling i ca 35 år inom DOS, Win16, Win32 och .NET).