►
From YouTube: 2021-08-12 Frontend Performance Discussion: Source Editor (with Monaco) in Blob viewer refactor
Description
Discussed the issues that the usage of Source Editor for viewing the blobs might bring, potential solutions, and the way forward in the effort.
A
B
Yes,
so
therap,
there
will
be
two
two
points
for
me
on
the
agenda
and
the
first
one
is
pretty
fast
as
we
have.
As
we
talked
about
during
last
session.
There
was
a
spike
in
total
blocking
time
on
the
blob
view
and
the
I
didn't
have
time
to
check
it
out
to
figure
out
what
is
going
on,
but
I
had
some
time
right
after
the
previous
call
and
it
might
look
like
my
seemingly
innocent
css
change
was
the
cause,
but
I
didn't
have
proper
time
to
to
confirm
this.
B
A
B
B
So
I
don't
think
that
this
tbt
spike
overweights
the
benefit
we
get
with
the
user
experience
there.
So
I
would,
I
would
prefer
to
live
it
as
is,
and
just
figure
out
why
that
that
css
change
causes
this,
because
there
might
be
a
lesson
for
us
to
learn
there
and
okay
know
how
to
to
deal
with
things
like
this.
A
B
A
A
B
So,
okay,
so
in
the
beginning,
when
we
were
about
to
to
to
use
source
editor
for
viewing
the
files
for
viewing
the
blobs
I
was.
I
was
concerned
with
like
with
the
architectural
decision
of
whether
it's
something
we
want
to
do,
but
then
I
was
convinced
that
it
it
should
be.
It
should
be
good.
It
should
be.
It
should
be
great
for
for
the
overall
code
base.
B
However,
one
a
recent
merge
request
from
another
group
that
took
exactly
the
same
approach.
They
are
using
source
editor
for
viewing
the
viewing
the
blob
viewing
the
configuration
file,
so
it
raised
a
lot
of
concerns
from
the
from
the
technical
reviewer
and
pretty
pretty
valid
ones.
It's
just
like
there
were.
There
is
a
lengthy
discussion
there
in
the
emergency
quest.
B
Then
the
discussion
has
been
moved
to
the
slack
discussion
that
that
is
linked
in
the
agenda
as
well,
but
the
the
essence
is
that
there
are
several
concerns
related
to
to
the
particular
use
of
source
editor
for
viewing
the
files
and
general
concerns
about
moving
the
functionality
from
the
backend
to
front
end.
So
the
the
the
main
points
about
the
the
main
concerns
about
particularly
source
editor
and
as
like
as
a
side
effect
of
using
monaco
right,
so
lack
of
mobile
support
for
tax
selection.
B
B
So
you
cannot
select
text
in
the
editor
on
the
mobile
devices,
neither
in
on
android
nor
on
ios
and
that's
that's
kind
of
like
you
can
still
edit
the
things
you
can
still
write
things,
so
I
have
recorded
the
video
you
will
find
in
the
beginning
of
the
slide
discussion.
So
things
do
work.
However,
the
text
selection
doesn't
work.
The
problem
is
that,
since,
like
the
text,
selection
might
not
be
a
big
bummer
when
you
edit
the
file.
B
However,
it
might
be
a
big
bummer
for
when
you
view
the
file,
because
usually
you
might
want
to
select
the
file
the
way
like
I
pushed
th
this
sort
of
discussion,
whether
it's
really
worth
mentioning
or
not.
Push
this
to
the
ueex
department
of
that
group.
That
was
suggesting,
and
jacques
was
the
maintainer,
not
that
much
request.
So
I
pushed
this
the
decision
of
like
whether
it's
worth
to
to
fix
the
mobile
support
or
the
uniques
people
get
with
use
by
using
the
source,
editor
overweights.
B
B
A
A
The
thing
about
looking
at
mobile
usage
numbers
is
that,
when
we're
talking
about
improving
the
support,
we're
always
talking
about
who
are
the
people
that
are
here
suffering
with
the
lack
of
support?
If
we
had
support
the
numbers
would
be
better.
So
it's
always
like
the
numbers
we
have
now
and
the
numbers
that
we
could
have
once
we
have
better.
B
Expand
the
damage
caused
by
this,
but
this
this
is
one
thing.
The
second
one
is
limited
support
for
the
languages
right,
and
this
is
a
very
good,
very
good
point
that
himacha
brought
up
that.
I
think
monaco
now
supports
about
75
76
languages
while,
while
rouge
that
we
are
using
on
the
back
end
he's
using
is
supporting
something
about
150
or
something
like
this.
I
checked
yesterday,
that's
pretty
dramatic
and
we
are
already.
B
We
already
have
plenty
of
requests
from
from
the
users
to
support
that
or
another
language
in
the
editor
interface,
and
once
we
move
the
editor
to
the
view,
we
will
get
enormous
amount,
enormous
number
of
those
requests,
probably
because,
as
again
himanshu
rightfully
pointed
out
that
monaco
doesn't
even
have
the
support
for
view
files
out
of
the
box.
So
we
have
to
write
that
ourselves.
A
B
Write
ourselves
can
we
add,
support?
Yes,
we
can,
we
can
add,
support
for
any
language.
Monaco
allows
to
add
support
for
any
language
you
want
in
and
himanshu
had
an
experiment
where
he,
in
the
context
context
of
the
white
theme
he
made
the
syntax
highlighting
pretty
close
to
to
what
rouge
does
what
roosh
has.
The
problem
is
that
this
is
a
very,
very
labor-intensive
task.
B
Yeah,
so
we
sort
of
we,
we
have
to
keep
this
in
mind
and
then
there's
still
potential,
so
we
have
tamed
the
lcp.
The
lcp
is
not
affected
by
monika
right
so
by
our
preload
prefetch
tactics.
We
do
not
have
any
performance
heat
on
lcp
by
using
source
editor.
However,
a
source
editor
pulls
in
monaco
and
monaco
needs
time
to
to
to
be
parsed
anyway,
and
parsing
cannot
happen
ahead
of
time.
B
The
the
thing
to
keep
in
mind
is
it's
questionable
whether
on
the
large
blobs,
what
is
what
is
the
performance
outcome?
Because
then
we
might
compare
apples
to
oranges
so
rendering
the
large
blob
on
the
backhand
might
delay.
The
lcp,
however,
round
ring
blob
in
with
the
source
editor
will
decrease
the
lcp
but
increase
the
total
blocking
time.
B
So
there
is
a
kind
of
weird
trade-off
and,
to
be
honest,
since
we
are
talking
about
viewing
the
files,
I'm
I'm
not
sure
the
increase
in
total
blocking
time
should
overweight
the
potential
loss
of
lcp,
because
when
you
view
the
file,
when
you
don't
edit,
the
file,
the
total
blocking
time
might
be,
might
be
manageable.
So
you
will
still
see
the
content
on
the
screen.
B
B
We
had
another
another
solution.
I
think
that
didn't
require
this
right.
So
at
the
end
of
the
last
session
we
talked
about.
Why
can't
we
copy
that
file
to
a
new
project
and
scope
the
future
flag
to
it
so
yeah?
What
we
were
talking
about
is
creating
two
different
two,
exactly
the
same
projects
enable
the
feature
flag
for
one
and
disable
the
feature
flag
for
another
one
and
add
those
two
things
to
to
the
monitoring
system.
Then
we
do.
A
B
A
B
Okay,
this
this.
These
points
that
I
mentioned
were
directly
related
to
using
source
header
and
monaco
as
the
underlying
mechanism,
so
the
the
two
other
are
related
to
the
general
move
from
the
back
end
to
front
end
for
entering
the
the
blobs
first,
the
the
source
graph
integration
we
will
have
to
re-implement
it
and
the
the
things
like
those
neat
user
experience
helpers
like
generating
links.
B
For
example,
when
you
look
at
the
package.json
file,
all
the
all
the
package
names
are
linked
to
the
npm
packages
and,
obviously
no
matter
what
technology
we're
using
on
the
front
end.
If
this
links
these
links
are
not
generated
on
the
front
on
the
back
end,
we
will
have
to
provide
the
same
the
same
functionality
when
we
implement
re-implement
the
viewer
on
the
front
end.
B
This
is
just
related
to
the
fact
that
we
are
moving
away
from
the
back
end
that
handles
this
for
us
to
front
end,
and
this
is
the
interesting
thing
like
potentially,
if
we
look
in
the
future-
and
we
say
okay,
we
still
want
we.
We
do
this
on
the
front
end
and
we
re-implement
all
the
features
that
back-end
provides
us
with.
At
the
moment.
We
we
always
said
we
might
figure
out
that.
Actually,
the
view
is
much
less
performance
because
we
have
to
have
to
do
really
heavy
computations
on
the
front
end.
A
B
How
that's
how
monaco
technically
does
in
general
monaco,
since
monaco
has
this
sort
of
window
right
and
all
the
thing
is
a
virtual
scroller,
scroll
kind
of
virtual
scroll
there
right,
so
monaco
reuses
exist
already
rendered
lines.
So
that's
why
it
applies
the
syntax
highlighting
in
patches.
So
once
light
is
visible,
then
it's
patched
with
with
a
highlighter:
that's
that's
how
it
works.
B
However,
this
is
an
interesting
thing
that
we
will
get
to
in
the
in
the
last
point
of
mind
before
we
get,
but
before
we
get
there
like,
I
was
definitely
I
was
playing
with
that.
Like
challenge
has
been
accepted
so
at
least
for
the
mobile
support,
so
I
have
at
least
two
solutions
now
that
are
both
in
draft
state
of
course.
B
B
No,
I
haven't,
of
course
it's
the
draft.
So
technically
it
applies
the
set
of
transformations
to
the
to
the
source
editor
so
that
the
source
editor
would
be
would
be
not
only
read
only,
but
also
would
support
the
selection
on
the
mobile
and
the
way
we
ex
we
like
the
way
we
do
this
in
this
particular
image
request.
This
particular
extension
is
actually
creating
a
snapshot
of
source
header,
so
we
create
the
source
editor.
B
B
We
put
it
into
the
into
the
dom
that
snapshot
and
we
hide
the
original
editor.
So
the
original
idea
is
not
rendered.
We
rendered
the
snapshot
with
exactly
how
the
source
editor
has
been
looking
before.
Why
we
have
to
do
this
in
order
to
get
rid
of
all
the
event
listeners
from
the
from
the
editor,
so
that
editor's
event
listeners
would
not
prevent
all
sorts
of
interaction
that
users
expect
to
to
have
with
just
plain
text
on
their
screen.
B
As
you
can
imagine,
this
is
pretty
pretty
heavy
thing
like
it's.
It's
not.
I
made
it
as
performant
as
possible,
but
still
we
not
only
pull
in
the
source
editor.
We
also
do
the
like.
Do
the
dom
manipulations?
It's
all
done.
The
the
manipulation
is
done
in
one
go,
so
we
do
not
sort
of
apply
different
like
create
a
lot
of
layout
shifts.
It's
done
in
one
go,
but
still
it's
the
process.
It's
also
done
nicely.
B
So
when
user
hits
the
page,
they
will
still
see
the
editor
at
first,
but
then
over
time,
since
we
are
creating
the
snapshot
of
exactly
how
the
source
editor
looks
like
this,
real
editor
will
be
substituted
with
the
snapshot,
but
it
won't
be
noticeable
by
users,
because
so,
if
they
will
be
very
fast
to
click
in
the
editor,
when
they
hit
this
page,
they
will
actually
be
able
to
edit
the
file,
but
that
about
like
200
milliseconds
after
the
editor
will
be
swapped.
With
the
plain
snapshot
of
the
editor
so
and
visually
it.
B
There
won't
be
happening
anything
because
the
snapshot
will
take
exactly
the
same
place.
All
the
elements
will
be
exactly
the
same
places
as
the
editor,
so
there
will
be
no
layout
shift
or
anything
like
this.
Okay,
so
the
benefits
of
this
it's
it's
easy
to
adapt
it's
easy
to
implement
like
all
the
abstractions.
All
the
magic
is
hidden
in
the
extension,
so
it's
just
the
matter
of
creating
the
instance
and
applying
the
extension
done.
B
It's
also
very
convenient
to
switch
between
the
edit
and
view
right
because,
technically
what
this?
What
this
extension
does
is
already
creates.
This
smooth
bridge
between
view
and
edit
right,
we
it's
just
a
matter
of
hiding
one
element
and
showing
another
element
when
we
when
we
have
to
edit
the
file.
B
It's
also,
it
also
provides
the
unified
syntax
highlighting
between
edit
and
view,
because,
right
now
we
have
very
inconsistent
syntax
highlighting
right
because
in
the
editor
we
use
the
monaco
syntax
highlighting
highlighter.
While
on
the
view
we
use
rouge
and,
as
we
said,
the
syntax
highlighting
not
only
the
language
support
is
different,
but
the
the.
If
you
take
exactly
the
same
file
open
it
in
monaco
and
now
view
it
on
in
generated
on
the
viewer
by
backhand
in
rouge.
B
A
A
B
A
B
Okay,
so
that's
that's
the
thing
this
is.
I
think
I
still
think
this
is
the
the
the
pro
I
mean
if
we
fix
the
language
support
language
support
for
one
place
for
the
editor,
it
will
be
in
the
viewer
right
away.
So
that's
that's
technically
the
positive
thing
in
the
long
run,
because
we
will
have
one
source
of
truth
and.
B
A
A
That's
why
we?
I
really
want
to
see
a
site
speed
for
this,
because
right
now
we're
flying
blind,
because
we
don't
know,
what's
the
proportion
of
the
tbt?
Is
it
10
seconds?
Is
it
a
minute
like
we
don't
know,
and
it
would
be
really
nice
so
jacques
we'll
probably
prioritize
adding
that
into
the
tests
as
a
deliverable
just
to
have
time
for
it
yeah.
But
anyway,
sorry,
I
cut
you
off
dennis
go
ahead.
You
have
more
scenarios
to
present.
B
Yes,
so
this
one
was
sort
of
the
the
most
straightforward
one
right
so
read
only
extension
set
up
this
source
editor.
There
are
calls.
Obviously
it's
hacking
so
to
speak.
It's
like
we
have
to
prevent
to
to
create
this
switch.
It
might
have
the
implication.
I
have
no
idea
whether
it
will
have
any
implication,
but
there
is
no
matter
what
we
do
there.
There
always
might
be
the
performance
implications,
so
it's
better
to
write
it
down
and
again
we
do
not
benefit
from
like
we.
B
So
we
cannot
use
that
one
for
for
the
playing
strings
of
tags
that
we
put
into
the
code
code
blocks
when
we,
when
we
are
talking
about
front-end
solution
for
viewing
the
blobs
right
when
we
do
not
want
back-end
to
generate
the
markup
for
us,
so
syntax
existing
syntax,
highlighter
module
is
out
of
question.
So
we
in
this
second
merge
request.
We
are
using
we're
piggybacking.
B
What
monaco
gives
us
already,
so
we
just
take
that
text
and
we
colorize
it
and
apply
the
theme
very
lightweight
solution,
very
easy
to
to
use
it
creates
the
component.
It
creates.
The
sort
of
it
creates
the
possibility
for
us
to
to
actually
remove
the
markup
generation
for
any
for
any
content
type
for
notes,
for
descriptions
for
anything
for
that
matter
in
the
product
and
just
rely
on
this
one
solution
where
we
use
monaco
to
colorize
the
elements
in
the
code
block
and
to
apply
the
current
theme
do
like
this
solution
a
lot.
B
It
uses
the
technologies
that
we
already
have
in
the
in
the
stack.
It's
very
lightweight.
It
doesn't
have
no
new
dependencies.
As
I
said,
it
has
very,
very
good
potential
and
it's
very
easy
to
use.
So
if
you
take
a
look
at
that
merge
request,
I
think
there
is
a
I'm
not
sure
whether
yeah
I
was
playing
there
with
with
the
text
viewer.
B
B
A
B
B
All
right,
it's
in
the
tails
and
the
source
editor
utils,
so
we
have
the
colorize
method
in
monaco
that
goes
through
the
code
and
set
transforms
them
transforms
the
markup
to
include
to
add
those
spans
with
special
classes
to
to
to
hook
up
the
styles
okay.
So
this
is.
This
is
by
far
much
easier
solution
than
the
read
only
extension.
B
But,
of
course
the
problem
is
that
we
all
of
a
sudden
we
lose
the
benefit
of
fast
switch
between
view
and
that
it
will
still
be
faster
than
we
have
now,
because
we
will
already
have
monaco
there
right.
So,
switching
to
the
to
the
edit
interface
won't
take
like
more
than
50
milliseconds,
or
something
like
that.
So.
A
Dennis
I
wanted
to
take
this
opportunity
to
say
that
I'm
I'm
prioritizing
less
and
less
this
use
case
of
like
we
don't
have
metrics
for
these,
though
we
could
instrumentalize
it
all,
but
just
from
the
nature
of
the
page
I
can.
I
can
theorize
that
the
views
significantly
outweigh
the
edits
and
we
want
to
prioritize
the
view
for
the
blog
view,
even
if
that
comes
at
a
cost
of
like
choosing
switching
to
edit.
A
What
we
really
wanted
to
prioritize
was
the
move
from
the
folder
navigation
to
the
blob
view
that
one
happens,
a
lot
that
happens
like
pretty
much
every
time
you
go
into
a
folder.
You
want
to
reach
the
end
by
reaching
by
reading
a
blog
view.
Editing
is
not
so
common,
so
if
we
lose
a
little
bit
of
that
optimization,
I'm
okay
with
that
and
from
all
of
this
that
you're
presenting
to
me
the
biggest
thing
is
the
language
support
and,
of
course,
performance,
but
okay
right
but
yeah
the
view
in
edits.
B
That
that
makes
total
sense
that
makes
total
sense,
especially
since,
even
if
we
pull
in
the
whole
source
editor
without
preloading
monica
without
prefetching,
I've
had
that
draft
merge
request
for
the
snippets
where
we
did
this
and
it
was
pretty
fast
anyway,
it
was
manageable,
even
if
we
do
not
reload
now
with
all
the
preloads.
It's
it's
going
to
be
faster.
A
A
B
B
B
Yeah,
it's
lightweight
it's.
It
has
broader
language
support
and
very
close
to
rouge,
if
not
wider.
It's
potentially
potentially
has
better
performance
support
performance
like
lower
performance
impact.
Comparing
to
the
monaco.
However,
again
we
have
to
take
this
with
a
pinch
of
salt,
because
monaco
is
already
pre-loaded
on
those
on
the
views
from
the
repository
highlight,
gs
is
not.
Moreover,
now
we
are
going
to
get
into
the
cons
of
the
highland
gs
solution.
Highlight
gs
is
not
the
direct
dependency
of
gitlab.
B
B
B
However.
We
have
to
like,
as
with
any
new
dependence,
we
have
more
things
to
support.
We
have
technically
a
bit
worse
and
maintenance,
but
that's
those
things
might
not
be
worth
considering
if
we
take
the
the
language
support
of
highlight
gs.
So
that's
that's
another
solution.
Obviously
39
kilobytes
for
the
minified
javascript,
okay,.
A
B
B
A
B
B
Where,
where
monaco
creates
problems
like
they
are,
they
are
easily
like
the
second
solution
and
both
solutions
fixes
the
problem
fix
the
problem
right
and
second
solution,
fixes
it
in
a
bit
better
way,
but
technically
highlight
gs.
As
I
said,
effectively
highlight,
gs
is
the
same
as
the
second
solution,
with
broader
language.
Support
right.
Keep
in
mind
also
that
by
using
the
highlight
gs,
we
do
not
put
monaco
anywhere
right,
so
monica
will
still
be
loaded,
so
those
38
kilobytes
are
addition
like
38
kilobytes
is
nowhere
near
the
monstrous
monaco.
A
But
I'm
just
thinking
about
what
is
the
best
way
to
cover
these
problems,
while
still
supporting
what
we
want,
which
is
to
do
syntax
highlighting
on
the
on
the
front
end
check,
have
at
least
the
same
kind
of
level.
Support
of
syntax
highlighting
is
rouge
check
kind
of
I
haven't
checked
just
because
it
has
more
doesn't
mean
it
has
the
same
and
it
doesn't
harm
the
mobile
which
is
yeah.
So
the
the
the
I
checked,
and
I
think
I
can.
A
A
B
That's
like
those
both
of
those
two
solutions.
Give
you
by
the
end
of
the
day,
give
more
or
less
the
same
result.
You
will
just
see
the
plane
pre
like
pre-code,
set
of
elements
for
the
for
the
for
the
viewer
right.
It's
just
the
first
one
with
the
read-only
extension
will
be
much
more
massive
because
it
will
bring
a
lot
of
dome
craft
from
the
source
editor,
while
the
second
solution
will
be
will
be
very
lightweight.
A
B
They
took
they
took
the
the
lowest
hanging
fruit,
let's
say,
but
I'm
I
will
still
probably
since
since
I
already
have
the
emergency
quest
of
moving
those
utilities
for
colorizing
and
applying
the
theme
to
monaco,
I
moved
those
into
the
source,
editor
utilities,
for
reusing
in
the
in
the
product
for
broader
reuse
in
the
product.
I
will
suggest
them
to
actually
convert
to
to
using
that
using
exactly
the
second
option.
B
Okay,
that
for
for
the
time
being,
however,
if
we
will
pursue
the
highlight
gs
path,
well,
we
have
to
strive
for
unified
application.
It
has
to
be
properly
componentized.
It
has
to
be
properly
librarified
if
you
wish,
so
that
we
could
use
one
way
of
syntax
highlighting
in
the
product
instead
of
relying
on
myriads
of
those
and
then
then
I
would
suggest
to
remove
the
monaco
highlighter
from
from
the
view
interfaces.
A
A
B
A
A
B
If
you
take
a
look
at
the
emergency
at
the
second
merge
request
like
where,
instead
of
the
instead
of
importing
from,
for
example,
setup
code
snippet
from
the
editor
utils,
we
will
just
import
from
some
highlight
gsu
tails
or
something
like
this
and
do
do
exactly
the
same
thing
so
architecturally.
This
is
the
solution.
I
would
go
for
the
second
one,
because
it
it
allows
us
to
easily
switch
the
backbone
of
this
solution.
It
can.
B
A
B
Or
outside
of
the
sharing
file
yeah
outside
of
the
circuit
component,
we
can
again,
if
you
take
a
look
at
that
mer.
Second
merge
request,
so
there
are
two
sort
of
two
layers.
So
it's
the
audience
solution,
the
core
of
it.
Is
this
code
block
snippet?
Let
me
just
share
my
screen.
Go
ahead.
That
will
be.
B
B
This
comes
from
the
parent
component
that,
if
it
wants
to
implement
the
link
to
line
functionality,
so
this
is
the
only
thing
that
adds
more
or
less
complexity
to
this
component
right,
because
we
need
to
highlight
the
thing.
Otherwise,
things
are
very
straightforward,
and
this
is
the
this
is
the
sort
of
magic
like
when
we
mount
this
component.
We
set
up
code
snippet
and
the
code
snippet,
I'm
sorry.
The
code
snippet
comes
from
editor
utils.
B
So
if
we
are
going
to
use
the
highlight
gs,
for
example,
where
we'll
just
instead
of
importing
for
the
setup
code
snippet
from
editor
utils,
we
will
just
import
it
from
some
highlight
gs
directly
or
from
highlight
gs
utilities.
Something
like
this,
then
all
the
craft
about
the
lines
generation
comes
in
the
parent
component.
So
in
this
particular
case
text
viewer
alt.
B
B
We
calculate
the
number
of
lines
and
that's
what
we
do
like
just
manually,
creating
this
iteration
for
the
line
numbers
and
then
we
set
up
all
the
linking
like
these.
Things
can
be
abstracted,
probably
in
in
the
in
yet
another
util.
So
this
should
not
be
be
a
big
deal.
I
just
didn't
want
to
mess
it
mess
up
with
this
in
this
particular
merchant
quest.
I
just
sure.
A
A
B
If
it's
short
snippet,
you
don't
want
to
show
the
line
numbers
and
also,
if
you
have
several
blocks
like
that
on
the
line
on
the
page,
how
do
you
link
to
to
particular
line
all
the
line?
Highlighting
functionality
now
assumes
one
cold
block
on
the
page.
Otherwise
we
have
to
update
that
mechanism
that
functionality
to
to
support
to
to
be
able
to
distinguish
what
particular
code
block
on
the
page.
We
have
to
link
to
and
highlight
the
link
highlight
the
line.
A
I'm
just
thinking
about
one
thing,
though,
because
that
will
force
us
to
always
or
to
never
wrap
the
line
right
so
in
merge
requests,
the
line
can
wrap
and
you
can
have
multiple
lines,
so
the
line
number
needs
to
adjust
to
the
height
of
the
line
of
the
content,
whereas
on
the
blob
view,
if
you
have
it
on
a
separate
component,
a
separate
container,
you
have
to
have
the
line
numbers
in
one
container.
You
have
the
content
in
another
container
right,
then
the
line
numbers
won't
extend
when
the
line
of
the
content
extends
too.
A
B
A
B
We
can
we
can
it's
not
as
tricky
we
can.
Technically
we
can
go
the
the
github
way
and
convert
this
whole
solution
into
the
table
layout,
where
every
line,
including
the
line
number,
is
the
table
row
and
then
it
wouldn't
matter
for
us
whether
we
wrap
the
lines
where
we
don't
wrap
the
lines,
but
in
this
particular
solution.
If
we're,
if
we
stick
with
the
pre
tag,
then
we
just
have
to
listen
to
like
because
all
the
line
not
wrapping
happens
on
the
wait.
A
second.
A
B
A
One
time,
no,
no,
no,
no,
no!
So
here's
what
I'm
thinking
so
the
way
that
we
do
it
on
the
merger
quest
is
because
it's
super
important
for
you
to
read
the
entire
line
right
on
the
blob
view.
As
a
ux
improvement,
we
might
want
us
in
the
future
support
wrapping
lines.
The
the
difference
here
is
that
we're
grabbing
the
syntax
highlighted
blob
of
markup
and
just
dumping
it
into
a
container
into
a
pre
tag.
The
difference
is
that
we
would
have
to
iterate
into
each
one
of
those
lines
and
generate
a
row.
A
That
right,
exactly
we
just
get
the
html
back,
but
that
sort
of
complexity,
if
we
ever
want
to
do
that,
you
I'd
rather
have
that
complexity
in
a
shared
component
so
that
whoever
consumes
that
doesn't
have
to
worry
about
it.
But
that's
still
on
the
table.
It's
up
to
us
to
to
decide.
I
think
I
don't
think
it's
it's
a
side
topic!
It's
not
related
to
this
hurdles
that
we're
finding
now.
So
we
can
it's
irrelevant
right
now.
I'm.
B
B
A
B
Mean
I
mean
when
we,
when
we
view
the
files
we
have
to
make
sure
that
it
shouldn't
be
the
copy
of
the
source
editor,
as
rendered
on
the
edit
screen.
So
the
very
first
thing
that
stroked
me
was
when
I
went
to
the
view
of
the
blob,
and
it
was
still
this
500
pixels
height
container,
where
I
had
to
scroll
to
the
line
of
the
content
so
yeah.
First
of
first
of
all,
it
has
to
be
expanded
to
contain
all
the
lines,
and
that's
that's
that's
easy
to
do.
B
There
is
one
method
in
monaco
that
that
does
that,
and
both
of
the
merge
requests
that
I
that
I
propose
like
not
proposed
both
merchant
west,
that
I
worked
with
they.
They
fixed
this
this
thing
and
also
like
the
the
the
things
that
I
mentioned
for
for
a
text
selection
on
mobile.
Also,
we
have
to
get
rid
of
this
context.
Menu.
The
right
click
like
there
are
things
that
we
have
to
do
to
source
header
in
order
to
so
technically
the
the.
B
A
So,
okay,
so
thank
you
for
presenting
the
potential
solutions.
I
think
this
is
this
goes
beyond
source
code,
and
I
think
this
could
benefit
from
a
bigger
conversation.
It's
important
to
get
like
some
metrics
in
there
to
get
a
sense
of
how
how
fast
these
things
are.
What
are
the?
What
are
the
costs
in
terms
of
like
performance?
B
That's
the
thing
like
I
have
to
my
plan.
I
have
two
merch
requests
right,
so
I
can
run
on
those
two
things,
but
I
want
to
to
also
have
the
highlight
gs
like
in
integration,
not
the
merge
request,
because,
like
this,
this
falls
into
the
land
of
new
dependency
and
sure
that's
not
what
I
want
to
deal
with,
but
I
will
be.
B
I
will
have
to
create
as
a
proof
of
concept,
brian
branch,
where
we
use
the
highlight
gs
for
these
purposes,
and
then
we
will
be
able
to
run
the
tests.
We
will
be
able
to
run
the
gdk
measure
on
on
all
of
the
three
potential
solutions
on
all
four
solutions.
The
current
one
right,
the
and
the
three
suggested
here
for
the
front
end.
B
A
B
A
So
the
last
question
I
have
is
this:
all
of
this
that
we're
talking
about
is
the
inner
workings
of
the
source,
editor
right
source
editor
in
read-only.
Sorry,
let
me
let
me
step
back,
it's
not
the
inner
workings.
It
might
not
be
the
inner
workings
you
might
be
outside
of
the
source
editor,
but
from
our
perspective,
as
a
consumer
on
the
blob
viewer
right
now,
we
have
to
wait
for
this
decision
and
for
this
whatever
for
the
outcome
of
this
before
we
turn
it.
A
B
A
That
keeps
the
hammel
version
exactly
to
the
the
render
on
the
server
okay,
so
we'll
continue
on
our
refactor
dennis,
but
we'll
follow
closely
and
we
want.
We
want
to
participate
in
helping
in
any
way
we
can.
So
once
you
leave,
feel
free
to
drop
like
a
line
of
stuff
that
that
you'd
like
us
to
work
on
while
you're
out.
B
B
That's
the
main
concern
for
now
sure
because,
as
I
said,
we
might
reduce
the
back
end
time,
but
if
we
are
about
to
re
reintroduce
all
of
the
features
on
the
front
and
like
source
graph
links
generation,
I'm
not
convinced
this
will
be
faster
because
we
technically
we
take
the
functionality
that
is
generated
on
the
server
to
the
to
the
client.
And
then
the
clients
will
suffer
big
times
if
they
are
not
on
the
fast
device.
B
That
that
part
should
be
considered,
but
if
we
did
say
okay,
that's
consider
considering
that
we
still
want
to
move
to
front
end,
then
the
the
way
I
would
envision
this
would
be
to
to
go
for
the
option
number
two
right
away
and
then
keep
in
mind
that
we
just
because
technically
there
will
be
no
big
difference
between
doing
the
implementing
the
option.
Number
two
with
monaco
or
with
highlight
gs.
B
As
I
said
it's
just
this
switch
of
the
backbone,
all
the
rest,
all
the
line,
highlighting
things
all
the
things
really
to
generating
the
the
markup
and
things
they
will
still
keep
still
be
the
same.
So
I
would
go
for
that
option
as
the
intermediary
get
the
benefit
of
a
faster
rendering
time,
and
then
we
will.
We
might
want
to
improve
this
with
the
highlight
gs,
to
improve
the
language
support
and
have
better
syntax,
highlighting
question.
B
Technically,
keep
in
mind
that
implementation
of
the
source
graph
and
a
generation
of
the
links
while
like
they
are
out
of
question
when
we
pick
whether
we
do
the
the
syntax
colliding
in
monaco
or
in
highlight
gs,
because
those
two
things
will
have
exactly
the
same
performance
impact
on
both
solutions.
Right.
A
A
B
B
B
A
It's
okay
because
you're
not
blocking
us,
so
we're
totally
okay
to
go
ahead
with
the
refactor
anyway,
until
until
you're
back.
So
it's
more
about
evolving
the
conversation
and
making
the
decisions
together.
I
think
it's
important
to
to
have
a
wider
conversation,
so
my
my
proposal
would
be
the
next
time
we
have
this
meeting
to
have
it
at
a
later
time,
so
we
can
have
himanchu,
oh
well,
he
wants
you
can.
A
Yeah
so
so
paul
is
not
depositing
america,
but
I
would,
I
would
really,
and
eric
is
in
america
too,
eric
shorter,
yep
yep.
So
since
this
this
is
a
topic
that
affects
many
people,
we
might
want
to
move
that
to
a
later
time
and
invite
them
because,
but
for
that
we
would
have
to
have
more
more
numbers
and
stuff
or
we
have
a
separate
call
whatever
we
want
to
do.
A
Go
on
with
that,
yes,
yeah!
Okay,
so
it
sounded
something
like
that.
So
that
is
a
deal
breaker
for
us
and
I
I
we
should
have
seen
it
before.
Apologies
for
that,
but
apart
from
that,
this
is
really
good.
We're
making
progress,
we're
changing
things
and
breaking
things
and
that's
how
we
like
to
do
things
yeah
all
right,
we're
out
of
time
way
over
time.
Thank
you!
So
much
anything
before
we
go.