[Allegro] e-mab2.apr unterdrückt in seltenen fällen das zeilenendezeichen

[Thomas Berger]

Am 20.02.2015 um 08:57 schrieb Klaus Lehmann:
> Guten Morgen Herr Eversberg,

> sie haben u¬¬ rausgeschnitten. warum?
> 
> 
> 
> aus der aktuellen doku 34 erlaube ich mir zu zitieren:
> 
> u¬¬ Sonderfunktion: Nichtsortierzeichen verdoppeln
> Wenn ein Nichtsortierzeichen vor einem Wort steht, 
> wird ein zweites dahinter gesetzt. D.h. der "Nichtsortiermodus" 
> (→ Anh.A.1) wird von 0 auf 1 geändert. 
> Achtung: In der .CFG muß zu diesem Zeitpunkt aber n0 gesetzt sein, 
> hernach muß man es auf n1 setzen.
> 
> 
> ->>>OK. also soll das Nichtsortierzeichen NICHT verdoppelt werden!
> die doku verstehe ICH! 
> [herr berger wird zufrieden nicken, nicht wahr? ;-)]

Nein. Die Dokumentation im Handbuch ist an der Stelle dunkel.
Ist die beschriebene Sonderfunktion (es wird ja genau das
Gegenteil von dem getan, was etwa u!! taete) *nur dann aktiv*,
wenn in der .CFG-Datei "n0" steht oder ist das "muss zu diesem
Zeitpunkt" nur als allgemeine Ermahnung a la "sonst macht es
keinen Sinn" gedacht?


> 
> 
> ->>>JETZT kommt aber der "hatrick" in der doku:
> z.B. u[] : Wörter (Zeichenfolgen), die von den Zeichen x und y,
> uxy umschlossen sind, werden weggelassen. 
> Wenn x und y fehlen, wird für x das Nichtsortierzeichen genommen (→ Anh.A.1), 
> für y das Leerzeichen (bei Nichtsortiermodus n0) 
> bzw. ebenfalls das Nichtsortierzeichen. Mit u<> könnte man also bewirken, 
> daß spitz geklammerte Angaben wegfallen. 
> Ein evtl. hinter y stehendes Leerzeichen wird auch beseitigt, 
> sonst hätte man ein überzähliges.
> U Die Anwendung dieser Befehle empfiehlt sich für Sortierzwecke bei der Kopfkategorie #u1.
> Uxy Bei 'U' statt 'u' wird dann ferner das erste nachfolgende Wort automatisch groß geschrieben.
> 
> da steht: u mit zwei zeichen, bedeutet, alles was eingeschlossen ist, 
> wird gekillt! wir haben HIER zwei zeichen, nämlich links ein ¬ und 
> rechts ein ¬ . also wird das mittendrin gekillt, und die zeichen auch.
> WIE BITTE? was gilt nun? die obige aussage, oder die untere?
> [zufrieden nicken, ist aber jetzt NICHT angesagt!]

Es *ist* eben eine im Handbuch dokumentierte Sonderfunktion:
u<zeichen><zeichen> ist *normalerweise* das Herausnehmen des
darin eingeschlossenen Textes, *aber* wenn das Zeichen das in
der .CFG definierte Nichtsorzierzeichen ist, dann muessen Sie
die Abkuerzung "u" fuer diesen Zweck nehmen, denn u<zeichen><zeichen>
tut in diesem Fall das Gegenteil der Normalfunktion, indem es
den Text und die Zeichen drin laesst, bzw. ein ggfls. fehlendes
abschliessendes Nichtsortierzeichen ergaenzt.

Das war frueher eine sehr sinnvolle Magie-Funktion, als (bis V13 oder
war es V11?) der "allegro-Standard" ein einzelnes, einleitendes
Nichtsortierzeichen war, und MAB-Diskette genau dasselbe Zeichen
benoetigte, aber umschliessend (echtes MAB2 hingegen umschliesst
zwar auch, benutzt aber zwei verschiedene Zeichen, eines fuer
die Einleitung, eines fuer das Ende). Aus dieser Zeit stammen
auch die Vorkehrungen fuer das Unterprogramm u9 in der Importsprache.

Auch wenn der Standard fuer A.CFG nun seit Jahrzehnten "n1" (also
umschliessende Nichtsortierzeichen) ist, ist "n0" natuerlich nie
abgeschafft worden, also immer noch legal. Und da jede Sorte
Parameterdatei fuer alle diese Varianten funktionieren muss und
die Exportsprache die Setzung der .CFG auch nicht auslesen kann
(hilft auch nicht unbedingt, die Daten koennten ja "gegen die CFG"
erfasst vorliegen...), bleibt es eine Problemstelle: Die Parameter-
Dateien muessen beim Export eine groessere Einheitlichkeit herstellen
als ggfls. vorliegt. Andererseits funktioniert[e] die Sonderbedeutung
von u<zeichen><zeichen> wie gesagt nur in dem Fall, wo das identische
Zeichen nur ggfls. verdoppelt werden musste, also nur in der konkreten
Konstellation a.cfg -> MAB-Diskette. Da ist die Frage, ob das nicht
so speziell ist, dass man es besser abschafft und das an dieser Stelle
benoetigte lieber explizit in die Exportparameter hineinprogrammiert.


> ich sehe KEINE logik dadrin!
> 
> 
> 
> nochwas:
> dieser "fehler" (es ist mir wurscht, wie das bezeichnet wird!) ist 
> uralt. seit jahrzehnten werden daten an mabsysteme weitergegeben. 
> erzähle mir bite KEINER, daß das noch nie entdeckt worden sein kann, 

Der Fehlschluss ist moeglicherweise, dass Sie denken, dass irgendjemand diese
e-mab2.apr fuer MAB2-Exporte einsetzen koennte: Was da herauskommt bekommt
man doch sofort um die Ohren gehauen, ohne dass es um Finessen wie verlorene
Artikel im HST geht. Ausserdem hat es mit den 16bit-Modulen vermutlich
bis heute so wie dokumentiert funktioniert

viele Gruesse
Thomas Berger