[linux-l] Re: belug lernt nicht dazu!

Volker Grabsch vog at notjusthosting.com
So Nov 27 00:05:25 CET 2005


On Sat, Nov 26, 2005 at 10:07:55PM +0100, Oliver Bandel wrote:
> > Falls du mit "unbequemer Benutzung" auch die Wiki-Weboberflächen
> > meinst: die standen für mich gar nicht so im Vordergrund, da ich
> > sie ohnehin nur als "zusätzliche Option" zu den im SVN gelagerten
> > Wiki-Textdateien vorschlug.
> 
> SVN?

SVN = Subversion, eine Versionskontrolle, der Nachfolger von CVS,
wesentlich besser designt.

> > Sicher werden nicht
> > alle Syntaxdetails jedem gefallen. Aber das ist Geschmackssache,
> > bisher waren alle Wikisprachen, die ich gesehen habe, gleichermaßen
> > "einfach" bzw. "schwer". Aber zu den Sprachen weiter unten.
> 
> Vieleich wäre dann eine nutzerspezifische Syntax das richtige. :)

Erstmal nach Möglichkeit alle *bekannten* Wiki-Sprachen unterstützen.
Wenn jemand dann noch ne eigene will - bitte, soll er selbst schreiben.
Aber ja, genau das will ich mit Wikidok ermöglichen: Dass man nicht
gleich ein völlig anderes / neues Wiki braucht, bloß weil man ne
andere Sprache will, oder ein anderes Backend, oder so.

> Dann bracuht man eben eine einstellbare Syntax.
> jaja, ich weiß, den Krams will sich kein Programmierer
> unnötig aufhalsen!
> Statt dessen plagt man lieber die Benutzer mit dem, was der
> Programmierer sich im Rausch ausgedacht hat. ;-(

Auch ne Variante. Aber da es so viele syntaktische Möglichkeiten für
Wikisprachen gibt, würde das auf einen generischen Parser hinauslaufen,
und *den* zu konfigurieren, da wird sich der potentielle User nicht
ranwagen, und der Programmierer wird lieber schnell selbst sein Zeug in
lex/yacc machen. Zumal es IMHO schon genug Wikisprachen gibt. Man sollte
ähnliche Wikisprachen lieber angleichen, statt noch mehr Varianten zu
provozieren. Gerade bei den Wikisprachen ist es an der Zeit, mal
Standards zu definieren. Ich meine, es bringt doch nichts (außer
Verwirrung), wenn sich zwei Wikis nur darin unterscheiden, ob eine
Aufzählung nun mit - oder * beginnt.

> OK, das ist ja auch noch erträglich,
> wobei das zweite "=" schon zu viel Tipparbeit ist.
[...]
> Also: wenig tippen, viel erreichen - das ist dann effizientes Arbeiten.

Ja, es gibt auch Wikisprachen, die sehr tipparm sind. Schau dir
z.B. mal http://www.bephpug.de/ an. Das Wiki, das dort läuft, ist
von der Sprache her recht einfach gehalten.

> [Projekt Gutenberg]

Die Sachen ausschließlich durch Einrückung und nicht durch =, +, *, ...
zu markieren ist sicher auch ne nette Idee, aber ich kann mir nicht
vorstellen, wie dort lesbarer Quellcode rauskommen soll. Obwohl ...
in Python geht das auch recht gut ... ohne geschweifte Klammern & Co. :-)

> Überflüssige Sachen
> raus lassen. Auch ein schliessendes "=" am Ende kann da schon zu nervig sein.
> Wozu dieses denn da sein soll, ist mir unklar, kann man doch auch \n
> als Ende-Marker nehmen.

Full ACK. Aber es gibt ja viele Wiki-Sprachen. :-)


> Mit ist übrigens eingefallen, daß ich letztens einen
> Wiki mal bei jemanden in einer Firma in Aktion sah,
> der mit ein paar wenigen Klicks und dann eintippen
> der Texte alles fertig stellen konnte.
> Ohne langes suchen nach den passenden Links.
> Hätte mal nachfragen sollen, was für ein Teil das war.

Keine Ahnung, aber was du beschreibst, klingt nach der Wikipedia. :-)
Auf die Seite gehen, dann auf "bearbeiten" klicken, eintippen, fertig.

> Aber wenn der Browser mir automatisch meinen $EDITOR aufmacht,
> dann wäre das eine schöne... sehr schöne Sache.

