Hilfe Diskussion:Syntaxhighlight/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Hilfe Diskussion:Syntaxhighlight/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Hilfe_Diskussion:Syntaxhighlight/Archiv/1#Thema_1

Obskure Sprachen?

Einige der Sprachen, genauer: Sprachkürzel, sind mir nicht geläufig. Wäre es möglich, diese (soweit vorhanden) auf den zugehörigen Wikipedia-Artikel verlinken zu lassen? --RokerHRO 12:03, 16. Aug. 2007 (CEST)

Hab' mal ein paar verlinkt. --84.191.90.87 20:26, 21. Okt. 2007 (CEST)

Prima, danke für die Mühen! :-) --RokerHRO 21:32, 21. Okt. 2007 (CEST)

Wikipedia

Gibts sowas auch für Wiki-Code? --Markus 14:23, 21. Okt. 2007 (CEST)

AutoHotkey

Ich vermisse die Syntax-Hervorhebung für die Skriptsprache AutoHotkey und würde gerne helfen, sie hinzuzufügen. Geht das bzw. was muß ich dazu tun?

Hier kannst du leider nichts direkt tun, da MediaWiki das externe Programm GeSHi Syntax Highlighter einsetzt. Nur was dort unterstützt wird, kann auch hier verwendet werden. — Raymond ^{Disk. Bew.} 20:53, 15. Mär. 2008 (CET)

Danke für den Tip! Auf der GeSHi-Homepage ist beschrieben, wie man eine Sprachdatei erstellt. Vielleicht werde ich das machen und dann den Autor kontaktieren. -- Gort 08:41, 23. Mär. 2008 (CET)

Anpassungen

Der Link hilft mir nicht viel weiter. Gibt es Beispiele für benutzereigene Geshi.css-Dateien? Ich möchte meine gern anpassen, weil mir einige Farben der Standardausgabe stören. Bitte um Hilfe: Wo muss ich die Geshi.css anlegen und wie muss sie ausschauen? --Dagobert Drache 20:06, 12. Sep. 2008 (CEST)

Eine Geshi.css kannst du nicht für dich persönlich anlegen, die kann es nur für das gesamte Projekt geben. Du kannst aber in deiner Monobook.css die Ausgabe für dich persönlich modifizieren. Schau mal uner en:MediaWiki:Geshi.css, ob dir die Anpassungen der englischsprachigen Wikipedia gefallen. — Raymond ^{Disk. Bew.} 22:30, 12. Sep. 2008 (CEST) 

Wunderbar, danke für den Hinweis! --Dagobert Drache 20:30, 13. Sep. 2008 (CEST)

Größe des Kastens

Ich bin mir nicht sicher, ob das ein Problem der Erweiterung oder der CSS ist: Der Rahmen reicht immer bis zum rechten Rand der Seite, auch wenn dort noch andere div-Elemente (wie etwa ein Bild-Thumbnail, eine Navi-Leiste o. ä.) positioniert sind. Dies kann dazu führen, das Boxen sich überschneiden. Tatsächlich sieht man das gleich oben auf dieser Hilfeseite. Wäre eine der Zeilen des "Hallo Welt"-Beispiels sehr lang, würde sie hinter der Hilfenavigation verschwinden. --Hk kng 16:42, 19. Nov. 2008 (CET)

strict

Auf der MediaWiki Seite dazu ist noch das strict Attribut angegeben. Was macht es? --FUZxxl (Diskussion) 12:23, 7. Dez. 2008 (CET)

Hilft Dir das weiter? Gruß --W_I^KImaniac 13:19, 7. Dez. 2008 (CET)

Nicht sonderlich. Ich habs noch nicht ganz verstanden. --FUZxxl (Diskussion) 17:46, 7. Dez. 2008 (CET)

Generelles Highlighting

Weis Jemand wo man weitere Sprachen "beantragen" kann?
Ich denke z.B. an generelles Highlighting für Config-Dateien (Wie bei Emacs conf-mode oder ft=conf bei Vim).
Highlighting für Makefiles währe auch toll.
Wenn ich wüßte wie es geht, würde ich es gerne selber machen, aber ich denke nicht, dass ich so einfach eine Sprache zu den Sprachen die der <source>-Tag kennt hinzuzufügen. 85.179.236.225 20:25, 20. Dez. 2008 (CET)

Wir nutzen den GeSHi-Highlighter http://qbnz.com/highlighter/ Nur was dort an Sprachen vorhanden ist, wird dann auch hier unterstützt. Wobei die Server der Wikimedia-Foundation eine Version < 1.0.8 verwenden, denn per Bugzilla:10967 hat schon jemand ein Update auf 1.0.8 angefragt. — Raymond ^{Disk. Bew.} 20:44, 20. Dez. 2008 (CET)

Highlighting von \" bei Javascript

Bei der Escape-Sequenz für das doppelte Anführungszeichen (\") gibt es ein highlightingproblem. Das Anführungszeichen wird als Beginn einen normalen Strings interpretiert, obwohl es dies nicht ist, da es escaped wurde. Dies kann bei Anwendung in RegEx passieren, da diese nicht in Anführungszeichen eingeschlossen werden.

Ein einfaches fehlerhaftes Beispiel:

\"\"text
"text"
text

und ein korrektes Beispiel:

"\"\"text"
"text"
text

Ich weiß nicht, wo das gemeldet werden muss (bugzilla oder bei GeSHi-Highlighter direkt), würde mich aber freuen, wenn dies jemand übernehmen könnte. Das highlighting verunstaltet in der Form die javascript-skin-seiten (monobook.js usw) enorm. Ich hoffe es ist nachvollziehbar. Der Umherirrende 19:07, 10. Jan. 2009 (CET)

siehe bugzilla:10967. Gruß --P.Copp 00:15, 12. Jan. 2009 (CET)

Also hat es mit einer alten Version zu tuen. Danke. Jetzt müsste ein Serveradmin das nur noch umsetzen. Aber nach über einem Jahr braucht man sich auch nicht viel hoffnung zu machen. Mal schauen, was die Zeit so bringt.Der Umherirrende 19:49, 12. Jan. 2009 (CET)

Enclose

Gibt es neuerdings gar kein Kästchen mehr um Source-Blöcke?? Was für ein Sinn macht dann eigentlich das Enclose-Attribut? --alexrk 18:42, 28. Jun. 2009 (CEST)

Hallo alexrk, das ist ja seltsam, Spezial:Vorlagen expandieren nimmt die Darstellung mit Kästchen vor, anderen Seiten nicht. Gruß --W_I^KImaniac 19:01, 28. Jun. 2009 (CEST)

Also ein Bug oder ein Feature? ;) Ich finde jedenfalls die Version mit Kästchen bedeutend übersichtlicher. --alexrk 19:16, 28. Jun. 2009 (CEST)

Schriftgröße

Lässt sich die Schriftgröße eigentlich einstellen? Bei machen Farben lässt sich der Code ja kaum noch vom Staub auf meinem Bildschirm unterscheiden.
(nicht signierter Beitrag von JoachimG (Diskussion | Beiträge) 10:58, 7. Feb. 2010 (CET) – SignaturNachtrag 2010-02-07 11:46)

