[epdf] - Markdown, LaTeX + Convertertools

[xenos1984]

Ich werde mal schauen, was da los ist. Meine Vermutung sind "leere" Kapitel. DocBook (was als Zwischenformat bei der Konvertierung von AsciiDoc nach PDF benutzt wird) wirft dann einen Fehler. Deshalb hatte ich unter jeder Überschrift ein tbd ergänzt, falls dort noch kein Text war.

Die Dateien konnte ich auch mit SVN auschecken.

[Beta-User]

Hallo zusammen,

habe jetzt eine "verpdf-bare" AsciiDoc-Variante ins svn geschubst. Da paßt hinten raus noch was mit den Zeilenumbrüchen (bzw. deren Zahl) nicht, die Überschriften sind teils nicht auf der richtigen Ebene usw., aber immerhin kann man alles mit cat in eine Datei packen und dann kommt wieder was raus...

Kleinere Korrekturen sind auch drin, aber nix großes, hauptsächlich Quotes...

just for your info.

[Schotty]

@Beta-User: Ich habe mir mal kap02.txt zur Brust genommen und ein paar Korrekturen, Umformulierungen und Anmerkungen (im Text mit "(ANMERKUNG v. Schotty: ...)" gekennzeichnet) vorgenommen. Rudi hat mir zwar Schreibrechte fürs SVN erteilt, aber ich hänge die Datei jetzt erstmal lieber hier an. Wie du siehst habe ich sie auch etwas umbenannt, damit du lokal bei dir nicht durchn Tüddel kommst - falls es dadurch Probleme beim Erzeugen eines Diffs gibt, sag bescheid, dann belasse ich die Dateinamen in Zukunft so, wie sie sind. Kannst es dir ja mal ansehen, ob es so für dich Sinn macht und auch mit den (ANMERKUNGEN ...) so gangbar und deutlich genug ist.
Hinsichtlich des Zusammenhangs zwischen dem Geschriebenen und den Screenshots habe ich jetzt noch nicht weiter nachgesehen, da warte ich, bis du ein 'fertiges' PDF zur Verfügung stellst (macht m.A.n. mehr Sinn).
Gruß

[Beta-User]

Hi Schotty,

ich schau mir das nochmal im Detail an, aber mal vorneweg einfach das feedback: sehr hilfreich!

Damit andere das zum einen Nachvollziehen können und zum anderen ein paar Dinge drin sind, die ich gerne "als Linie" geklärt hätte, einfach mal der Reihe nach die "Anmerkungen":



ANMERKUNG v. Schotty bzgl 'Cinema': Vielleicht anders formulieren, bspw "(..)"nach FHEM" und dann in den neu zu erstellenden 'Raum' namens "Cinema" zu bringen"
Im Testsystem gibt es den Raum schon, und es wird vorher auf die "Einträge" links Bezug genommen. Müßte also passen, wenn man das Bild vor Augen hat, oder?



ANMERKUNG v. Schotty: Der Begriff taucht hier zum ersten Mal auf - evtl vorher einmal drauf eingehen, was ein 'Modul' ist?!?
- Der Hinweis ist berechtigt, aber die Lösung nicht so einfach... Generell war mein Gedanke, nicht allzuviel Theorie usw. "nach vorne" zu packen, sondern das eher "intuitiv" zu versuchen. Aber die weiteren Anmerkungen in diese Richtung zeigen, dass es wohl etwas "too much" ist und wir uns für das Grundproblem was überlegen müssen.
- War erst am überlegen, ob man hier konkret einfach den Modulbegriff meiden sollte und stattdessen "commandref"-Eintrag schreiben, aber nachdem ich den Text nochmal etwas mehr im Zusammenhang gelesen habe, sollte man wohl wirklich etwas (hier wohl sogar deutlich) ausführlicher erläutern, was da grade passiert ist... (tbd.)