Dann nimm doch einfach mal nen ordentlichen[tm] Browser :-)
w3m und lynx machen das so.

Und wenn du via Subversion an die Sachen rankommst, kannst du erst
recht mit jedem beliebigen Browser an die Sachen ran, und du hast
stets eine aktuelle Kopie der Seiten auf deinem Rechner.

Übrigens wäre es auch cool, wenn das im KDE-Projekt besser integriert
wäre (ist es vielleicht mittlerweile schon). Ich meine, der KDE-Editor
"Kate" wird doch sowieso überall als Komponente eingebunden. Wenn man
im Konquerer ne Seite mit <textarea...> öffnet, könnte doch in das
Feld gleich ein Kate rein.

> > Und Plugins
> > für die bisherigen Texteditoren (vi,emacs,...) - außer SVN-Plugins -
> > würden mir auch nicht groß einfallen.
> 
> Wie soll ich den Satz verstehen?

Naja, man könnte auch die Texteditoren (vi, emacs ...) mit einigen
Plugins ausstatten, sodass sie z.B. im Wiki-Quelltext die Links
zu anderen Wikiseiten entsprechend hervorheben, und man direkt diese
andere Datei öffnen kann. So ein emacs-Plugin hab ich schonmal
gesehen. Auch Subversion ist schon recht gut im Emacs integriert,
aber ich bevorzuge dennoch die Kommandozeile.  :-)

Sowas meinte ich eben. Auch sog. "Blogging-Software" wäre als
Editor-Plugin ganz nett. Also mal andersrum: Nicht den Editor
in den Browser / ins Wiki integrieren, sondern die Wiki-Funktionalität
in den Editor bringen.

Gute Ansätze gibt's da, aber ich bin mir nicht sicher, ob das wirklich
eine gute Idee ist. Da kenn ich mich nicht so aus. Ich wollte nur
erwähnen, dass es auch *diesen* Weg gibt.

> Aber aus typografischer Sicht ungünstig arrangierte
> Ausgabefenster sind das zweite Hauptptoblem.
> (Aber das trifft ja auch auf Applikationen zu, nicht nur auf Wikis.)

Ich weiß jetzt nicht genau, was du damit meinst. Kannst du ein
konkretes Beispiel nennen?

> > Ein Maßstab wäre z.B., dass die Textdatei als solche gut lesbar
> > sein soll, also nicht wie ein Quellcode, sondern wie ein Dokument
> > (z.B. ne Readme.txt) ... in dem Fall ist reStructuredText eindeutig
> > das beste, und genau solch ein Format zu unterstützen, ist das
> > explizite Ziel dieses Projektes.
> 
> Welches Projektes? Deines?

Nein, des Docutils/reST-Projektes. Siehe nächsten Absatz.

> > Dafür als Tipp: HTML generieren, und dann mit "w3m -dump ..."
> > in Text umwandeln. Ich habe damit schon gearbeitet, macht sich
> > ganz gut.
> 
> Aha, noch ein Tool das ich nicht kenne... na, egal.
> Wo nehme ich denn das html her, um text zu generieren,
> den ich dann in den HTML-/Wiki rein stecke?
> Ist das nicht doppelt-gemoppelter Blödsinn. oder habe ich gerade
> nicht verstanden, wo Du bist/was Du mir sagen willst?

Uff, also nochmal:

w3m ist ein Textmodus-Browser, d.h. unter anderem kann er HTML in
Plaintext umwandeln, durch den man dann navigiert. "w3m -dump ..."
verzichtet auf die Benutzerführung, und spuckt einem die angegebene
URL gleich als Plaintext aus.

Will man Dokumentationen generieren, hat man Eingabedateien in einer
bestimmten Sprachen, nennen wir sie:

	datei.wiki

Und man hat mehrere Ausgabeformate. Wünschenswert sind:

	datei.txt
	datei.html
	datei.tex  (--> datei.pdf)

Das *.txt kann man entweder direkt aus der Wikisprache generieren,
oder über die *.html-Datei via:

	w3m -dump datei.html >datei.txt


Ziel der reST-Sprache hingegen ist:

	datei.wiki == datei.txt

Das heißt, dass die Wikisprache (reST) gleich im "README"-Stil ist,
sodass der Wiki-Quellcode gleichzeitig eine gut aussehende Plaintext-
Datei liefert.

