Option to default to line-number for all code blocks

[lukasoppermann]

Hey @LeaVerou,

so I am using your awesome prism syntax highlighter for my blog. I would like all code blocks to have line numbers (with maybe the occasional one without line numbers).

I think it would be pretty awesome to add some kind of config to set the line-number plugin into a default-on state. In this state, the plugin would always add line-numbers, apart from the code blocks where the class .no-line-numbers is added.

Adding the .line-numbers class for every code-block has the following disadvantages in some cases:

• if done automatically, you can not unset it
• I am using markdown files, which are parsed by the php commonmark and it is not so easy to automatically change the behavior to always add line-numbers. As they are sticking to the commonmark specs, I don't think they should change their behaviour, so it would be much simpler to add it to prism.

[LeaVerou]

It’s super easy to do so yourself, as a pre-processing step before Prism runs. Assuming you're using a no-line-numbers class to opt out, you'd run something like (using Bliss in the example below, tweak accordingly if using another DOM helper library):

$$("pre:not(.no-line-numbers) > code").forEach(code => code.parentNode.classList.add("line-numbers"));

If you’re not using <pre> for anything other than code, it can be simplified even further:

$$("pre:not(.no-line-numbers)").forEach(pre => pre.classList.add("line-numbers"));

[lukasoppermann]

This is exactly what I am doing at the moment. I just feel it would be nicer to actually have that within the plugin. But I guess you do not like it because it needs config?

[LeaVerou]

I was just suggesting a temporary workaround that will work now, independently of what decision we make here.
FWIW, I think it makes sense to make it opt-out. If someone is adding this to their Prism download, they are clearly interested in having line numbers, so it doesn't make sense to force them to opt in further, on every single code example. So I would be in favor of this change. My main concern though would be: What about backwards compat?

[LeaVerou]

Another way to go would be to make it an inherited option, just like language. i.e. you can put the line-numbers class on a shared ancestor instead of having to repeat it on every element. Of course then we still need a no-line-numbers class to opt-out.

[lukasoppermann]

Hmm, I definitely agree with the reasoning for opt-out. 👍 Of course, BC breaks are a concern. A possibility would be a version bump. Also of course, it is not going to really break anything, as it is just adding line numbers, but I see your problem. We could make it opt-out, but have the possibility of a no-line-numbers class on a shared ancestor, which would make it easy to fix any breakage. But this would mean we would than have to check for the individual line-numbers again, to add it there.

I think the beast would be to think in the direction of opt-out and how this can be done with none to minimum BC problems.

[lukasoppermann]

Hey @LeaVerou I have been thinking about this a bit:

• maybe it would actually be a good idea to extract plugins to their own git repos, this way they could be individually sem-versioned (one could easily communicate BC breakage by sem-version)
  • you website could still build a download with everything included
  • it would make working with prism via bower a little easier
  • a changelog much like here http://keepachangelog.com/ can communicate any changes and like to an upgrade FAQ to help people fix BC breakage. (I no there already is a changelog which is fine, but maybe a little more details could be added to the realses :-D )
• somehow adding a class to an ancestor e.g. the <article> feels like configuration to me
  • if there is configuration, wouldn't it be better to make it real and add it in js?

The Prism object could have a small config method, which only has a getter and setter (no other logic). This way any plugin (also thrid-party plugins) could have the user add configs and retrieve it in the plugin to deal with it. Of course, there should be sensible defaults, so that the "load a go" way of using Prism, that you have going now, still works.

Prism.config({
  'auto-line-numbers': true 
});

I really like the idea of just adding a js and css file and everything starts automatically, thus I would say it should still work. But if feel Prism is at a point, where this approach needs to be extended because whenever you actually want to do some more "advanced" stuff, its getting a little hard.

[LeaVerou]

I like the idea of having plugins in separate repos!
Though somebody would need to do the work of modifying the download page to build from repos instead of folders. Also, how would somebody send a PR to add a new repo?

if there is configuration, wouldn't it be better to make it real and add it in js?

Not everybody using Prism can code JS, but all our users can work with HTML. Note that around 50% or more of HTML authors are not super comfortable with JS. Ideally there should be a way to provide both and it should be in the core or some base plugin that gets included if at least one plugin is included. @zeitgeist87 did some work on writing such a plugin a while ago, but it was way too large for this purpose IIRC. We need something small and compact, even if it doesn't cover all possible use cases ever, so that it doesn't add any significant weight to the plugins.

[lukasoppermann]

Hey @LeaVerou, sadly I have no idea how you build the editor and also not how one would change it to use repos, but it could possibly be done with something like gulp on the server.

The plugins should be underneath https://github.com/PrismJS and somewhere there would be a repo where you send an issue to add a new plugin. If it is agreed the plugin should be added, you (or somebody) could create a new repo there.

Themes could potentially also get their own repos, but maybe that is overkill.

Maybe it would make sense to add a "Prism-project" repo, which is the code for the website. There users could add an issue for a new plugin.

Not everybody using Prism can code JS, but all our users can work with HTML. Note that around 50% or more of HTML authors are not super comfortable with JS.

I totally agree with this and I think this is one of the advantages of Prism. But this could be easily solved by adding (and requiring every plugin to have) sensible defaults. This should make it possible to use prism just like now without any config, put still allow for configuration.

I think my suggestions would be very small as it is just a getter / setter idea and could be easily get to the core (and also used in the core but of course with sensible defaults.)

[LeaVerou]

Actually, it doesn't need to be repos under PrismJS, it could be any repo, as long as we store its info in components.js. That way people can push fixes to their plugins without requiring our approval, and we can still offer a nice build with everything from the Prism page.
Unfortunately, I don't have the time to work on this, but perhaps @Golmote or @zeitgeist87 do?

[bricebou]

Hi, any news about this ? It would be really nice to simply have to download this plugin and let it numbering line by default :-)
Thanks !

[rmawatson]

Hi, any news about this ? It would be really nice to simply have to download this plugin and let it numbering line by default :-)
Thanks !

+1

[lieszkol]

+1

[tsubasacode]

nice tool. Can I ask how can I fix one line result . Something shows my code as only one line stripping all new lines.

[RunDevelopment]

@tsubasacode Please open a new issue and describe the problem in more detail. Maybe even add an example project or JSFiddle, so I can reproduce your problem.

[tsubasacode]

Thank you very much. I found a online and realized that it was because of I was getting the code from editable div instead of textarea. When I switched to textarea it worked as perfectly.
Thanks a lot.
solved issue #1764