ANMERKUNG v. Schotty: Evtl noch einen Hinweis einfügen, wo die Dateien zu finden sind?
(zu fhem.cfg und statefile) Für fhem.cfg.demo ist es m.E. klar (bzw. es ist ok, wenn der Leser darüber nachdenkt), wir kommen ja aus der Kommandozeile. Für statefile wäre die Frage, ob man ganz dürre Worte verliert, oder bei sowas generell einfach einen Link setzt, wo das dann zu finden ist (gehört zu "global", auf das wir nochmal intensiver eingehen werden (fehlt noch), siehe https://fhem.de/commandref_modular_DE.html#global. Tendenziell würde ich einen einfachen Link auf die pdf-Erklärung zu global setzen?).


ANMERKUNG v. Schotty: Welche Anführungszeichen? Hier im Text habe ich diesbzgl keine entdeckt
...die sind meiner Schnellkorrektur zum Opfer gefallen => auch der Klammerzusatz kann weg.

ANMERKUNG v. Schotty: Dann vielleicht direkt auf die Sonderzeichen beim alias verzichten und darauf hinweisen, dass eine Verwendung von Sonderzeichen generell unterlassen werden sollte?
Nun ja, an der Stelle geht es ja... Denke, dass wir einerseits zu Demo-Zwecken _nicht_ darauf verzichten und andererseits vielleicht darauf hinweisen, dass auch der Gebrauch von Sonderzeichen usw. in alias-Attributen nicht so toll ist. Zudem fehlt, dass alias nicht "unique" sein muß...

ANMERKUNG v. Schotty: Welche direkteren Formen? Wenn du hier noch nicht darauf eingehst, dann diese Anmerkung in der Klammer evtl ganz weglassen
CommandSet, z.B.. Und darauf einzugehen, führt tatsächlich (viel) zu weit. Andererseits muß einem nicht beim ersten Lesen alles klar sein, und für den Experten-Leser wird so eher klar, dass das eben eine Vereinfachung ist und mehr Möglichkeiten bestehen. Neige dazu, das so zu lassen.

ANMERKUNG v. Schotty: Der Satz ist irgendwie sehr verschachtelt ...
Berechtigter Hinweis. So einfacher:
"Die mit setstate beginnenden Zeilen brauchen wir nicht, aber das sind die Zeilen, die in der oben bereits erwähnten *statefile* gespeichert werden. Dir fällt vielleicht auf, dass hier statt des _define_, das du eingegeben hattest, die Schreibweise _defmod_ verwendet wird? Zum Unterschied zwischen beiden kommen wir gleich. Jedenfalls wird das _define_ sowie die Attribute in der Konfigurationsfile (zuerst meistens _fhem.cfg_) gespeichert."

ANMERKUNG v. Schotty: Diesen Hinweis bzgl Nicht-Speichern der Demo-Konfig vielleicht direkt am Anfang des Umgangs mit dem Demo-System bringen...
Kann sein, habe da auch immer mal wieder überlegt, wo der richtige Ort für den Hinweis ist. An sich ist es nicht wirklich wichtig, im schlimmsten Fall ist eben ein Shelly oder Receiver in der demo-config. Richtig doof wird das erst, wenn der Port geändert ist...
Vielleicht am einfachsten noch einen Zusatz machen wie: "Falls du das doch schon gespeichert hattest: nicht schlimm, aber ab jetzt bitte erst wieder, wenn es ausdrücklich dasteht und dann genau so wie angegeben!"

ANMERKUNG v. Schotty: Wie weiter oben schon geschrieben wäre es m.E. ratsam, auf den Unterschied diesbzgl bereits weiter oben einzugehen.
(bezieht sich auf "defmod"). Hat sich mit der Änderung oben erübrigt, oder?

ANMERKUNG v. Schotty: Der Befehl 'help' sollte m.A.n. ebenfalls schon vorher, ansonsten aber nochmal gesondert explizit genannt werden, auch mit dem Hinweis auf die Verfügbarkeit der Hilfe-Funktion hinsichtlich Modulen. Dort ist dann ja auch entnehmbar, in welchem Board/Unterforum Fragen bzgl des Moduls gestellt werden können etc.
Das mit "Wie bekomme ich Hilfe im Forum" hätte ich nach hinten geschoben, der Platzhalter war u.A. dafür gedacht. Aber auch hier war ich vermutlich "zu schnell". Etwas langsamer?

"Da auch das `save`-Kommando ein paar Optionen kennt, schauen wir uns das erst mal etwas genauer an. Du könntest jetzt wieder den Eintrag _commandref_ aus dem Menü links aufrufen, aber es gibt eine weitere, direktere Variante, an diese Informationen zu kommen. Versuch's mal mit `help save`.



ANMERKUNG v. Schotty: Im Satz vorher steht, dass "die aktuell laufende Sitzung mit dem Demo-System beschäftigt ist" - wenn dem so ist, warum muss es dann jetzt nochmal neu gestartet werden?
Da ist mir beim Verschieben von Textblöcken bzw. nachträglichen Änderungen im Vorgehen was durcheinandergeraten, muß korrigiert werden!


ANMERKUNG v. Schotty: Der letzte Satz ist m.A.n. ebenfalls 'unklar'..
(bezieht sich auf Alternativen zu fhem.cfg = configDB). Würde hier auch einen (kommentarlosen) Link auf einen noch fehlenden Teil einfügen?


ANMERKUNG v. Schotty: Was ist der Unterschied zw "save" und "save minimal.cfg"? Das ist/wird hier nicht deutlich, eine Erklärung wäre sicherlich hilfreich.
An sich ist gewollt, dass der Leser sich diese Frage stellt... Ist aber vermutlich wirklich noch zu schwierig, wie wäre es mit einer Erweiterung?
"Wie wäre es also jetzt mit einem schnellen `save minimal.cfg`? Dann haben wir noch eine vierte Konfigurationsdatei _minimal.cfg_ im fhem-Verzeichnis liegen, mit der wir FHEM starten können."


Du siehst also: Diese Art des kritischen Durchsehens hilft.

Wäre schön, wenn ihr (ggf. einfach per Stichwort) kurz was dazu sagen könntet, auch zu den Geschmacksfragen.

Das diff im Detail sehe ich mir nochmal gesondert an.

[Schotty]

Im Testsystem gibt es den Raum schon, und es wird vorher auf die "Einträge" links Bezug genommen. Müßte also passen, wenn man das Bild vor Augen hat, oder?

Yupp, wird wohl so sein - wie gesagt, den 'Zusammenhang' zw Geschriebenem und den Grafiken habe ich jetzt noch nicht gecheckt, das gucke ich mir dann lieber mit einer (ersten) PDF-Version an, dann bekomme ich auch einen besseren Eindruck hinsichtlich Layout.

Generell war mein Gedanke, nicht allzuviel Theorie usw. "nach vorne" zu packen, sondern das eher "intuitiv" zu versuchen. Aber die weiteren Anmerkungen in diese Richtung zeigen, dass es wohl etwas "too much" ist und wir uns für das Grundproblem was überlegen müssen.

Yupp, intuitiv ist so eine Sache, denn bei 'Euch Experten' ist die Intuition in dem Fall eine gaaanz andere als bei 'uns n00bs'
Auch wenn manche Dinge dadurch für versierte User evtl 'langweilig/langatmig' werden, so ist die Zielgruppe m.E. aber ja eine andere, nämlich Anfänger mit null Plan vom Ganzen. Und für die können gewisse Dinge erfahrungsgemäß nicht 'einfach' genug erklärt sein. Also lieber einen Satz zuviel, als einen zuwenig..

- War erst am überlegen, ob man hier konkret einfach den Modulbegriff meiden sollte und stattdessen "commandref"-Eintrag schreiben, aber nachdem ich den Text nochmal etwas mehr im Zusammenhang gelesen habe, sollte man wohl wirklich etwas (hier wohl sogar deutlich) ausführlicher erläutern, was da grade passiert ist... (tbd.)

Imho sind GERADE Dinge wie 'Modul' etc unabdingbar erklärungsbedürftig für einen Einsteiger. Zum einen kommt das auch im Forumsbereich immer wieder als Antwort auf bestimmte Fragen ("da gibt's ein Modul für" -> öhm, ja, danke, aber wie/wo/was muß ich suchen? Ich habe doch keinen Plan?! ), und zum anderen könntest du auf das ganze Einsteiger-PDF verzichten, wenn letztlich doch (immer wieder) 'nur' auf die commandref oder das Wiki verwiesen wird (was ja grundsätzlich nicht der Fall ist, also bitte nicht falsch verstehen! ).

Bitte versteht mich hier nicht falsch - commandref und Wiki sind gute und wichtige Infoquellen, aber (Hand auf's Herz) nunmal nicht immer gerade einsteigerfreundlich formuliert (was ja auch vollkommen i.O. ist!). Selbst erfahrenere User haben da z.T. Verständnisprobleme, wenn ich mir diverse Forenbeiträge so ansehe.
Hinzu kommt, dass manche Beschreibungen in der commandref nur auf Englisch vorzuliegen scheinen (gerne auch mal mitten im deutschen Text) - allerdings spricht heutzutage nunmal noch immer nicht jeder Englisch und ist spätestens da aufgeschmissen. Was Google-Translator in einem solchen Fall draus macht, möchte ich gar nicht wissen.. (..hmm, oder vielleicht doch? Da kommen bestimmt lustige Sachen bei raus..  )

(zu fhem.cfg und statefile) Für fhem.cfg.demo ist es m.E. klar (bzw. es ist ok, wenn der Leser darüber nachdenkt), wir kommen ja aus der Kommandozeile.

Klar ist es ok, wenn der Leser nachdenkt - soll er ja auch - aber manche Dinge erschließen sich einem Einsteiger mangels Vor- oder Hintergrundwissen nunmal auch bei dem x-ten Lesen nicht (hermeneutischer Zirkel hin oder her), da kann er u.U. nachdenken, so viel er will. Logisch kannst/willst du nicht zeitgleich einen Windows/Linux/whatever-Basiskurs draus machen, aber wie gesagt: Eine Doku für Einsteiger/Anfänger zu erstellen ist eine andere Baustelle und erfordert m.A.n. andere Vorgehens- und auch Beschreibungsweisen, als eine Doku für versierte oder gar professionelle User.   

Für statefile wäre die Frage, ob man ganz dürre Worte verliert, oder bei sowas generell einfach einen Link setzt, wo das dann zu finden ist (gehört zu "global", auf das wir nochmal intensiver eingehen werden (fehlt noch), siehe https://fhem.de/commandref_modular_DE.html#global. Tendenziell würde ich einen einfachen Link auf die pdf-Erklärung zu global setzen?).

Wenn du 'später' im PDF eh drauf eingehst: Klar, dann bitte immer zusätzliche Links zu den entsprechenden (nachfolgenden) Kapiteln hinzufügen. Wenn du zusätzlich auch noch die passenden Links für den jeweiligen commandref- und/oder Wiki-Eintrag dazu packst - noch besser! Nur eben 'reine' Verweise auf cr/Wiki sind wie oben erwähnt m.E. nicht (immer) gerade zielführend.

ANMERKUNG v. Schotty: Dann vielleicht direkt auf die Sonderzeichen beim alias verzichten und darauf hinweisen, dass eine Verwendung von Sonderzeichen generell unterlassen werden sollte?
Nun ja, an der Stelle geht es ja... Denke, dass wir einerseits zu Demo-Zwecken _nicht_ darauf verzichten und andererseits vielleicht darauf hinweisen, dass auch der Gebrauch von Sonderzeichen usw. in alias-Attributen nicht so toll ist. Zudem fehlt, dass alias nicht "unique" sein muß...

Klar, dann so, wie du schreibst. Mir ging nur durch den Kopf, dass es vielleicht (erstmal) 'einfacher' für alle wäre, dazu zu raten, Sonderzeichen generell eher zu meiden.

ANMERKUNG v. Schotty: Welche direkteren Formen? Wenn du hier noch nicht darauf eingehst, dann diese Anmerkung in der Klammer evtl ganz weglassen
CommandSet, z.B.. Und darauf einzugehen, führt tatsächlich (viel) zu weit. Andererseits muß einem nicht beim ersten Lesen alles klar sein, und für den Experten-Leser wird so eher klar, dass das eben eine Vereinfachung ist und mehr Möglichkeiten bestehen. Neige dazu, das so zu lassen.

Selbstverständlich muss und kann einem beim ersten Lesen nicht alles klar sein, das Textverständnis ändert sich ja immer wieder mit dem neu erworbenen Wissen (wieder Stichwort 'hermeneutischer Zirkel'). Aber auch hier nochmal meine 2ct: Das ist/wird ein Einsteiger-PDF - "Experten-"Leser sind dabei (erstmal) eine andere Zielgruppe. Aber lass es ruhig so.

ANMERKUNG v. Schotty: Der Satz ist irgendwie sehr verschachtelt ...
Berechtigter Hinweis. So einfacher:
"Die mit setstate beginnenden Zeilen brauchen wir nicht, aber das sind die Zeilen, die in der oben bereits erwähnten *statefile* gespeichert werden. Dir fällt vielleicht auf, dass hier statt des _define_, das du eingegeben hattest, die Schreibweise _defmod_ verwendet wird? Zum Unterschied zwischen beiden kommen wir gleich. Jedenfalls wird das _define_ sowie die Attribute in der Konfigurationsfile (zuerst meistens _fhem.cfg_) gespeichert."

Yupp, so ist's besser!

ANMERKUNG v. Schotty: Diesen Hinweis bzgl Nicht-Speichern der Demo-Konfig vielleicht direkt am Anfang des Umgangs mit dem Demo-System bringen...
Kann sein, habe da auch immer mal wieder überlegt, wo der richtige Ort für den Hinweis ist. An sich ist es nicht wirklich wichtig, im schlimmsten Fall ist eben ein Shelly oder Receiver in der demo-config. Richtig doof wird das erst, wenn der Port geändert ist...
Vielleicht am einfachsten noch einen Zusatz machen wie: "Falls du das doch schon gespeichert hattest: nicht schlimm, aber ab jetzt bitte erst wieder, wenn es ausdrücklich dasteht und dann genau so wie angegeben!"

Klar, geht prinzipiell auch - aber was spräche dann dagegen, einfach ganz am Anfang des Doks einen Hinweissatz dieser Art unterzubringen? So à la "Bevor wir anfangen, uns mit der Einrichtung und Konfiguration von FHEM auseinander zu setzen, noch ein kurzer Hinweis, was das Speichern der (geänderten) Konfiguration angeht: Bitte speichere erst, wenn im Text ausdrücklich darauf hingewiesen wird und tue dies dann auch bitte exakt so, wie es beschrieben sein wird." Man muss ja nicht warten, bis das Kind in den Brunnen gefallen ist

ANMERKUNG v. Schotty: Wie weiter oben schon geschrieben wäre es m.E. ratsam, auf den Unterschied diesbzgl bereits weiter oben einzugehen.
(bezieht sich auf "defmod"). Hat sich mit der Änderung oben erübrigt, oder?

Yupp, alles schick

Das mit "Wie bekomme ich Hilfe im Forum" hätte ich nach hinten geschoben, der Platzhalter war u.A. dafür gedacht. Aber auch hier war ich vermutlich "zu schnell". Etwas langsamer?

"Da auch das `save`-Kommando ein paar Optionen kennt, schauen wir uns das erst mal etwas genauer an. Du könntest jetzt wieder den Eintrag _commandref_ aus dem Menü links aufrufen, aber es gibt eine weitere, direktere Variante, an diese Informationen zu kommen. Versuch's mal mit `help save`.

Ja, ginge natürlich, und wenn das Thema 'help' später nochmal explizit behandelt wird, dann kannst du auch wieder zusätzlich den Link zu dem entspr Kap im PDF setzen.

Vielleicht sollten wir aber für so zentrale Punkte generell auch noch einen kleinen Index am Dokumentenende erstellen, je nachdem, wie 'verschachtelt' am Ende gewisse Themen im Text oder auch im Inhaltsverzeichnis sind. Aber da können wir ja zum Schluss nochmal drüber nachdenken.

ANMERKUNG v. Schotty: Der letzte Satz ist m.A.n. ebenfalls 'unklar'..
(bezieht sich auf Alternativen zu fhem.cfg = configDB). Würde hier auch einen (kommentarlosen) Link auf einen noch fehlenden Teil einfügen?

Ah ok, ja, dann passt es wieder.

ANMERKUNG v. Schotty: Was ist der Unterschied zw "save" und "save minimal.cfg"? Das ist/wird hier nicht deutlich, eine Erklärung wäre sicherlich hilfreich.
An sich ist gewollt, dass der Leser sich diese Frage stellt... Ist aber vermutlich wirklich noch zu schwierig, wie wäre es mit einer Erweiterung?
"Wie wäre es also jetzt mit einem schnellen `save minimal.cfg`? Dann haben wir noch eine vierte Konfigurationsdatei _minimal.cfg_ im fhem-Verzeichnis liegen, mit der wir FHEM starten können."

Yupp, die Erweiterung finde ich besser.

Bevor jetzt von irgendeiner Seite ein Aufschrei kommt: Logisch soll dem Einsteiger nicht alles 1:1 vorgekaut und präsentiert werden (Konfuzius und seine Fische), ist schon klar - aber es bringt (dem unbeleckten Leser) nicht viel, wenn man am Ende mit Fragen vor dem Dok sitzt, deren Antwort sich einem Einsteiger nunmal nicht erschließt oder (mangels Vor-/Hintergrundwissen) erschließen kann.
"Es ist gewollt, dass der Leser sich diese Frage stellt" ist verständlich und ja grundsätzlich auch richtig - es darf imho nur eben nicht so sein, dass sich die Antwort auf diese Frage durch das Lesen des Textes nicht klärt und der Leser damit allein gelassen wird.
Schließlich soll die Lektüre am Ende ja Spaß machen und dazu motivieren, sich auch über das Einsteiger-PDF hinausgehend in FHEM einzuarbeiten. Es bringt ja nichts, wenn der einsteigende Leser am Ende frustriert das Dok in den Papierkorb verschiebt und sich einem anderen HA-System zuwendet (wo er dann vermutlich vor ähnlichen Problemen steht - keine Ahnung, ich habe andere vielgelobte Systeme selbst nicht getestet), nur weil er im Grunde noch verwirrter und mit mehr Fragezeichen auf der Stirn dasitzt, als es ohnehin der Fall ist.

Von einer Anleitung für einen Einsteiger erwarte ich persönlich, dass selbiger damit wirklich einen guten und gangbaren Einstieg in die Benutzung -in diesem Fall von FHEM- erhält - das beinhaltet nunmal (leider?) auch, dass gewisse 'Selbstverständlichkeiten' erklärt werden. Notfalls auch mal an irgendeiner Stelle doppelt und anders formuliert.

Wenn es dann für ein gewisses Publikum zu einfach oder langweilig/langatmig wird - sorry guys, dann bitte bis zum nächsten Abschnitt querlesen oder direkt in die commandref abtauchen..

[Beta-User]

...das mit dem pdf muß erst mal noch warten, bin auch erst am Spielen mit der AsciiDoc-Syntax bzw. warte auch mal drauf, was xenos1984 daraus macht...

Die Bilder an sich sind aber vorhanden/kann man ansehen (ist aber "mühsam", klar) oder die Befehle auch "nachmachen" (an einem Testsystem).

Zum eigentlichen: Ist völlig ok, wenn du mich da auf eine erträgliche Geschwindigkeit einbremst, alles bestens, und ich hoffe, deine Anmerkungen auch "gut" eingearbeitet zu haben...

Bin noch nicht ganz fertig, aber zumindest sind die soweit erst mal "vorverarbeitet", und hoffe, dass du nach Lektüre etwas weniger Sorge hast, dass das "zu schnell" gehen soll . (manchmal steht nur "link" da; das sollte in der Regel ein "interner" sein, es ist nicht geplant, die Leser bei den "basics" auf irgendwelche externe Doku zu verweisen (es sei denn, die sei auf dem passenden Niveau oder kann dahin gebracht werden)). Und die eine oder andere Gelegenheit läßt sich vielleicht auch "konstruktiv nutzen" - bin mal gespannt, ob und wie ihr das findet, worauf ich grade anspiele )

[Schotty]

Ich will dich weder ein- noch ausbremsen, aber ich lese es wie gewünscht mit der 'DAU'-Brille und dementsprechend sind meine Anmerkungen/Vorschläge auch zu verstehen

Und die eine oder andere Gelegenheit läßt sich vielleicht auch "konstruktiv nutzen" - bin mal gespannt, ob und wie ihr das findet, worauf ich grade anspiele )

Ostereiersuchen ist vorbei 
Bzgl der 'Gelegenheiten' verstehe ich gerade nicht, was du meinst, aber vielleicht klärt sich das ja beim Lesen..

Noch eine generelle Anmerkung:
Wenn du die Änderungen o.ä. übernommen hast, würde ich es sinnvoller finden, wenn du das in die jeweilige Datei im SVN übernimmst und dort aktualisierst. Sonst haben wir hier ruck-zuck ein Kuddelmuddel (mit deiner neuen Version existieren jetzt bspw zwei Versionen der von mir angehängten Datei, das kann schnell unübersichtlich werden). Ich hatte es nur hier eingestellt, weil ich a) gucken wollte, ob das so ein gangbarer Weg ist, ich b) nichts 'zerschießen' wollte (bin noch nicht so firm mit SVN) und c) es so auch andere User machen könn(t)en, die keine SVN-Schreibrechte haben.

