no-descending-specificity:
Expected selector ".mw-highlight.mw-content-ltr .linenos" to come before
selector ".mw-highlight a:hover .linenos"
Change-Id: Ib8bd3dcc83058c6935b6b6c472554e3c1fa01eda
* Render a solid gutter that can take 3-4 digit line numbers
* Position line numbers absolutely in the gutter
* Add padding to code so that it doesn't wrap into the gutter
Change-Id: I7abb87452ad61808dad32b41c1d2d86b8ababb28
This makes them unselectable in more browsers as the
user-select fix isn't supported everywhere (e.g. Safari).
Bug: T32773
Change-Id: I274632a1055e1f85679fbb29c81629104cc8b222
Changes:
<https://github.com/pygments/pygments/blob/2.7.2/CHANGES#L15-L158>
The 2.7.2 release contains fixes to existing lexers, as well as the
following new lexers:
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, and yang
To verify the integrity of the pygmentize binary, you can run
'create_pygmentize_bundle' and verify that the same pygmentize file is
created.
Change-Id: I0be3c1c204237b4a8873063e282be7ab8655be9d
Require that the node is modified and the language input is
valid before enabling the "done" action. Otherwise disable it.
Bug: T206481
Change-Id: Ie9d2907358ea585ba72628887c46af69f942772f
The CSS already has this modifier prefixed with -webkit-, -ms- and
-moz-, some browsers now support this without any prefix (according to
caniuse.com: Chrome 54+, Opera 41+).
Change-Id: Icd67250c26bec61be0fb101f1db077ee13ccf6b7
Don't bother checking supported languages before generating the node contents.
We always want the preview, as that's what will display on the rendered page
even if the language is invalid.
Bug: T164120
Change-Id: I8344449bbf9c9cce131d745ea5f4e54b96fe57b1
* Allows the dropdown menu to extend outside of the dialog.
* Avoid z-index conflicts with Ace scrollbars (T170027).
Bug: T170027
Change-Id: I52d2d06b56391f30be07c71a86d71d9ab50f0a8c
Ensures the rendering is cached with the correct hash.
Bug: T151130
Depends-On: I80e2f2587cff8e9d9fe6ded5d8581263268deaa8
Change-Id: I64466cc342f7ab7f9d4539f935688d167853a662
All our highlight content is inside a <pre> block. When this block is
more narrow that the page (due to being pushed aside by floating
context for instance), then the background of this parent element will
extend beyond the contents.
An alternative could be setting overflow:hidden; and then setting
margin:0 on the included <pre> element (which has UA default margins)
Bug: T126010
Change-Id: Id3c9544ea8fa379c7c640afa692d6184ad9c550f
Notable changes:
* Added new token types and lexing for magic methods and variables in
Python and PHP.
* Added a new token type for heredoc (and similar) string delimiters and
lexing for them in C++, Perl, PHP, Postgresql and Ruby lexers.
* Improved the CSS lexer.
* Added Varnish config lexer
Full changelog is found at:
<bc45808f83/CHANGES>
Bug: T156573
Change-Id: I4dc1782f19881ba1294308e1cdea1b2e063f438a
* Combobox is now an input widget so doesn't need .input
* Replace isValid with getValidity.
* Remove 'Show line numbers' from inline mode, as it has
no effect.
* Remove no-longer required z-index hack.
Bug: T150555
Change-Id: I3c4ac3cb6b174348cc3582469a86fb1a23ca7c51
Provide a translation from Syntaxhighlight compatible Pygments and
GeSHi language names to CodeEditor compatible Ace lexer names
Now when you select php4, the CodeEditor will use the Ace lexer php,
instead of falling back to text mode.
Bug: T148515
Change-Id: Ibc209f97318614f764457726f8d55f4e15276d79
From the description of the commit message[1] for WindowTool (which replaces
DialogTool) and FragmentWindowTool, the
ve.ui.MWSyntaxHighlightDialogTool should be a FragmentWindowTool,
and not a WindowTool/DialogTool.
In fact, the bug is caused by the missing isCompatibleWith method
in WindowTool.
[1] I3a0e761f0d6e942d503ec
Follow up: I676af9c50b09ef007926240eb2327d1a0fdd80f5
Bug: T121596
Change-Id: I0fa440d845c1dea34b623de0a36fb57cebf60f78
Maintain the inspector for inline snippets (which are editable
but still not creatable).
Bug: T112617
Bug: T57934
Change-Id: I76e36590363d36c0d3db4ec28ce81c4860d9b467
Follow-up to 043969f84e.
It is not needed for current HTML generated by the extension tag,
but is required for compatibility with cached renders generated
between 6484894497 and
043969f84e.
Bug: T105499
Change-Id: Ie15d9c7fb673528b2ab5e40e6beddc580fb6d368
* Use 'nowiki' strip marker to prevent list processing (also known as
doBlockLevels()). This resolves various issues related to using
<syntaxhighlight/> blocks in lists and lists suddenly appearing
inside <syntaxhighlight/> blocks. Fixes T17333, T25674, T104067.
* To prevent <p/>-wrapping resulting from the above, add our own
wrapper <div/> around the output.
* Since we already have our own wrapper, remove Pygments' one and
extend it with custom attributes. This resolves some regressions
from the GeSHi migration. Fixes most of T103964.
Bug: T17333
Bug: T25674
Bug: T103964
Bug: T104067
Change-Id: I3afd1224a18549c62cd4a95fd046affa6d1d3b3f
MZMcBride noticed the red border around '國' in
https://en.wikipedia.org/wiki/Swift_(programming_language)#Example_code
That particular case happens to be a Pygments bug, because multibyte characters
are valid variable names in Swift. But even in cases of legitimate syntax
errors, I don't think we want to show the red border. This behavior may be
useful in code editors, but it is not useful in a wiki environment, especially
given the longstanding habit of using an existing, mostly-compatible lexer to
highlight a language for which no specific lexer exists.
To fix this, override the style in pygments.wrapper.css, and swap the order in
which the two CSS files are concatenated, so that in general we have the
ability to override Pygments-generated CSS.
Change-Id: I304fdaf3a462445d316e0f7fecc983fa87afc629
Before we started using the 'code' tag for inline code snippets,
<code><syntaxhighlight enclose=none ...>...</syntaxhighlight></code>
was a common pattern. Continue supporting it in existing content.
Follow-up to 04293baad9. My IRC comments
about this were seemingly forgotten, and the code I added in
5b7522a5fc to handle this problem
unceremoniously removed.
Bug: T85794
Change-Id: I8e52089fed41e78fb60ddd5b7c12075056265dd9
The 'direction' rules must not be applied to regular preformatted
text in MediaWiki core, only to syntax-highlighted programming
language code.
(Not reverting the part that removes 'monospace' rule, *that* is
superfluous.)
This reverts commit f834b719b9.
Bug: T103780
Change-Id: Ie7e9123ab3456aa6fff0485431fe81cd5eb31fa2
The styles in MediaWiki core for <pre> already cover this. And
for skins that want different styles, SyntaxHighlight should not
have been overriding it.
Bug: T103780
Change-Id: Ib863288a9a4530b183cf5fdb692489363d82a50f
I'm not entirely sure that this will always behave correctly on RTL
wikis, but currently we never behave correctly on RTL wikis.
Bug: T85794
Change-Id: I8af2b18884ec619d581f9ceed737c5628b647086
It was always "none" and not "span", this must've been an accidental change.
Also add a CSS tweak to better render the common pattern of
<code><syntaxhighlight enclose="none">...</syntaxhighlight></code>.
Bug: T85794
Change-Id: I3ed1b7f3c954374b49fc9a97881ea5236415cb6f
GeSHi is unmaintained, lacks support for many popular modern languages, and
suffers from deep architectural flaws, chief among them the inconsistent
tokenization of different languages, each of which requires a custom
stylesheet.
Pygments is a well-maintained alternative. It is, by my count, the most popular
syntax highlighting library around. It is BSD-licensed, actively maintained,
and is widely used in PHP projects.
To keep this easy to review, this change does not include update for l10n
files, and it does not delete the geshi/ directory. I will do those in a
separate patch.
The chief change between this and the previous implementation is that errors
result in the code block not being highlighted, as opposed to not being printed
at all, having been replaced by an angry red error message. I think that is the
right user experience. If you go to StackOverflow or GitHub and try to mark up
your code block as being written in some language that their highlighter
doesn't know about, you don't get an error message -- the code simply doesn't
get highlighted.
Because we don't recursively load dependencies for extensions, to test this,
you will need to create a composer.local.json in $IP and add:
{
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json"
]
}
}
}
Then run `composer update`.
Bug: T85794
Change-Id: I07446ec9893fae3d1e394f435d3d95cf8be6bc33
