feat: add code view-specific tokenization settings #401
Conversation
|
@tjkandala Will you have a follow-up PR for this one? I mean add |
| @@ -549,14 +558,18 @@ export function createHoverifier<C extends object, D, A>({ | |||
| // It's important to do this before filtering otherwise navigating from | |||
| // a position, to a line-only position, back to the first position would get ignored | |||
| distinctUntilChanged((a, b) => isEqual(a, b)), | |||
| map(({ position, codeView, dom, ...rest }) => { | |||
| map(({ position, codeView, dom, overrideTokenize, ...rest }) => { | |||
There was a problem hiding this comment.
Do you think, can we use a parameter default value assignment, like overrideTokenize = tokenize, ...rest}) instead of shouldTokenize function?
There was a problem hiding this comment.
That's a great idea, but will we always use destructuring assignment? I think keeping it explicit will prevent regressions
|
@vovakulikov We'll use this in sourcegraph/sourcegraph#25020! |
tjkandala
force-pushed
the
tjk/override-tokenize
branch
from
896ee30 to
71d58d1
Compare
Codecov Report
@@ Coverage Diff @@
## master #401 +/- ##
==========================================
+ Coverage 85.86% 85.91% +0.04%
==========================================
Files 14 14
Lines 651 653 +2
Branches 174 175 +1
==========================================
+ Hits 559 561 +2
Misses 92 92
Continue to review full report at Codecov.
|
Some code hosts use many types of code views, some of which are tokenized and some of which are not. This PR introduces a way for consumers to override the
Hoverifierinstancetokenizeflag through event options inHoverifer#hoverify.