[Beta-User]

ist jetzt auch im svn, damit die Ostereiersuche einfacher wird (noch sind mancherorts Ferien...) .

[Schotty]

Sorry, hab's jetzt erst gesehen aber die angehängte Datei vorhin schon in der Mangel gehabt, korrigierte und kommentierte (nur in einem Fall, ich glaube ca Zeile 72, jetzt mit "(->2CHECK)" gekennzeichnet, das war dir vorhin wohl durchgerutscht) Fassung im Anhang.

Falls die (Haupt-)Ostereier mit M wie Modul und D wie define/defmod anfangen, dann habe ich sie gefunden und finde sie gut

EDIT: Stimmt nicht,hatte doch mindestens zwei anmerkungen gemacht,die o.g. und noch eine weitere..

[Beta-User]

So, das sollte jetzt weitestgehend in https://svn.fhem.de/trac/changeset/21705/ enthalten sein.

Das Hauptosterei war aber eher was anderes: Anleitungen genau befolgen .

[Schotty]

..gerade noch n typo entdeckt: abschnitt "save", erster block,letzte zeile: "Echtsysstem" -> ein s zuviel.

Falls du mit "anleitungen genau befolgen" meinst,dass ich alles schritt für schritt nachstellen soll: sorry,aber das schaffe ich zeitlich derzeit absolut nicht - bin froh,dass ich heute schonmal kap02 bis hierhin geschafft habe.. 