reST hat also den Vorteil, dass man eine Plaintext-Variante nicht
extra generieren muss, weil der Quellcode schon eine "gut lesbare
Dokumentation" ist. Außerdem hat es den Vorteil, dass man eventuell
vorhandene Textdateien fast schon als reST-Dateien vor sich hat.

Nachteil von reST ist, dass es viel mehr Tipparbeit ist, nicht nur
beim Verfassen des Textes, sondern auch später beim Anpassen der
Dokumentation.


So, ich hoffe, das ist nun geklärt.




> > Falls du da besonders neue kreative Ideen hast,
> > wäre ich sehr interessiert. Aber bisher lief alles auf Sachen hinaus,
> > die es längst gibt.
> 
> Sachen die es gibt zu nehmen kann sehr kreativ sein, wenn vorher
> niemand auf die Idee gekommen ist. :)
> 
> Nen vi statt eines Texteingabefensters eines Browsers ist
> IMHO eine kreative Idee, weil sie etwas neues einführt, auch
> wenn es eigentlich nichts neues ist.

Die Idee ist nicht neu. Siehe: w3m, lynx, mutt, slrn  :-)

> Aber bisher habe ich es noch nie erlebt, daß ich via Webbrowser
> meinen Editor benutzen kann, um Texte zu tippen.
> ( Vermutlich, weil ich vi und nicht emacs nehme, werden mir
>   die Emacs-Leute jetzt vielleicht zurufen? ;-))

Stimmt, Emacs ist ja auch nen Browser. :-)

> > Eben, genau das habe ich gerade gesagt. :-)
> > SubWiki ist ein guter Ansatz. MediaWiki übrigens auch. Und auch
> > DokuWiki. Alle haben wunderbare Ideen und bieten coole Vorteile.
> > Aber solange man diese nicht kombinieren kann, ist man an die
> > Nachteile jedes einzelnen dieser Wikis gebunden.
> 
> Was soll man dann Deiner Meinung nach machen?
> Alles zusammen koppeln, oder was neues entwickeln?

Beides. Die bestehenden Sachen besser aufdröseln (was hoffentlich
nicht allzu schwer ist), und dann noch ein paar winzige flexible
Sachen programmieren, die einem den Mist miteinander verbinden.

> Gibt es denn eigentlich eine gute Übersichtsseite, die mal alle
> Eigenschaften (Vor-/Nachteile) _klar_ gegenüberstellen?

Nicht, dass ich wüsste. "Vor-/Nachteile" sind es aber nicht, es
sind nur "Unterschiede"!

Nimm zum Beispiel mal SubWiki und MediaWiki. Subwiki arbeitet intern
mit Subversion, MediaWiki mit MySQL. Andere Wikis arbeiten mit RCS
auf Dateisystem-Basis. Was davon ist nun der "Vorteil", was der
"Nachteil"? Kann man nicht sagen. Das kommt ganz drauf an, was
man hat und was man braucht.

Zurück zum Thema: Ja, so eine Übersicht gibt es. Siehe:

	http://c2.com/cgi/wiki?ChoosingaWiki

> > Auf der anderen Seite ein Webinterface, durch das man "mal eben schnell"
> > ein paar Änderungen vornehmen kann. Jederzeit, auch im Internetcafé, mit
> > einem beliebigen Browser. Auch für Anfänger gut geeignet, die bereits
> > Wikis und/oder Webforen kennen.
> 
> Hmhhh, das erinnert mich jetzt gerade an opentheory.org: Sowohl
> Web- als auch Mailinterface... (statt entweder-oder).

Jepp. Ich finde sowieso, dass reine Webforen ungeeignet sind. Es sollte
lieber eine Mainlingliste sein, mit einem Webinterface. So hat jeder
was davon: Die Browser-Fans ihr "Webforum", die anderen ihre
Mailingliste. Wenn ich für jede Mailingliste extra täglich irgendeine
Webseite besuchen müsste ... *grusel* ...


> In den letzten Tagen geht mir wieder Literate Programming durch den Kopf....

reST hat übrigens was damit zu tun: Es ist nicht nur *in* Python
geschrieben, sondern auch *für* Python.

In Python gibt es ja Docstrings, und wenn die mal größer werden
(mehrere Absätze), dann sollte man sich an reST halten. (was man
intuitiv wahrscheinlich sowieso tut, wie bei E-Mails :-)).

