FIameCaster / prism-code-editor

Lightweight, extensible code editor component for the web using Prism
https://prism-code-editor.netlify.app
MIT License
43 stars 6 forks source link

configurable line number start #8

Closed Mike-Bell closed 5 months ago

Mike-Bell commented 5 months ago

First off, great lib, I was looking for a while for something like this that "just works" for me. Has to do a couple small css hacks, but for the most part it "just works".

Small feature request: configurable line number start, like the Prism line-numbers plugin supports.

I can do this manually, but it's ugly and probably bad for perf:

onUpdate: function(code: string) {
   onCodeChange(code);
   const lines = this.wrapper.children;
   for (let i = 0; i < lines.length; i++) {
      lines[i].setAttribute('data-line', i + startingLineNumber);
   }
},
FIameCaster commented 5 months ago

Setting attributes is pretty fast, so your solution has a negligible impact on performance. I wouldn't say it's that ugly. You can also start your for loop at i = 1 since the overlays are at index 0.

If I used CSS counters for line numbers, changing the line number start would be easy by overriding the counter-reset CSS property. Unfortunately, Safari doesn't update counters when adding or removing children, which is why I didn't use them. This seems to have been fixed very recently, probably in Safari 17.0 or 17.2, so I might switch to using CSS counters, but not in the near future.

Adding a configurable line number start would require a significant addition to the core (like a ~2% increase) for a fairly niche feature. This is because PrismEditor.setOptions would have to update the line number of every line whenever the line number start option is changed. I'm therefore a bit hesitant to add this feature unless it's heavily requested.

Mike-Bell commented 5 months ago

Cool, that's fine. I support not bogging down main use cases for less common ones. I have it in my mind that doing N dom manipulations on every code change is "expensive", but you're probably right that it's not a big deal.

FIameCaster commented 5 months ago

N dom manupulations every code change might sound like a lot, but compared to the syntax highlighting, it's neglibible. You can expect a less than 5% performance hit.