Sitzung: Jeden Freitag in der Vorlesungszeit ab 16 Uhr c. t. im MAR 0.005. In der vorlesungsfreien Zeit unregelmäßig (Jemensch da?). Macht mit!

Diskussion:Opal Syntax-Highlighting

Version vom 21. November 2005, 00:24 Uhr von Estar (Diskussion) (Format & Layout)

Ich finde die derzeitige Gruppierung nach Betriebssystemen ineffizient. Alternativvorschlag: Benutzer:Estar/OpalSyntaxTest. Einwände/Vorschläge/Flames? --estar 20:35, 20. Nov 2005 (CET)

Ich find es super das Du dir Gedanken machst wie man das Besser Präsentieren kann - ich finde aber auch das das Inhaltsverzeichnis damit im Moment mehr oder weniger wiederholt wird. Also entweder Tabelle, oder die Detaileinträge darunter, aber nicht beides.
Ich hab die Tabelle mal ein wenig vereinfacht um sie übersichtlicher zu machen - ich bin aber nicht so glücklich damit. Die Tabelle ist letztlich im Moment nur das Inhaltsverzeichnis, aber jetzt nicht mehr nach Betriebsystem sortiert (auch wenn das Prinzipiell schwierig ist, VIM und Emacs laufen natürlich auch unter OS X, etc.). Daher bin ich eigentlich dafür die Bisherige Strukturierung beizubehalten und lediglich die einzelnen Beiträge zu kürzen, also Lizenz und Homepage in einer kurzen Zeile unter der Überschrift zusammenzufassen und dann darunter den ganzen Platz für die Instruktionen zum Download und Install des Syntax-Files zu lassen - vor allem die Sortierung nach Betriebsystem (wenigstens Grob) finde ich eigentlich ganz Sinnig.--Martin Häcker 23:35, 20. Nov 2005 (CET)
Die Tabelle enthält schon mehr Information als ein Inhaltsverzeichnis (das man dann auch entfernen kann); die Sortierung der Zeilen lässt sich dann immer noch anpassen. Die Gründe für die Tabelle (und gegen ein Inhaltsverzeichnis mit Namen und grober Aufteilung nach Betriebssystemen) sind
  1. dass das Betriebssystemkriterium nicht das einzige denkbare ist (die Unterscheidungen nach Lizenzen und Architekturen sind auch interessant) und
  2. dass sogar eine grobe Aufteilung (wie im Moment in Windows- und Unixsoftware) auf Programme, die auf sehr vielen oder sehr wenigen Plattformen laufen, bestenfalls teilweise zutrifft. (Nicht alle Unixeditoren laufen auf jedem Unix, nicht alle Windowseditoren laufen auf jedem Windows und für Vim und Emacs jeweils zwei (Unix und Windows) bzw. drei (Unix, MacOS, Windows) Einträge zu haben, ist auch eine Form der Redundanz.)
<sarcasm>Allerdings finde ich das nicht im Detail wichtig, weil Vim sowieso besser ist und überall läuft…</sarcasm> --estar 01:24, 21. Nov 2005 (CET)

Was Leerräume betrifft: ich habe wenig Ahnung von Onlinetypographie und kann bei dem Thema kaum mitreden; es ist aber mit Sicherheit sinnvoller, so etwas im CSS-Code zu machen statt in der eigentlichen Seite, da

  1. CSS eine viel genauere Kontrolle über solche Sachen bietet,
  2. die CSS-Syntax besser für die Beschreibung der relevanten Eigenschaften geeignet ist und
  3. man dadurch nicht bei jeder Bearbeitung die Zeilenumbrüche zählen muss.

--estar 20:35, 20. Nov 2005 (CET)

CSS würde ich für diese Seite nicht anfassen wenn es sich irgendwie vermeiden lässt. Wir können das aber gerne Freitag in der Sitzung mal genauer klären was du hier meinst. --Martin Häcker 23:35, 20. Nov 2005 (CET)
Ich meine eigentlich nur, dass in der Wikitext-Sprache Zeilenumbrüche, Leerzeichen etc. Teil der Syntax sind; bei der Konvertierung von Wikitext nach HTML werden diese Sachen also mit umgewandelt, und zwar zu sowas wie
<p><br /></p>
was keine sinnvolle Methode ist, ein Layout anzupassen. Da nun aber jemand meint: "Freiraum ist gesund!" [1], und weil ich das als das Layout der Seite betreffend verstehe (im Gegensatz zum durch die Sprache eingeschränkten Layout des Wikitext-Quellcodes), scheint CSS die logische Wahl für die in Bezug auf "Freiraum" zu implementierenden Dinge, worum auch immer es sich handelt, zu sein. Letzteres muss aber die Person dann selbst erklären; ich habe keine Ahnung von Layout. Sofern dieses Detail geklärt wird, könnte man den erforderlichen CSS-Code schreiben und zum Beispiel mit der in [2] beschriebenen Erweiterung in diese Seite einbauen, ohne größere Kollateralschäden zu verursachen. Das ist jetzt aber natürlich rein hypothetisch. --estar 01:24, 21. Nov 2005 (CET)