So beispielsweise:

<div style="font-size:130%">
HIER SOURCE-BLOCK DENKEN
</div>

--ParaDoxa 11:24, 7. Feb. 2010 (CET)

Oder, vermutlich was du eigentlich wolltest, beispielsweise mittels folgender Zeile in deiner monobook.css:

.mw-geshi { font-size:130% !important; }

--ParaDoxa 11:44, 7. Feb. 2010 (CET)

Vielen Dank, aber ich hatte eine Möglichkeit gesucht, die Schriftgröße auf eine vorhandene Sprach-Source anzuwenden. EckigeKlammerAuf source lang="sql" style="font-size:130%" EckigeKlammerZu geht jedenfalls nicht.--JoachimG 15:47, 7. Feb. 2010 (CET)

Ja, aber beispielsweise das erste <source>-Beispiel auf der Hilfeseite generiert folgenden HTML-Code, in dem noch weitere CSS-Klassen innerhalb class="mw-geshi" vorkommen, beispielsweise class="php source-php", woraus ich schließe, dass es class="sql source-sql" usw. wahrscheinlich auch gibt. Mit ein wenig Versuch und Irrtum lässt sich höchstwahrscheinlich der gewünschte Effekt finden.

<div dir="ltr" class="mw-geshi" style="text-align: left;">
<div class="php source-php" style="font-family: monospace;">
<pre class="de1"><span class="kw2">&lt;?php</span>
  <span class="kw1">echo</span> <span class="st0">"Hallo Welt!"</span><span class="sy0">;</span>
<span class="sy1">?&gt;</span>
</pre></div>
</div>

--ParaDoxa 16:51, 7. Feb. 2010 (CET)

Verbale Umschreibung eines fehlenden Code-Teils

Hallo, mir ist gerade aufgefallen, dass in Temporale Datenhaltung seit Umstellung auf das Source-Tag "Bedingung(en) zum Ausschluss derselben Zeile IN x und y" etwas glücklos formatiert wird. Gibt es eine einfache nette Lösung für diese Problem? Viele Grüße --Cactus26 07:04, 16. Feb. 2010 (CET)

Ungültiges Archivierungsziel

Die Zielangabe bei der automatischen Archivierung dieser Seite ist ungültig. Sie muss mit demselben Namen wie diese Seite beginnen. Wende dich bitte an meinen Besitzer, wenn das ein Problem darstellen sollte. ArchivBot (Diskussion) 07:22, 1. Mai 2012 (CEST)

erledigtErledigt Harry8 10:14, 1. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Geitost 21:05, 2. Nov. 2012 (CET)

Bug bei Kommentaren und Fettschrift

Ich habe folgenden Code:

1. // The comments come before the package
   package pkg;
   import java.awt.*;
   class C{}
   

2. package pkg;
   import java.awt.*;
   class C{}
   

Beim ersten Beispiel ist "package" nicht fett, beim zweiten ist es fett. Eigentlich sollte es bei beiden fett sein. --Sebastian.Dietrich ✉ 10:31, 5. Mär. 2011 (CET)

Wie man hier testen kann, liegt der Fehler bei dem verwendeten Highlighter und nicht direkt in MediaWiki, du müsstest den Fehler also dort melden. --Schnark 11:39, 5. Mär. 2011 (CET)

Archivierung konnte nicht durchgeführt werden

Beim Botlauf um 04:18, 3. Nov. 2012 (CET) wurden fehlerhafte Optionen in der Vorlage 'Autoarchiv-Erledigt' festgestellt. Beachte bitte die Dokumentation der Vorlage und korrigiere den Fehler. Bei Unklarheiten kannst du Euku fragen. Gruß --SpBot 04:18, 3. Nov. 2012 (CET)

erledigtErledigt MfG Harry8 09:31, 3. Nov. 2012 (CET)

Syntaxhighlight für Mediawiki

Mal ne ganz blöde Frage, aber warum fehlt eigentlich ausgerechnet Syntaxhighlighting für den Mediawikicode? Das wäre für die Hilfeseiten doch hier und da ganz praktisch... --Sepp (Diskussion) 09:29, 25. Feb. 2014 (CET)

Die Frage ist nicht blöd; sie trifft ein Grundproblem der Wikisyntax.

Grundsätzlich wäre das lang="text".

Darüberhinaus ist ein Highlighting an feste, weltweite Regeln gebunden.

• Diese werden von einer formalen Programmiersprache einer bestimmten Versionsfamilie weltweit einheitlich erfüllt.
• In der Hilfe:Wikisyntax #Formale Sprache? ist das Problem weiter umrissen.
• Jedes Sprachelement ist vielfach interpretierbar.
• Die Interpretation liegt auch in lokalisierten Schlüsselwörtern, die sich laufend und in jeder Sprache ändern können.
• In der Vorlagenprogrammierung müssen die Elemente noch nicht einmal vollständig sein; jede Vorlage und Einbindung und Programmierung kann Klammern zuliefern.

Kurze Antwort: Weil Wikisyntax keine formale Sprache ist; und ein paar Anläufe mit WP:wikEd und WP:Technik/Text/Edit/AceWikiEditor haben Möglichkeiten und Grenzen demonstriert. Mit CSS-Regeln allein kommt man nicht sehr weit; denke an <nowiki>.

LG --PerfektesChaos 10:32, 25. Feb. 2014 (CET)

C++11

Ich wollte mal auf diese Diskussion Wikipedia_Diskussion:Redaktion_Informatik#Manuelles_Highlighting hinweisen. Knackpunkt ist wohl, dass C++11 einige neue Schlüsselwörter besitzt, die der aktuelle Syntaxhighlighter nicht kennt, was einen Benutzer dazu veranlasst hat, wegen zwei falsch formatierter Wörter alles manuell zu formatieren. Weiß irgendjemand, ob da entsprechende Aktualisierungen des Moduls schon geplant sind bzw. wo man da meckern kann bzw. muss? --KMic (Diskussion) 02:02, 23. Apr. 2012 (CEST)

• Der langfristig wichtigere Schritt wäre upstream: sourceforge.net mit Erinnerung an C++11 und die konkret benannten zusätzlichen Schlüsselwörter vom Oktober 2011 (last Update: Februar 2011).
  • Die dortigen Formatierungs-Informationen werden gelegentlich manuell in die Mediawiki-Welt importiert. Zurzeit auf dem letzten Stand.
• Zusätzlich kannst du auf bugzilla allgemein darüber informieren, was du bereits unternommen hast.
  • Du kannst dort jemand dazu verführen, als temporären workaround cpp.php entsprechend anzuflicken. Viel Erfolg!
• Der zurzeit wenig aktive Benutzer:BenBE1987 könnte einen shortcut bieten.
• Wenn du keinen der genannten Wege selbst nutzen möchtest, dann teile dies hier einfach mit; mitlesende Kollegen der WD:NEU werden das dann schon weiterleiten.

Beste Grüße --PerfektesChaos 09:16, 23. Apr. 2012 (CEST)