[Schotty]

Hier kap01.txt, gekennzeichnet als kap01_Schotty_v1.txt.

Generelle Anmerkungen/Fragen:
- Wörter wie firmware, zip, update, links etc schreibst du klein. Es sind zwar 'englische' Wörter, werden aber in der 'deutschen' Verwendung imho trotzdem groß geschrieben (die Firmware, das Zip, das Update etc). Ich habe es jetzt noch nicht durchgehend geändert, schlage es aber hiermit vor.
EDIT: Sehe gerade, dass du bspw "Interface" in kap09 auch großgeschrieben hast - würde ich wie gesagt dann durchgängig so empfehlen..
- An zwei Stellen bereits im Text gekennzeichnet, aber hier auch nochmal: M.A.n verwendest du etwas zu häufig Anführungszeichen für bestimmte Worte (s. Anmerkung im Text). Kam von anderer Seite hier auch schonmal als Anmerkung glaube ich (xenos?). Gerade, wenn du diejenigen Worte noch mit asciidoc-Syntax hervorherbst oder krusiv schreibst o.ä., dann ist es zuviel des Guten und macht den Text m.E. eher unleserlicher.
- Hatte ich bereits mal per Email nachgefragt, aber da wolltest du nochmal drüber nachdenken: "Du" oder "du"? Gestern in kap02 war es bereits klein geschrieben, hier in kap01 habe ich es jetzt auch geändert. Wenn du dennoch "Du", "Dein" etc groß schreiben willst, sag bitte bescheid, dann erspare ich mir und dir die Änderungen
EDIT: Ich sehe gerade, dass es in kap03 & kap09 auch klein geschrieben ist - werde ich dann jetzt erstmal so beibehalten..

