aboutsummaryrefslogtreecommitdiff
path: root/node_modules/highlight.js/docs/line-numbers.rst
diff options
context:
space:
mode:
authorFlorian Dold <florian.dold@gmail.com>2019-03-27 21:01:33 +0100
committerFlorian Dold <florian.dold@gmail.com>2019-03-27 21:01:33 +0100
commitcc97a4dd2a967e1c2273bd5f4c5f49a5bf2e2585 (patch)
tree92c5d88706a6ffc654d1b133618d357890e7096b /node_modules/highlight.js/docs/line-numbers.rst
parent3771b4d6b67b34c130f3a9a1a15f42deefdb2eda (diff)
remove node_modules
Diffstat (limited to 'node_modules/highlight.js/docs/line-numbers.rst')
-rw-r--r--node_modules/highlight.js/docs/line-numbers.rst39
1 files changed, 0 insertions, 39 deletions
diff --git a/node_modules/highlight.js/docs/line-numbers.rst b/node_modules/highlight.js/docs/line-numbers.rst
deleted file mode 100644
index 674542d4e..000000000
--- a/node_modules/highlight.js/docs/line-numbers.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-Line numbers
-============
-
-Highlight.js' notable lack of line numbers support is not an oversight but a
-feature. Following is the explanation of this policy from the current project
-maintainer (hey guys!):
-
- One of the defining design principles for highlight.js from the start was
- simplicity. Not the simplicity of code (in fact, it's quite complex) but
- the simplicity of usage and of the actual look of highlighted snippets on
- HTML pages. Many highlighters, in my opinion, are overdoing it with such
- things as separate colors for every single type of lexemes, striped
- backgrounds, fancy buttons around code blocks and — yes — line numbers.
- The more fancy stuff resides around the code the more it distracts a
- reader from understanding it.
-
- This is why it's not a straightforward decision: this new feature will not
- just make highlight.js better, it might actually make it worse simply by
- making it look more bloated in blog posts around the Internet. This is why
- I'm asking people to show that it's worth it.
-
- The only real use-case that ever was brought up in support of line numbers
- is referencing code from the descriptive text around it. On my own blog I
- was always solving this either with comments within the code itself or by
- breaking the larger snippets into smaller ones and describing each small
- part separately. I'm not saying that my solution is better. But I don't
- see how line numbers are better either. And the only way to show that they
- are better is to set up some usability research on the subject. I doubt
- anyone would bother to do it.
-
- Then there's maintenance. So far the core code of highlight.js is
- maintained by only one person — yours truly. Inclusion of any new code in
- highlight.js means that from that moment I will have to fix bugs in it,
- improve it further, make it work together with the rest of the code,
- defend its design. And I don't want to do all this for the feature that I
- consider "evil" and probably will never use myself.
-
-This position is `subject to discuss <http://groups.google.com/group/highlightjs>`_.
-Also it doesn't stop anyone from forking the code and maintaining line-numbers implementation separately.