Danke für die schnelle Antwort. Also wenn irgendjemand das weiterleiten könnte, wäre das natürlich super und ich würde mich auch garnicht wehren. ;-) Grüße, --KMic (Diskussion) 11:42, 23. Apr. 2012 (CEST)

@KMic:

Es wurde nicht konkret angegeben, um welche Schlüsselwörter es sich handeln solle.

http://sourceforge.net/p/geshi/feature-requests/143/ 143 Add new keywords for C++ and C# language vermeldet eine Aktivität für 2013.

Bitte prüfe, ob du mit deinem Wunsch dort eingefädelt bist. Willst du Butter von den Behörden, schicke Milch auf den Dienstweg.

LG --PerfektesChaos 11:49, 3. Apr. 2014 (CEST)

Frage zum Syntaxhighlight

Hallo!

Ich würde gerne wissen, ob man irgendwo einsehen kann, wie das Syntaxhighlight funktioniert, damit man das Skript eventuell selbst verwenden kann. Gibt es irgendeine Wikipedia Seite, wo die sprachenspezifischen Skripte zu finden sind?

Vielen Dank im Voraus!

--Timde (Diskussion) 10:16, 3. Apr. 2014 (CEST)

@Timde:

Ich habe dich mal unten angehängt; in der Wikipedia-Diskussion ist chronologische Folge üblich.

Der umseitige Einleitungssatz führt dich auf GeSHi und dieser Artikel auf verschiedene URL, mit denen man sich irgendwo auch bis zu den Syntaxdefinitionen einzelner Sprachen und dem ausgeführten Quellcode durchnavigieren kann, und wie sich das woanders nutzen ließe. mw:Extension:SyntaxHighlight GeSHi leistet das ebenfalls.

Liebe Grüße --PerfektesChaos 11:41, 3. Apr. 2014 (CEST)

Falsches Attribut-Format im Tag