Ansonsten: Hinweis von gestern Abd bzgl Typo in kap02 hattest du gesehen? (s. Beitrag über diesem)

[Schotty]

kap03

[Beta-User]

Vielleicht aus gegebenen Anlaß ein paar Anmerkungen zum "opus operandi":

(war zu langsam, hat sich teils überschnitten).

..gerade noch n typo entdeckt: abschnitt "save", erster block,letzte zeile: "Echtsysstem" -> ein s zuviel.

Bei sowas ist es m.E. am einfachsten, das direkt ins svn zu schubsen. Als Kommentar reicht es mir, dass es einen commit gibt...

Generell wären in meiner Wahrnehmung bisher alle Anmerkungen und Änderungen ganz gut im svn aufgehoben gewesen, man sieht da auch in der Regel sehr schnell, ob es größere oder kleinere Änderungen waren usw.. (und ich gehe davon aus, dass das bei den Vorschlägen zu kap01 auch nicht anders sein wird!)

Wenn man (kurze) Schlüsselwörter für Fragen oder Anregungen verwendet ("Schotty: " "xenos: ", "xxxx: ", "link" ...), ist das sogar gut, weil ich die dann ggf. auch als Merkposten länger "mitschleifen" kann, und ihr seht in den svn-diffs auch gleich, wann es ggf. wie gelöst wurde?