Einige der Python-Tools zum Erstellen von Dokumentationen verwenden
nämlich bereits die Docutils. Das aber nur am Rande. Mehr Infos
findest du auf:

	http://docutils.sourceforge.net/docs/peps/pep-0287.html

> [...]
> > Analog dann die Berlinux-Suche:
> > 
> > > docfind -ititle=".*"berlinux.*|.*vorbereitung.*" \
> > >          -searchcategories=web,ftp -doctype=html,pdf \
> > >          -reportformat=text
> > 
> > Was hältst du von obigem Ansatz? Dann wäre dein docfind
> > quasi ein
> > 	alias docfind='httptool http://www.belinux.de/search'
> > oder so ähnlich.
> 
> Kenne httptool nicht, denke aber (Deinem bischen Code entnehmend)
> lautet die Antwort "nein".

Das war ne Erfindung. Genau wie dein "docfind". Nur eben
allgemeiner.

	httptool http://www.google.de/search --q="Suchstring"

würde dann an "http://www.google.de/search" per HTTP-GET oder -POST
den entsprechenden CGI-Parameter übermitteln. So war meine Idee.

Wenn die Ausgabeseite dann durch "w3m", "lynx" oder "w3m -dump" gejagt
wird, wäre das IMHO ein sehr nettes allgemeines Tool für Remote-
Zugriffe und -Suchanfragen, genauso wie du es haben wolltest.

> Aber da müsstest Du noch etas mher zu httptool sagen.
> Google bringt mir nur Müll.

War ja nur ein Beispiel. *Zusätzlich* müsste es natürlich entsprechende
Suchmöglichkeiten auf den jeweiligen Servern geben. Ich meinte nur,
dass man dafür keine extra "Shell" oder ein neues Protokoll erfinden
muss, bloß um es von Kommandozeile aus bedienen zu können. HTTP reicht
völlig aus.

> Ne, schau mal nach "LAPIS" (leider in meiner garnicht-Freude
> Programmiersprache implementiert...) die Features fehlen
> im vi noch. ;-)

Wahrscheinlich wird es sie eher im Emacs als im VI geben. Aber du
hast recht: Ne schöne Sache.

> > Wiegesagt, vielleicht gibt's die
> > sogar schon.
> 
> LAPIS anschauen.
> 
> Dann dieses Konzept serverseitig auf Suchmaschine aufsetzen.
> DAS ist ein Bringer! :)
> 
> Selbstverständlich dann auf Clientseite eben auch solche
> Features haben (also guten Browser/Editor).

Stimmt. Das wäre nett. Ein guter, aber leider auch sehr, sehr
aufwändiger Vorschlag.

> [...]
> > Die Ideen und die Ausdrucksfähigkeit von jedemanden zu kritisieren,
> > ist übrigens IMHO genau das gleiche, wie seine Software zu kritisieren.
> > (weil dort sehr ähnliche Fähigkeiten gefordert sind ... nur das einmal
> > in einer Maschinensprache, das andere Mal in einer menschlichen)
> 
> Du stellst Menschen und Maschinen auf die selbe Stufe.
> Katastrophal!

Nein, ich behaupte lediglich, dass die Fähigkeit zur klaren Ausdrucksweise
nicht viel mit der konkreten Sprache zu tun hat.

Egal, ob es sich
* um eine natürliche Sprache (Deutsch, Englisch),
* um eine sehr formalisierte menschliche Sprache
  (Mathematik, Juristen-Deutsch)
oder
* um eine Computer-Sprache (C, LaTeX, SQL, ...)
handelt.

Anders ausgedrückt: Die Fähigkeit, gut verständliche und sauber
strukturierte Programme zu schreiben, ist sehr stark verwandt mit der
Fähigkeit, sich klar auszudrücken und seine Gedanken anderen zu
vermitteln.

Dein heißgeliebtes "Literate Programming" ist doch gerade ein Produkt
dieser Erkenntnis, dass man natürliche Sprache (Kommentare,
Dokumentation) und Programmcode näher zusammenbringen möchte.
Aus Gutem Grund. [tm]  :-)

Wenn ich deine Argumente kritisiere, ist das genauso "schlimm", als
wenn ich deine Software kritisiere. Das hat bis dahin noch *nichts*
mit irgendeiner "Gleichstellung" von Mensch und Maschine zu tun.

Wenn ich Software kritisiere, kritisiere ich ja nicht die Maschine,
auf der das Ding läuft, sondern den, der das geschrieben / designt
hat.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste linux-l