Oha, kleine Ursache große Wirkung: Wie oder anders, könnte man so etwas überhaupt abfangen?
[…] Der Ausdruck <syntaxhighlight lang="lisp"style="white-space:nowrap" inline>(+ #.(print 10) 20)</syntaxhighlight> beispielsweise gibt nicht nur bei seiner Ausführung 30 zurück, […]

Mein WSTM, müsste ich eigentlich dort melden, macht nämlich daraus noch mehr Murks.

[…] Der Ausdruck [hier wird ein Umbruch gesetzt] <syntaxhighlight lang="lisp" style="white-space:nowrap" inline> [hier wird ein Umbruch gesetzt] (+ #.(print 10) 20) [hier wird ein Umbruch gesetzt] </syntaxhighlight> [hier wird ein Umbruch gesetzt]

beispielsweise gibt nicht nur bei seiner Ausführung 30 zurück, […]

Ich hätte den Fehler aber vermutlich sonst nicht so schnell gesehen, weil das auf den Ersten Blick normal aussieht, und man so ein fehlendes Leerzeichen nicht sofort erkennt. Aber natürlich gab es zusätzlich eine eindeutige Fehlermeldung – zumindeest im zweiten Teil (Falsches Attribut-Format im Tag <syntaxhighlight style="white-space:nowrap" inline [??? …] Falsches Attribut-Format im Tag <syntaxhighlight lang="lisp"style="white-space:nowrap" inline). Erkannt wurde es, aber die automatische Anpassung wirft Fragen auf. --Liebe Grüße, Lómelinde Diskussion 08:53, 9. Okt. 2015 (CEST)

OT: siehe Report.

• In der Tat, das ist ein Fall für WSTM.
  • Das fehlende Leerzeichen nach dem " hatte verhindert, dass die Parameter erkannt wurden.
  • Derjenige, der das verträumt hatte, dürfte ich gewesen sein; egal, wann und wo.
• Ohne Parameterliste wird auch inline nicht erkannt.
  • Normalerweise wäre das egal, aber wenn bei syntaxhighlight kein inline gefunden wird, dann wird das gnadenlos als eigener Block formatiert; deshalb die Zeilenumbrüche.
• Zu machen ist da eher wenig.
  • Es ist ja Absicht, dass sich der menschliche Bearbeiter die Parameterliste nochmal anguckt; es könnte ein C&P-Fehler sein, das " ist vielleicht vergessen worden zu escapen, das soll alles irgendwie anders interpretiert werden als es momentan für WSTM aussehen könnte, wenn man sich whitespace dazudenkt.
  • Deshalb möchte ich hier auch den Code nicht ändern.

LG --PerfektesChaos 14:58, 9. Okt. 2015 (CEST)

Ne, musst du auch nicht, ich habe es ja wieder hinbekommen. --Liebe Grüße, Lómelinde Diskussion 15:10, 9. Okt. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:47, 9. Okt. 2015 (CEST)

Bug

Es scheint, dass dieser zuweilen Aussetzer mit dem Rendern hat!? Mir scheint hier eine Kombination mit dem Pipe-Zeichen, siehe die ersten 3 Bsp. hier (auch in nicht html). Dabei ist mir noch ein Fehler aufgefallen, die Fehlermeldeung empfielt immer noch das lange überholte <source>-tag. ↔ User: Perhelion 13:13, 10. Nov. 2014 (CET)

• Ich weiß nicht, welches das 3. Beispiel ist. Da müsstest du schon etwas content releasen.
• Bugs gibt es. Sie liegen in den RegExp. Es gibt auch Bugzilla, der sich aber nach upstream durchkämpfen muss.
• Wenn du Änderungswüsche an einer Fehlermeldung hast, so ist es üblich, die MW-ID zu benennen; und wenn du die hast, darfst du gerne einen Nachtrag an WP:A/A #MediaWiki et al. schreiben und nett von mir grüßen.

LG

(nicht signierter Beitrag von PerfektesChaos (Diskussion | Beiträge) 13:25, 10. Nov. 2014 (CET))

Danke der Info, ich habe das Problem zum HTML jedenfalls ergründen können (da ich schon aussetzer mit Gnuplot Code gesehen habe und) die style attribute schön gerendert werden, liegt es wohl einfach daran dass die tag fehlen. ↔ User: Perhelion 13:30, 10. Nov. 2014 (CET)

Unterstützung von Logo?

Hallo,

ich habe gerade das Wikibook Algorithmensammlung in Bezug auf Syntaxhervorhebung überarbeitet und bin darüber gestolpert, dass die Programmiersprache Logo von diesem Werkzeug nicht unterstützt wird. Wäre schön, wenn die Unterstützung von jemandem, der sich mit der Sprache auskennt, hinzugefügt werden würde. Und welche Syntaxhervorhebung ist die beste für "Basic C64"? Danke! (nicht signierter Beitrag von 79.245.173.245 (Diskussion) 23:10, 28. Feb. 2015 (CET))

Zu Logo: Hier in der Wikipedia, auf Wikibooks etc wird ein Fremdprogramm verwendet. Wir haben hier also keinen Einfluss darauf, welche Programmiersprachen unterstützt werden. Auf der Seite http://qbnz.com/highlighter/ solltest du fündig werden, an wen du dich mit deiner Bitte um Unterstützung wenden kann. — Raymond ^Disk. 10:27, 1. Mär. 2015 (CET)

Standardschriftgröße

Die Standardschriftgröße ist IMHO zu groß. Sie sollte der des normalen Textes ungefähr entsprechen. Lässt sich das machen? -- Wolfgang Rieger (Diskussion) 12:43, 4. Jun. 2015 (CEST)

Du kannst es dir persönlich einrichten; ansonsten entspricht syntaxhighlight gerade dem code und alle beide haben dieselbe Schrifthöhe wie aller umgebender Text der Seite. Es gibt aber Browser-Einstellungen, die monospace in 14px anzeigen und Proportional in 12px. Von Rumbauerei für alle Benutzer würde ich dringend abraten; man muss hier l und I und 1 sauber und auf den ersten Blick unterscheiden können. LG --PerfektesChaos 12:55, 4. Jun. 2015 (CEST)

Ups! Tschulligung! Irgendwann mal war die Schriftart viel zu winzig, ich hatte in meiner common.js nachjustiert und das dann völlig vergessen. Sorry. In der Standardeinstellung ist die Schriftgröße jetzt ok. Zu doof zum … Beste Grüße + Dank -- Wolfgang Rieger (Diskussion) 16:20, 4. Jun. 2015 (CEST)

Strukturierter Text – Seite mit Syntaxhervorhebungsfehlern

Scheinbar funktioniert lang="scl"

<syntaxhighlight lang="scl">
IF (MASCHINE_EINGESCHALTET = TRUE) THEN
  AUSGANG1 := EINGANG1 AND EINGANG2;
ELSE
  AUSGANG1 := FALSE;
END_IF;
</syntaxhighlight>

nicht mehr. --Liebe Grüße, Lómelinde Diskussion 07:52, 8. Okt. 2015 (CEST)

Gleiches scheint auch für „e“ zu gelten.

<syntaxhighlight lang="e">
   PROC main()
      WriteF('Hello, World!')
   ENDPROC
</syntaxhighlight>

Das wird ebenfalls seit heute in dieser Kategorie gelistet. --Liebe Grüße, Lómelinde Diskussion 07:56, 8. Okt. 2015 (CEST)

Habe ich aus der Liste ausgetragen. Wieso laufend Sprachen wegfallen verstehe ich aber nicht. --mfb (Diskussion) 11:48, 8. Okt. 2015 (CEST)

Prima, ich verstehe das noch weniger, aber ich habe die Anzahl der Seiten in der Kat ein wenig im Hinterkopf und kleine Fehler kann ich auch anpassen, aber da weiß ich dann nicht, was ich tun soll. Möglicherweise funktioniert es irgendwann wieder. --Liebe Grüße, Lómelinde Diskussion 11:53, 8. Okt. 2015 (CEST)

Das Thema Syntaxhighlight steht hinten auf meiner Tagesordnung; es ist mir nicht klar, warum die beiden plötzlich aufschlagen. Ich warte ab, bis die in den anderen Projekten gemeckert haben, und arbeite dann alles bei Gelegenheit im Zusammenhang ab. Wird dann eine größere Nummer; muss warten.

• An Auszeichnungssprache war ich auch schon vergeblich dran und konnte nichts Unerlaubtes finden.
• @Ló: Du kannst die ja mal auf deinen Spielwiesen solange durch fortgesetzte Halbierung durchprobieren, bis du den einzelnen Auslöser identifiziert hast; vielleicht gibt es aber keinen.

LG --PerfektesChaos 12:55, 8. Okt. 2015 (CEST)

O.k. werde ich mal machen. --Liebe Grüße, Lómelinde Diskussion 13:01, 8. Okt. 2015 (CEST)

@PerfektesChaos: So gefunden aber du musst jetzt prüfen, dass ich nichts zerschossen habe, weil da kamen ein paar Fragezeichen die mir WSTM beschert hat, und ich bin nicht sicher ob die Anpassung meinerseits überall so richtig ist.

Ist es eigentlich egal ob ich lang="css" oder lang="CSS" schreibe? --Liebe Grüße, Lómelinde Diskussion 13:44, 8. Okt. 2015 (CEST)

„Seitenbescpreichungssprache“ ist Seitenbeschreibungssprache.

Was WSTM-Fragezeichen sein sollen, weiß ich nicht; aber inline ist ein „wertloser“ Parameter von <syntaxhighlight> und nicht von <span>.

Definiert sind Kleinbuchstaben; momentan funktionieren auch Großbuchstaben. Wo es gerade auffällt, besser einheitlich auf Kleinbuchstaben umstellen.

LG --PerfektesChaos 13:53, 8. Okt. 2015 (CEST)

Na ja so Fragezeichen halt „inline="???"“ oder „??????“ bei <font color=""> in dem Zitat, keine Ahnung was das bewirken soll oder ob das zum Zitat gehörte. --Liebe Grüße, Lómelinde Diskussion 14:01, 8. Okt. 2015 (CEST)

<font color=""> ist veraltet für <span style="color:SinnvolleAngabe"> und ohne Farbwert geistlos.

<span> hat keine „wertlosen“ Parameter. Damit ist <span inline> falsch; zu line und inline umseitig.

Und warum steht das jetzt nicht mehr in der Wartungskat, obwohl sich an den <syntaxhighlight> nichts geändert hatte und ich es mit Intensivpurgen nicht loswurde?

Brav. --PerfektesChaos 14:08, 8. Okt. 2015 (CEST)

Wegen des fehlenden " vor css. Kannst du testen Wenn du irgendwo beispielsweise auf der Spielwiese <syntaxhighlight lang=css" inline>…</syntaxhighlight> einfügst und auf die Vorschau klickst reicht das schon. Frag mich nicht, wie ich das gefunden habe. Aber da WSTM daraus folgendes gemacht hat <syntaxhighlight lang='css"' inline>…</syntaxhighlight> ist mir das irgendwie beim Durchsuchen nach einem möglichen Schreibfehler im Parameter „lang“ ins Auge gesprungen. Ja ich habe inzwischen die zitierte Seite aufgerufen und festgestellt, dass es zum Zitat gehört aber nicht angezeigt wurde. Und das Siehe auch baue ich nicht wieder ein, das ist bereits mehrfach im Fließtext verlinkt. --Liebe Grüße, Lómelinde Diskussion 14:16, 8. Okt. 2015 (CEST)

Da kannste mal sehn, wie wichtig es ist, dass WSTM die Parameterwerte analysiert und in delimiter einschließt.

Als Teil eines zeitgenössischen Zitats ist ein <font color="..."> okay; der Autor wollte den Vorteil zentraler Definitionen vor Einzelzuweisungen herausarbeiten.

LG --PerfektesChaos 14:40, 8. Okt. 2015 (CEST)

Ja du weißt doch auch so, dass ich gern damit arbeite. Wass’n das „delimiter“? Kram in meiner Erinnerung, irgendwann hatte ich mal Latein. De =„von, von herab“ hier wohl eher „ab- … von“, Limit = Limes = „Begrenzung“, –er = pluralisierendes Suffix. Argh, jaha ich habe vorhin nach dem Begriff für diese Dinger gesucht, menno. Woher weißt du das?

So ich habe noch einen, „pcre“ könnt ihr auch mal umtopfen.

<syntaxhighlight lang="pcre" inline>…</syntaxhighlight> „it’s the same“ Siehe →Regulärer Ausdruck.

Meine bescheidene Frage bleibt, soll ich das ändern oder so lassen und geduldig warten, bis es eventuell mal in ferner Zukunft wieder geht oder auch nicht geht? --Liebe Grüße, Lómelinde Diskussion 18:28, 8. Okt. 2015 (CEST)

Wo Codes im Moment fehlen, so belassen und auch in der Wartungskat drinlassen, damit man weiß, wo nachzuarbeiten wäre.

• Im Prinzip kann ich mich da einlesen und beim Lieferanten eine Definition zu RegExp abladen, die dann irgendwann bei uns wirksam wird. Habe aber null Zeit dazu.
• Vielleicht macht das inzwischen jemand anders, insbesondere enWP.

Wenn du wieder einen solchen Syntaxfehler findest: Fein; ansonsten belassen, ich guck irgendwann mal, ob es vielleicht Sprachen mit vergleichbarer Syntax gibt.

• Kategorie schadet ansonsten niemand.

Woher ich delimiter kenne (siehe dort, letzter Punkt bei den Beispielen? Naja, ist mir halt seit dreißig Jahren geläufig; keine Ahnung wo zuerst.

• Weiterbildung: Originalliteratur.

LG --PerfektesChaos 22:52, 8. Okt. 2015 (CEST)

O.k. normale Fehler wie dort, falls ich sie den sehe anpassen andere nicht anrühren. Kann ich mir merken, denke ich. Und neue Verluste melden. Die Kat ist ja recht überschaubar und, na ja, ich bin halt neugierig. --Liebe Grüße, Lómelinde Diskussion 06:44, 9. Okt. 2015 (CEST)

Weitere Ausfälle

<syntaxhighlight lang="intercal">
irgendein Code
</syntaxhighlight>

„Intercal“ wird scheinbar seit heute auch nicht mehr unterstützt. Sehe gerade, die gab es auch vorne gar nicht. Hmm … Was nun in lang="text" ändern?

pcre <syntaxhighlight lang="pcre" inline>…</syntaxhighlight> steht noch bei den unterstützten, ist aber auch raus. --Liebe Grüße, Lómelinde Diskussion 09:07, 15. Okt. 2015 (CEST)

Neuer Ausfall lang="Euphoria" scheint nicht mehr zu funktionieren, das müsste auch umsortiert werden, angewandt in Euphoria (Programmiersprache). --Liebe Grüße, Lómelinde Diskussion 17:02, 19. Dez. 2015 (CET)

pycon ≠ ≈ = python

Nur so weil das für mich nun gar nicht assoziativ aussieht, aber da es tatsächlich funktioniert frage ich mich wozu dient diese Hervorhebung {{?}} ist ja eher eine Abschwächung. Ich frage weil ich gerade mal wieder einen solchen Fehlerfall hatte und zunächst stutzig wurde, weil ich „python“ im Artikel fand und als ich hier auf die Hilfeseite kam zunächst „pycon“ las. Verwundert da ich zumindest den Python als Programmiersprache namentlich kenne. Dass der Fehler gar nicht an der Stelle zu suchen war sah ich aber, da es ja ordnungsgemäß bunt eingefärbt def bankersAlgorithm(E,A,C,R): while … for … in wurde. Trotzdem hat es bei mir einige Fragezeichen hinterlassen. Also den Fehler habe ich auch so behoben nur der Eintrag in der Tabelle vorn verwirrte mich total. PyCon klingt für mich eher wie eine Veranstaltung. --Liebe Grüße, Lómelinde Diskussion 09:25, 27. Mär. 2016 (CEST)

pygments.org bietet Aufschluss und zeigt auch, was passieren muss, damit es nicht grau in grau wird.

Das „py“ in pygments.org ist übrigens auch aus dem selben Terrarium entfleuchtes pigment (= Farbe, die es ins Spiel bringt).

Nebenbei: Die Tabelle, genauer die drei Tabellen nebeneinander gehen mir auf den Keks. Ich kann sie nicht nach Klarnamen der Sprache sortieren, und die Zeilenumbrüche behindern bei der Verständlichkeit, und mehrere ID für denselben Effekt sind mangels horizontaler Linien nicht erkennbar, und ich beabsichtige eine Erweiterung des Informationsgehalts und damit breitere Zellen. Und das Einklappen ist ohnehin witzlos; niemand kommt in eine Situation, in der ihm das dann noch weiterhelfen würde.

• Wenn du dich mal langweilst, und da du ja schon regelmäßig mit den Dingern rummachst: Würdest du ein von mir strukturiertes Untervorlagenkonzept aus- und mit Leben erfüllen wollen?

LG --PerfektesChaos 10:46, 27. Mär. 2016 (CEST)

Das kann ich gern tun, so nach Ostern. Ja warum das klappbar sein sollte hatte ich mich auch schon gefragt. Danke für den Link. --Liebe Grüße, Lómelinde Diskussion 10:58, 27. Mär. 2016 (CEST)

Apropos, „bietet Aufschluss“ ich bewundere es immer wieder wie man solche Seiten auch „verstehen“ kann.

Schreib es mir mal irgendwo auf wo ich in aller Ruhe damit herumexperimentieren kann.

Beispiele  

python, py, sage >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero	python3, py3 >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero
pytb und py3tb >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero
pycon >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero	cython, pyx, pyrex >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero
numpy >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero	dg (dogelang) >>> a = 'foo' >>> print a foo >>> 1 / 0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero

Interessant sie funktionieren scheinbar sogar alle. --Liebe Grüße, Lómelinde Diskussion 12:01, 27. Mär. 2016 (CEST)

Das „Con“ steht für „Konsole“, hier bestmöglich als Kommandozeile erklärt; hat nichts mit Conference zu tun.

An den >>> tippen Benutzer Python-Code ein.

• Deshalb ist pycon das einzige Format, das diesen prompter hervorhebt.
• Danach kommt in der Zeile reguläre Programmiersprache.
• Für alle anderen Formate sind die >>> Schrott.

Alles andere ist die Antwort des Systems darauf.

• Dabei werden in der Konsolen-Antwort des Systems Schlüsselwörter wie ZeroDivisionError: erkannt.
• Auch Traceback ist ein Schlüsselwort.
  • pytb und py3tb handhaben solche Rückverfolgungen (du hast sie mir schon öfters in JavaScript-Fehlerprotokollen übermittelt). Das „tb“ verweist darauf. Deshalb ist diesen das Schlüsselwort Traceback ebenfalls bekannt und blau. In pycon wird vor der roten Fehlermeldung ein Traceback (Stacktrace) eingeblendet, um den Fehler lokalisieren zu können.

Die Wörter in und or sind Schlüsselwörter in der Programmiersprache, tauchen hier aber in menschlichem englischen Text auf. Deshalb werden sie fälschlich hervorgehoben, wo Nachrichtentext als Programmiersprache formatiert wird, und werden ignoriert, wo die Systemantworten erwartet und angezeigt werden. Der Grund, warum ZeroDivisionError: erkannt und rot dargestellt wird, dürfte in Programmiersprache und Traceback fundamental unterschiedlich sein; es ist auch ein anderes Rot.

LG --PerfektesChaos 13:42, 27. Mär. 2016 (CEST)

Oh, ach so für mich standen da nur Hieroglyphen, die unterschiedlich farbig angezeigt werden, je nachdem, welche Sprache ich vorgebe. Danke für die Erklärungen.   Ich glaube ein ganz klein wenig verstehe ich es jetzt wo der Unterschied liegt. Ich tue mich unheimlich schwer mit technischen Englisch. Immerhin was ein „ZeroDivisionError“ ist, weiß ich, das hat beim Atari ST eine gewisse Anzahl an Bomben hervorgerufen. --Liebe Grüße, Lómelinde Diskussion 14:05, 27. Mär. 2016 (CEST)

Update auf 2.7.2

@Lómelinde: Da du mich angepingt hast: Es gab im November 2020 noch Gerrit:643097 mit einem Update auf Version 2.7.2. Hinzugekommen sind "arrow, bare, devicetree, dmesg, dts, execline, fstar, gd, gdscript, ipython, ipython2, ipython3, ipythonconsole, kmsg, llvm-mir, llvm-mir-body, miniscript, mosel, ms, peg, pointless, promql, psysh, raku, reason, reasonml, ride, sieve, singularity, tid, tnt, usd, usda, webidl, yang". Das habe ich im November selber übersehen und gerade nur auf die Schnelle nachgeschaut. — Raymond ^Disk. 09:54, 16. Mär. 2021 (CET)

Oh dann sind da wohl noch ein paar nachzutragen, Dankeschön. --Liebe Grüße, Lómelinde Diskussion 09:56, 16. Mär. 2021 (CET)

So alle geprüft und die gestrichen, die nicht funktionieren. Teilweise übernommen aber nicht alle. --Liebe Grüße, Lómelinde Diskussion 11:30, 16. Mär. 2021 (CET)

Benutzer:Blart/Vorlage:Erde

Enthält folgende Anweisung

Text <syntaxhighlight>{{Babel|:Blart/Vorlage:Erde}}</syntaxhighlight> Text

Das machte mich nun stutzig, weil die Seite nicht in der Fehlerkategorie erfasst wird und das, obwohl eindeutig das Attribut lang= fehlt (Hilfe:Syntaxhighlight#Parameter = Pflichtangabe). Kann es irgendwie sein, dass der BNR von dieser Analyse ausgeschlossen ist? CC: Sebastian Wallroth als Auslöser →Spezial:Diff/208481203. Siehe auch Kategorie:Wikipedia:Seite mit Syntaxhervorhebungsfehlern da müsste das eigentlich gelistet werden, damit defekte Syntax repariert werden kann. @Sebastian, bitte statt des Syntaxhighlight_Tags in einem solchen Fall besser pre-Tags verwenden. --Liebe Grüße, Lómelinde Diskussion 13:33, 24. Mai 2022 (CEST)

Die Parameter im Abschnitt "Parameter" sollten "richtige" Abschnitts-Überschriften haben

(etwa) so, wie ich es in https://de.wikipedia.org/w/index.php?title=Hilfe%3ASyntaxhighlight&type=revision&diff=227144841&oldid=221616073 gemacht hatte.

Ich hoffe, einige von Euch (Lómelinde, Wipa0404 , Y2kbug, Raymond, Xqt, Dirk123456, Speravir, Anton Sevarius, Entlinkt, Crazor, Ajv39) unterstützen meine Argumente und meinen Vorschlag.

Vorteile:

• 1. Die Überschriften tauchen im InhaltsVerzeichnis auf.
• 2. Es ist leichter zu erkennen, wo ein Abschnitt beginnt und endet.
• 3. Jeder Abschnitt kann *einzeln* bearbeitet (editiert) werden.

@PerfektesChaos:

Zu deinem Argument

"solche Darstellungen für untergeordnete Komponenten tauchen in den Inhaltsverzeichnissen nie auf"

Dein Argument mit meinen Worten: "Wir sollten es so lassen, weil es eben so ist."

Wenn man diesem Argument folgen würde, dann dürfte man in der WP ja GAR nichts und NIE irgend etwas ändern.

DAS Argument ist ja nun wirklich ein sehr schlechtes Argument.

Die WP lebt doch von Verbesserungen!

Zu

"diese Seite wird regelmäßig in Gesamtheit bearbeitet"

Diese Seite hat im Inhalts-Verzeichnis z.Z. 16 Abschnitte, die einzeln bearbeitet werden können.

Wer diese Seite "in Gesamtheit" bearbeiten möchte, kann das ja tun, indem er/sie das [ Bearbeiten ] in der zweiten Zeile dieser Seite verwendet.

Aber warum sollte man für alle anderen das Bearbeiten un-nötig schwer lassen?
Das -- musst du mir 'mal erklären.

Zu

"per Anker konnten bisher alle Spezifikationen individuell angesprungen werden, und jetzt sind die Anker sogar in den falschen Abschnitten gelandet"

Das war Absicht.
Die Anker hätten ja immer noch zu dem betreffenden Abschnitt geführt.
Meine Absicht war, dass die neue Überschrift in Gänze zu sehen ist.
Aber ich hätte auch nichts dagegen (gehabt), die Anker da/so:

=== {{Anker|Soundso}}Überschrift ===

zu platzieren.

Ping willkommen, Steue (Diskussion) 18:13, 18. Okt. 2022 (CEST)

Ich bin für solche Überschriften

Steue (ohne (gültigen) Zeitstempel signierter Beitrag von Steue (Diskussion | Beiträge) 18:15, 18. Okt. 2022 (CEST))

Ich bin gegen solche Überschriften

• Dagegen, weil ich so etwas Spezial:Diff/221616073/227144841#=== inline === für wirklich schlecht halte, das sieht sowohl im Inhaltsverzeichnis als auch in der Abschnittsüberschrift selbst === inline === unschön aus, bläht das Inhaltsverzeichnis auf und ist zudem unnötig, niemand muss auf dieser Seite ständig einzelne Abschnitte bearbeiten, da wird nur sehr selten etwas verändert. Und diejenigen, die dort etwas ändern und sich um die Pflege dieser Seite kümmern, kommen damit klar. Dein Vorschlag verschandelt die Seite unnötig. Es gibt nur ganz wenige Benutzer hier, die sich aktiv um die Pflege der Hilfeseiten kümmern ich benötige diese Überschriften nicht. --Liebe Grüße, Lómelinde Diskussion 18:50, 18. Okt. 2022 (CEST)
• Völlig unübersichtlich. --Magnus (Diskussion) 18:51, 18. Okt. 2022 (CEST)
• --PerfektesChaos 20:21, 18. Okt. 2022 (CEST)
  • Der Abschnitt H:SYH #Parameter hat ein eigenes kleines erläutertes Inhaltsverzeichnis. Sowas fehlt natürlich im automatischen Inhaltsverzeichnis.
  • 35 % der Zahl der Bearbeitungen ist von mir, weitere 21 % kommen von Lómelinde, und alle sonstigen, die hinreichend sachkundig für Veränderungen an dieser Doku sind, wissen wie notfalls der Abschnitt H:SYH #Parameter zu bearbeiten wäre (ausweislich VG wird jedoch regelmäßig die komplette Seite en bloc bearbeitet). Und alle, die sich mit Syntax auskennen und an dieser Hilfeseite was verloren haben, schaffen das auch.
  • „Pflichtparameter“ ist ein in allen Vorlagen- und MediaWiki-Dokus einheitlich verwendetes Schlüsselwort. Das hast du nunmehr unabgesprochen durch deine private Schöpfung „notwendiger Parameter“ ersetzt (11 Vorkommen in allen Namensräumen; „Pflichtparameter“ hat hingegen 3.265).
  • Es bedarf auch keinerlei Begründungen, „warum“ irgendwas Pflichtparameter ist – der Grund ist immer und überall, dass die Funktion sonst nicht sinnvoll ausführbar ist. Ich werde auch dies in Kürze revertieren, weil es nur ohne Erkenntniswert aufbläht. lang ist Pflichtparameter, das ist in dieser Software nunmal so, Basta.

Danke für den Hinweis. Dass das eine Art (auch nicht gerade standard-mäßiges) Inhalts-Verzeichnis ist, war (für mich) nicht offensichtlich. Ich wage 'mal zu vermuten: vielen anderen Lesern ist/wäre es genauso ergangen. Jetzt, nachdem du es mir geschrieben hast, finde ich das ja ganz nützlich. Aber das widerlegt Lomélindes Argument, dass diese Parameter überhaupt nicht in dem/einem InhaltsVerzeichnis zu sein bräuchten.

Und weil diese StichWörter dadurch im Haupt-IV fehlen, ist das nicht die besste Lösung.

Im Grunde gestehst du damit ja auch ein, dass diese ParameterNamen in einem IV vorkommen sollten.

---

Für wen sind die/alle Hilfen hier in der WP gedacht und gemacht -- für Leute, die sich ohnehin auskennen, oder für jene, die das Ganze erst lernen wollen?

Für Letztere waren meine Überschriften gedacht.

Dass diejenigen, die diese Seite bei Bedarf pflegen, diese Überschriften nicht brauchen, war mir schon klar. Aber ich bin sicher, mein Hinweis auf die unwissenden, aber wissen-wollenden Leser wird auch nichts ändern.

Aber wegen solcher Ansichten sind die Hilfe-Seiten so schwer zu lesen, wie sie sind.

Steue (Diskussion) 01:16, 19. Okt. 2022 (CEST

@ PerfektesChaos

Zu

"Es bedarf auch keinerlei Begründungen"

Zitat:

Communicate: ... make the extra effort so that other people understand you. ... It is always a good idea to explain your views; it is less helpful for you to voice an opinion on something but not explain why you hold it. Explaining why you have a certain opinion helps to demonstrate its validity to others and reach consensus.

Quelle:

Wikipedia:Talk page guidelines #How to use article talk pages / * Communicate

Steue (Diskussion) 01:37, 19. Okt. 2022 (CEST)

11 Vorkommen von „notwendiger Parameter“ in allen Namensräumen belegt doch zweierlei:

• 1) dieser Ausdruck ist nicht (nur) meine Schöpfung, und
• 2) einige andere (Verständige) halten diesen Begriff „notwendiger“ auch für besser, weil er die Sache (überhaupt erst ein mal) begründet.

"Pflicht" begründet nicht.

Steue (Diskussion) 01:53, 19. Okt. 2022 (CEST)

@ Lomélinde,

Ich gebe ja zu, dass es nicht schön aussieht, aber

was ist in einer Wikipedia wichtiger:

Schönheit des äußeren ErscheinungsBildes (Layout) oder praktischer Nutzen für die Leser?

Wenn du es nicht schön findest, dann steht es dir doch frei, es schöner zu machen -- aber bitte schön ohne den praktischen Nutzen zu schmälern.

Steue (Diskussion) 02:00, 19. Okt. 2022 (CEST)

Es geht nicht um schön oder nicht schön, diese Unterteilung ist schlicht unnötig, weil diese Seite, wie schon geschrieben, nur von sehr wenigen Benutzern aktiv gepflegt wird. Diese wissen, was sie tun und kennen das Konzept der Hilfeseiten. Ich sehe keinerlei Mehrwert darin, das oben ins Inhaltsverzeichnis zu setzen. Du wolltest wissen „wer das möchte“, ich sage „ich möchte das nicht“. Da gibt es auch keinen Diskussionsbedarf von meiner Seite. Wichtig ist es eine Struktur einzuhalten und das tut auch diese Hilfeseite. Sie hat nach meiner Meinung eine verständliche Strukturierung, einer Aufblähung des Inhaltsverzeichnisses bedarf es nicht, insbesondere nicht mit fetten Gleichheitszeichen === … ===, das ist absolut unüblich. --Liebe Grüße, Lómelinde Diskussion 07:15, 19. Okt. 2022 (CEST)

1.41.0-wmf.5

Mit phab:T29828 Gerrit:906127 neu zum umseitigen Einpflegen:

• art, arturo, be, berry, carbon, comal, comal80, cplint, css+ul4, dax, fc, fif, fift, func, gap-console, gap-repl, hcl, html+ul4, jmespath, jp, js+ul4, jsonnet, k, linuxconfig, lobas, macaulay2, mcf, mcfunction, mcschema, mips, oobas, phix, portugol, postgres-explain, py+ul4, q, qlik, qlikscript, qliksense, qlikview, snbt, sobas, sql+jinja, tal, tlb, ul4, unixconfig, uxntal, wsgl, wowtoc, wren, x++, xml+ul4, xpp
• mediawiki alias von wikitext?

VG --PerfektesChaos 14:49, 20. Apr. 2023 (CEST)

lang="mediawiki" und lang="wikitext" lösen derzeit definitiv die Fehlerkategorie aus siehe Spezial:Diff/232973465 und die Vorherversion lang="mediawiki", die anderen muss ich alle mal prüfen. testweise art und be N auch die lösen die Fehlerkat aus.

hello

irgendwie nicht wirklich --Liebe Grüße, Lómelinde Diskussion 18:53, 20. Apr. 2023 (CEST)

art, arturo, be, berry, carbon, comal, comal80, cplint, css+ul4, dax, fc, fif, fift, func, gap-console, gap-repl, hcl, html+ul4, jmespath, jp, js+ul4, jsonnet, k, linuxconfig, lobas, macaulay2, mcf, mcfunction, mcschema, mips, phix, portugol, postgres-explain, py+ul4, q, qlik, qlikscript, qliksense, qlikview, snbt, sobas, sql+jinja, tal, tlb, ul4, unixconfig, uxntal, wsgl, wowtoc, wren, x++, xml+ul4

Ergebnis des Tests keine der angegebenen Sprachen funktioniert außer oobas und xpp und die standen auch schon vorher in der Tabelle Hilfe:Syntaxhighlight#Unterstützte Sprachen

CC: @ Benutzer:Raymond hast du da irgendeine Info warum das bei uns nicht läuft?

zufällig gefunden hatte ich aber noch html+handlebars

if hello then "ok" else end
{{#invoke:TemplatePar|match
|template=[[Vorlage:EU-Richtlinie]]

Das fehlt noch in der Tabelle. --Liebe Grüße, Lómelinde Diskussion 07:41, 21. Apr. 2023 (CEST)

@Lómelinde Wundert mich, aber leider keine Idee, was da faul ist. Der Patch wurde auch nicht revertiert. --Raymond ^Disk. 07:57, 21. Apr. 2023 (CEST)

Na dann warten wir mal bis zum nächsten Update. --Liebe Grüße, Lómelinde Diskussion 08:00, 21. Apr. 2023 (CEST)

Bis jetzt scheint da nichts zu funktionieren, vielleicht mag da mal jemand nachfragen woran das liegen könnte? --Liebe Grüße, Lómelinde Diskussion 13:46, 1. Mai 2023 (CEST)

@Lómelinde Es wurde heute Nacht eine Konfigurationsänderung vorgenommen. Klappt es jetzt? --Raymond ^Disk. 09:12, 2. Mai 2023 (CEST)

Ja jetzt scheint es zu klappen. Danke für die Info. --Liebe Grüße, Lómelinde Diskussion 09:15, 2. Mai 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 10:15, 1. Jun. 2023 (CEST)

lang="vba", lang="visual basic for applications" (Excel-Makro)

Visual Basic for Applications (VBA), Excel-Makro - Gibt es das schon als SyntaxHighlight? oder was wäre ein passender Workaround? Gruss, --Markus (Diskussion) 00:39, 1. Mär. 2024 (CET)

@Markus Bärlocher Die vollständige Liste der unterstützten Programmiersprachen findest du unter https://pygments.org/languages/ . VBA finde ich darin nicht. Workarounds funktionieren nicht; sie führen zu einer Fehlermeldung in Form der Einordnung der Seite in eine Wartungskategorie. Da die vorgenannte Liste nicht von der Wikimedia Foundation gepflegt wird, kann sie auch nicht selbststänig erweitert werden. --Raymond ^Disk. 08:03, 1. Mär. 2024 (CET)

Ok, danke. Habe den Wunsch mal per Mail an Georg weitergeleitet (selber kann ich nicht helfen ;-) ). Gruss, --Markus (Diskussion) 20:52, 2. Mär. 2024 (CET)

Interessant, erst neulich habe ich lang="vb" ersetzt, weil das plötzlich nicht mehr funktionierte →Spezial:Diff/223308163/234780591 und heute, wo ich es ausprobiert habe, geht es wieder, also du kannst lang="vb" = Visaual Basic oder alternativ lang="vbscript" verwenden. lang="vba" funktioniert jedenfalls nicht und würde Fehler auslösen.

lang="vb" Visual Basic Classic

Public Class Program
   Public Shared Sub Main()
     Console.WriteLine("Hallo Welt!")
   End Sub
End Class

lang="vbscript" Visual Basic Script

Public Class Program
   Public Shared Sub Main()
     Console.WriteLine("Hallo Welt!")
   End Sub
End Class

Es gäbe auch noch lang="vbnet" Visual Basic .NET

Public Class Program
   Public Shared Sub Main()
     Console.WriteLine("Hallo Welt!")
   End Sub
End Class

Siehe auch Available lexers bei pygments.org (kein excel makro) und mw:Extension:SyntaxHighlight#Supported languages Mediawiki. --Liebe Grüße, Lómelinde Diskussion 08:06, 1. Mär. 2024 (CET)

Danke für die - wie immer - beispielhafte Antwort. Weder vb noch vbscript hat bei mir funktioniert. Workaround: <pre>...</pre> - aber halt ohne Syntaxhighlight. Gruss, --Markus (Diskussion) 21:01, 2. Mär. 2024 (CET)

Verstehe ich nicht, hier funktioniert es doch einwandfrei. Wo hast du das denn versucht? --Liebe Grüße, Lómelinde Diskussion 08:51, 3. Mär. 2024 (CET)

@ Markus ist deine Anfrage hier dann erledigt? Dann setze bitte einen Erledigtbaustein. --Liebe Grüße, Lómelinde Diskussion 17:39, 1. Mär. 2024 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Markus (Diskussion) 21:09, 2. Mär. 2024 (CET)

#Parameter / inline

Ich habe eine (wie ich finde) besser/schneller/leichter verständliche und vor allem dann auch leichter nachmachbare Version entwickelt, in: Benutzer:Steue/Syntaxhighlight #Könnte/Sollte.

Urteilt selbst.

Wem sie gefällt, der kann sie ja gerne kopieren.

Aber rechnen tue ich nicht damit.

Ich -- habe jedenfalls keine Lust, mir meine aufwendige Arbeit von ... zurücksetzen zu lassen.

Ping willkommen, Steue (Diskussion) 00:41, 19. Okt. 2022 (CEST)

Pygments-Update-Rhythmus

Hallo,

ich habe mich heute mal gefragt, ob Pygments inzwischens auch Lean4 unterstützt, und nicht nur Lean3 (die sind stellenweise syntaktisch doch recht verschieden). Und siehe da: Ja, als Sprachcodes gibt es inzwischen lean, lean3 und lean4, statt nur lean. Zunächst wollte ich es einfach umseitig hinzufügen, habe mich aber entschieden, langsam zu machen. Dann habe ich erstmal ausprobiert, ob lean4 überhaupt geht und festgestellt: geht hier noch nicht. Ins Pygments-Change-Log geschaut und gesehen: ok, lean4 gibt's erst seit heute -- also eigentlich kein großes Wunder, dass es hier noch nicht geht. Aber: Weiß man, wann damit zu rechnen ist, dass die Unterstützung auch hier ankommt? Sind es eher Tage oder eher Monate? --Daniel5Ko (Diskussion) 21:36, 4. Mai 2024 (CEST)

@Daniel5Ko Heute wurde Task364249 erstellt und Patch 1027245 geschrieben. Die Chancen stehen nicht schlecht, dass die Aktualisierung in 1-3 Wochen live geht. --Raymond ^Disk. 21:47, 4. Mai 2024 (CEST)

Danke für die Info. :) --Daniel5Ko (Diskussion) 22:00, 4. Mai 2024 (CEST)

Wird wohl noch 'ne Weile dauern, angesichts der Änderungen in Task364249 von vorgestern. --Daniel5Ko (Diskussion) 23:38, 18. Mai 2024 (CEST)

Ja, da hatte ich leider nicht mit gerechnet :-( --Raymond ^Disk. 08:25, 19. Mai 2024 (CEST)