Falls du mit "anleitungen genau befolgen" meinst [...]

Nochmal: Kein Stress! Das war nicht an dich addressiert, sondern an dich ging die Frage: "Ist es eine gute Idee, den Leser ggf. erst mal in diese 'Falle' laufen zu lassen, um bei der Gelegenheit das Thema 'Anleitungen befolgen' auch gleich zu abzuräumen?".

Natürlich wäre es wünschenswert, wenn sich irgendwann mal noch irgendjemand an eine 1:1 Umsetzung machen würde, aber das eilt im Moment nicht und gehört eher in die Kategorie "Feinschliff".

Was fertiger ist, ist gut, was noch nicht: kein Problem. Wichtiger ist das mit den Anmerkungen gewesen!

Muß mir am WE mal die Zeit nehmen, die Bausteinchen zu sortieren und ggf. an kap02 weiterzuarbeiten (Tendenz da: global und fhem.pl). Von daher wäre von deiner Seite (@Schotty) ein (überschlägiger) review von kap03 und kap09 evtl. mal ganz gut (wenn Zeit dafür ist) - wobei je weiter hinten desto mehr zu erwarten ist, dass sich da noch einiges ändern wird.

@xenos1984: das "kontroll-pdf" hatte ich mit a2x erstellt. Das kann aber scheinbar mit den remote-Bildern nicht umgehen (ich habe die manpage noch nicht angesehen, ist evtl. einfach). Das würde mich im Moment jedenfalls von "deiner Seite" am meisten "drücken"... (auch nicht eilig!)

Generelle Anmerkungen/Fragen:
- Wörter wie firmware, zip, update, links etc schreibst du klein. Es sind zwar 'englische' Wörter, werden aber in der 'deutschen' Verwendung imho trotzdem groß geschrieben (die Firmware, das Zip, das Update etc). Ich habe es jetzt noch nicht durchgehend geändert, schlage es aber hiermit vor.

Akzeptiert!

- An zwei Stellen bereits im Text gekennzeichnet, aber hier auch nochmal: M.A.n verwendest du etwas zu häufig Anführungszeichen für bestimmte Worte (s. Anmerkung im Text). Kam von anderer Seite hier auch schonmal als Anmerkung glaube ich (xenos?). Gerade, wenn du diejenigen Worte noch mit asciidoc-Syntax hervorherbst oder krusiv schreibst o.ä., dann ist es zuviel des Guten und macht den Text m.E. eher unleserlicher.

andies hatte das kritisiert, ich habe das nebenbei ebenfalls in diese Richtung verändert. Würde vorschlagen, Anführungszeichen auf "eigene" (erfundene oder auf spezielle Weise verwendete) Begriffe zu reduzieren?
(Ich habe nur noch keine wirkliche Linie gefunden, wie man das am besten markiert, gehe aber davon aus, dass kursiv in der Mehrzahl der Fälle die beste Wahl ist. => nach Gutdünken so ändern).

- Hatte ich bereits mal per Email nachgefragt, aber da wolltest du nochmal drüber nachdenken: "Du" oder "du"? Gestern in kap02 war es bereits klein geschrieben, hier in kap01 habe ich es jetzt auch geändert. Wenn du dennoch "Du", "Dein" etc groß schreiben willst, sag bitte bescheid, dann erspare ich mir und dir die Änderungen
EDIT: Ich sehe gerade, dass es in kap03 auch klein geschrieben ist - werde ich dann jetzt erstmal so beibehalten..

Ja, wir wollen "auf den letzten Stand der Dinge" kommen, auch wenn mir du kleingeschrieben nur hier im Forum einigermaßen leicht von der Hand geht...

Bild wieder klarer?

[Schotty]

Generell wären in meiner Wahrnehmung bisher alle Anmerkungen und Änderungen ganz gut im svn aufgehoben gewesen, man sieht da auch in der Regel sehr schnell, ob es größere oder kleinere Änderungen waren usw.. (und ich gehe davon aus, dass das bei den Vorschlägen zu kap01 auch nicht anders sein wird!)

Hmpf, nun bin ich schon mit kap01, kap03 und fast mit kap09 durch - deswegen hatte ich doch gestern bei der ersten kap02-Fassung das hier geschrieben:

@Beta-User: Ich habe mir mal kap02.txt zur Brust genommen und ein paar Korrekturen, Umformulierungen und Anmerkungen (im Text mit "(ANMERKUNG v. Schotty: ...)" gekennzeichnet) vorgenommen. Rudi hat mir zwar Schreibrechte fürs SVN erteilt, aber ich hänge die Datei jetzt erstmal lieber hier an. Wie du siehst habe ich sie auch etwas umbenannt, damit du lokal bei dir nicht durchn Tüddel kommst - falls es dadurch Probleme beim Erzeugen eines Diffs gibt, sag bescheid, dann belasse ich die Dateinamen in Zukunft so, wie sie sind. Kannst es dir ja mal ansehen, ob es so für dich Sinn macht und auch mit den (ANMERKUNGEN ...) so gangbar und deutlich genug ist.

Aber egal, ich hänge kap09 jetzt gleich auch nochmal hier an und melde mich privat nochmal bei dir..

Wenn man (kurze) Schlüsselwörter für Fragen oder Anregungen verwendet ("Schotty: " "xenos: ", "xxxx: ", "link" ...), ist das sogar gut, weil ich die dann ggf. auch als Merkposten länger "mitschleifen" kann, und ihr seht in den svn-diffs auch gleich, wann es ggf. wie gelöst wurde?

Ok, dann in Zukunft nur noch 'Schotty:', also ohne 'ANMERKUNG v.'..

an dich ging die Frage: "Ist es eine gute Idee, den Leser ggf. erst mal in diese 'Falle' laufen zu lassen, um bei der Gelegenheit das Thema 'Anleitungen befolgen' auch gleich zu abzuräumen?".

Hmm, in die 'Falle' laufen zu lassen finde ich nicht so gut, ich könnte mir vorstellen, dass es User gibt, die da erstmal schwer wieder rauskommen... Also wenn es 'klar' ohne 'Falle' geht, dann imho lieber so..

Von daher wäre von deiner Seite (@Schotty) ein (überschlägiger) review von kap03 und kap09 evtl. mal ganz gut (wenn Zeit dafür ist)

kap03 ist schon oben im Anhang, kap09 kommt gleich/heute noch.