►
From YouTube: Source Editor Deep Dive #4
Description
Group level conversation about Source Editor and its architecture
A
Hello:
everyone
today,
we
are
at
our
fourth
edition
of
source
editor
deep
dive.
This
particular
edition
is
going
to
be
dedicated
to
answering
all
the
questions
and
addressing
all
the
all
the
topics
that
might
not
have
been
covered
previously
regarding
the
source
editor
regarding
different
decisions
made
in
the
source
center.
Why
we
built
it
how
we
build
it?
Why
we
built
that
or
another
feature
this
way,
and
not
the
other
way
and
obviously
we'll
have
the
open-ended
session,
where
we
will
be
able
to
ask
questions.
A
A
B
A
C
B
A
D
A
A
Cool
area,
so
let
me
just
okay,
so
the
source
editor
we
all
know
by
now.
It
used
to
be
cold,
editor,
light
long
long
time,
yeah.
Once
upon
a
time
there
was
an
editor
called
edit
alive,
and
then
we
renamed
it
to
source
editor.
So
I
think
this
is
actually
the
very
first
deep
dive
for
particularly
source
editor.
All
the
previous
ones
were
for
added
light
for
anybody
tuning
in
to
this
recording
all
the
deep
dives
for
editor
light
were
are
still
valid
for
source
editor
and
vice
versa.
A
That's
why
we
have
content
editor
where
you
work
with
the
content,
edit
content
and
source
editor,
where
you,
edit
source
you
create
source
source.
Editor
is
pretty
young
editor
technology,
whatever
it
has
been
in
implementing
gitlab
for
about
a
year,
maybe
actually
maybe
less
than
that,
and
it's
still
in
the
very
early
days,
and
we
still
try
to
figure
out
correct
solutions.
Correct
implementations
for
different
features,
but
in
general
source
editor,
is
a
very
thin
wrapper
around
monaco.
A
A
The
source
editor
is
just
a
thin
wrapper,
providing
some
convenient
abstractions
on
top
of
monaco,
but
that
which
is
which
still
allows
to
get
to
the
core
monaco
api
for
anybody
implementing
instances
of
source
editor
in
general
who's
using
source
editor
in
gitlab.
This
slide
hasn't
been
finished
as
well.
A
I'm
sorry,
but
the
primary
user
of
sourceheader
is
obviously
ourselves.
The
editor
group,
the
source
editor,
is
used
in
snippets
web
id
single
file
editor.
It
is
also
used
in
pipeline
editor
in
the
in
I
was.
I
was
literally
right
before
this
school.
I
was
trying
to
find
a
place
where
wrote
down
all
the
users
of
source
editor
and
I
failed.
I
didn't
I
couldn't
find
it.
I
wrote
it
down
in
some
agenda
file
that
that
is
gone
for
now,
but
its
pipeline
editor
is
powered
by
with
source
editor.
A
It's
it's.
The
security
policy,
editor
powered
with
source
editor
and
it's
one
more
use
in
related
to
pipelines,
but
I
don't
remember
where
exactly
I'm
very
sorry.
In
general,
the
source
editor
is
used
in
in
different
sections,
so
security,
ci
authoring,
editing
experiences,
so
source
editor
is
pretty.
Let's
put
it.
This
way
it's
pretty
well
tested
by
ourselves
and
by
our
users-
and
this
gives
us
very
good
basis
to
say
that
source
editor
is
pretty
stable
piece
of
software.
A
A
There
is
a
warning:
not
everything
isn't
mastered
yet
so,
if
you're
watching
this
video,
beware
that
things
that
you
will
see-
and
we
will
hear
about-
might
not
have
been
implemented
in
master
yet
and
might
have
not
been
implemented
master
for
a
good
reason,
because,
as
I
said,
this
is
an
early
technology
and
we
are
still
working
our
path
through
this.
So
the
power
of
source
editor
comes
from
extensions.
A
Before
we
proceed
and
talk
about
extensions,
we
have
to
mention
that
there
are
several
paradigms
several
architecture
elements
when
it
comes
to
source
editor.
There
is
a
global
editor
global
editor
object.
That
is
the
editor
created
by
monaco
using
the
source,
editor
tools,
but
it's
kind
of
the
monaco
editor.
Then
there
is
an
instance
that
we
have
two
types
of
instances.
We
have
a
code
instance
and
we
have
div
instances.
Diff
instances
at
the
moment
are
used
only
in
web
id.
A
I
believe
I'm
not
sure
about
I'm
not
aware
of
any
work
in
progress
in
that,
but
we
have
two
types
of
instances:
code
instance
and
div
instance
this
this
this
instances
again
in
source
editor
world,
follow
the
same
paths
of
code
instance
and
div
instance
in
the
moniker
world.
So
the
api
of
diff
instance
in
monaco,
for
example,
that
you
find
in
the
documentation
for
monica
will
work
in
the
for
the
div
instance
of
source
header
as
well.
A
However,
source
editor
provides
some
extends.
The
the
core
monaco
api
with
some
convenient
functions
that
we
will
be
talking
about
a
bit
later
so
two
types
of
instances.
The
instance
is
the
very
basic
element
of
the
of
the
source
editor
and
in
in
terms
of
ui.
You
can
think
about
instance,
as
a
complete
window
with
the
editor
when
you
get
to
edit
a
file
in
the
repository
you
see
the
editor.
This
is
one
instance.
A
A
It
is
convenient
because
we
can
pass
different
configuration
parameters
to
different
instances
based
on,
for
example,
file,
extension
of
that
or
another
snippet
we're
working
with.
At
the
same
time,
we
can
pass
configurations
to
all
of
the
snippets
at
the
same
time
using
this
global
editor
on
top
of
all
the
instances.
So
it's
pretty
solid
structure,
so
we
either
configure
everything
all
at
once
or
we
have
enough
tools
to
granularly
control
every
instance
on
the
page.
So
this
is
instance,
the
instances
are
extended
with
the
extension.
A
So
this
is
where
all
the
power
of
source
editor
comes
comes
from
extension
is,
is
a
piece
of
software,
a
code.
It
can
be
any
anything.
We
will
talk
about
different
types
of
extensions
a
bit
later,
but
technically
it
provides
additional
functions,
additional
methods,
additional
properties
to
that
particular
instance.
Extensions
are
applied
on
the
instance
level.
We
can
apply
extensions
through
the
global
editor,
but
then
global
editor
will
still
take
that
extension
and
apply
to
all
of
the
instances
initialized
by
this
global
editor,
so
extension
is
applied
on
the
instance
level.
A
The
extensions
can't
be
this
is
a
bit
hardcore
to
those
not
working
with
the
code
at
the
moment.
I'm
sorry,
but
we
will
get
to
to
fund
things
a
bit
later,
so
extension
can
be
in
an
es6
class,
including
a
class
that
extends
another
extension.
So,
for
example,
you
can
create,
let's
assume
we
have
at
the
moment
in
the
code
base.
We
have
several
extensions
that
are
already
written
so
and
you
find
an
extension
that
is,
that
sort
of
meets
your
expectations.
A
Does
what
you
need,
but
you
need
to
tweak
it,
so
you
can
create
your
extension
as
an
extension
of
the
existing
extension
so
kind
of
like
build
this
chain,
and
you
just
tweak
the
existing
extension
in
your
part
without
breaking
or
changing
anything
in
the
original
extension.
This
is
super
handful
helpful,
because
the
the
way
this
whole
work
around
source
header
works
from
the
organizational
level
is
that
we
as
this
as
the
editor
group,
are
responsible
for
maintaining
the
core
of
the
source.
A
Editor,
however,
delegate
delegating
the
responsibility
of
maintaining,
creating
and
changing
the
existing
extensions
to
the
respective
groups,
who
need
that
or
another
extension.
So,
for
example,
ci
editor
group,
I'm
sorry,
ci
authoring
group
created
the
extension
for
for
the
ci
files,
so
they
are
maintained.
They
are
working
with
that
extension
and
anybody
in
the
in
in
the
company
can
use
that
extension
for
their
particular
use
of
the
source
editor.
Should
they
need
that
they
they
can
also
use
that
extension
as
the
basis
and
then
extend
from
that
one.
A
I'm
sorry,
I
need
to
admit
paul.
So
probably
I
need
to
exit
the
does.
Anybody
else
have
the
manager
rights
here?
No,
okay!
Let
me
just
do
this
I'll,
admit
paul,
and
we
get
back
to
this.
So
this
I'm
sorry,
I
was
skipping
the
things,
so
this
organization
allows
us
to
build
the
very
collaborative
and
evolving
environment
around
source
header,
so
we
can
also
present
extensions
as
a
function.
A
This
is
very
not
advised,
but
if
the
extension
is
really
about
just
one
method,
for
example,
it
might
be
not
viable
to
create
extent
an
extension
as
the
standalone
file,
yet
it
is
advised,
but
for,
for
example,
when
we
test
things
create
the
and
create
some
tests
used
for
for
source
editor.
This
might
be
quite
handy
to
create
extension
as
the
inline
object.
A
So
how
does
the
extension
work
in
the
source
header?
Let's
talk
about
the
current
architecture
of
extensions?
This
is
how
it
is
done
now.
We
talked
about
this
with
the
majority
of
the
group
yesterday
and
at
the
moment
we're
using
the
mixing
pattern
of
applying
an
extension
to
the
instance.
What
does
it
mean?
It
means
that
extension.
A
There
are
good
things
about
this
approach.
It
just
works.
It's
pretty
trivial
to
understand
it's
very
trivial
to
implement.
It
is
easy
to
maintain
and,
as
I
said
during
more
than
one
year
of
existence
of
this
architecture,
we
didn't
have
any
complaints
so
far.
However,
as
the
engineers
we
understand
that
this
approach
is
far
from
being
optimal
and
the
the
fact
that
this
architecture
didn't
bite
us
so
far
is
just
pure
lacquer.
I
guess
so.
A
There
are
obvious
issues
with
this
approach.
First
of
all,
we
are
mutating
the
instance.
What
does
it
mean?
Is
that
we
take
something
that,
especially
since
we
are
building
our
instances
on
top
of
monaco
instance,
and
then
we
start
all
of
a
sudden
start
changing
the
public
api
of
this
thing.
This
is
not
very,
very
good
approach
and,
as
I
said,
it
might
bite
us
in
the
future
and
also
we
cannot
unuse
an
extension.
A
A
At
the
moment,
I'm
gonna
talk
about
proxy
architecture,
so
we
have
the
instance
that
is
the
thin
layer
over
on
top
of
monaco
and
we
have
extension
with
bf
extension.
That
brings
a
lot
of
functionality,
so
in
prox
architecture,
what
happens
is
instead,
of
instance,
swallowing
the
extension
when
we
call
instance
use
extension
is
wrapped
around
the
existing
instance
as
a
proxy,
so
we
still
keep
the
original
instance,
but
we,
the
whole
thing,
is
created
as
proxy.
What
does
it
mean?
A
The
interesting
thing
happens
is
if
we
want
to
apply
another
extension,
so
that
another
extent
that
second
extension
will
swallow
the
first
proxy
creating
the
new
proxy.
This
is
totally
valid
architecture
pattern
creating
proxy
on
prop
on
top
of
proxy
in
this
particular.
In
this
case,
we
will
still
preserve
the
original
instance
and
what
happens
if
we
request
the
property
from
this
newly
created
proxy
with
two
extensions,
the
the
proxy
will
check
whether
we
have
this
property
on
the
extension
number
two.
If
we
don't,
if
we
do,
it
will
return
this
property.
A
This
means
that
the
in,
but
the
inner
proxy
follows
exactly
the
same
pattern,
so
the
inner
proxy
will
in
order
to
return
this
property,
it
will
request
the
first
extension
first.
If
it
doesn't
find
the
property
on
the
extension,
it
will
go
to
the
instance
and
return
from
the
instance,
but
that
thing
like
this
whole
first
proxy.
A
A
The
layering
is
pretty
straightforward,
with
very
basic
name.
Conflict
resolution
lost
in
first
out
so
the
x.
If
we
have
two
extensions
with
exactly
the
same
property
or
exactly
the
same
name,
the
last
one
wins
so
the
last
one
that
has
been
applied,
the
value
of
that
property
will
be
returned
when
requested,
not
the
property
of
the
inner
inner
extension.
A
A
A
A
Then
we
remove
the
one
of
the
extensions
and
then
reassemble
the
proxy
back
again.
So
in
this
particular
case
we
had
to
get
treat
or
unuse
the
first
extension
we
dissect
this
whole
proxy,
remove
the
first
extension
out
of
the
equation
and
assemble
the
the
new
proxy
object,
so
wrap
instance
with
the
second
extension.
A
It's
pretty.
It
looks
more
or
less
straightforward
on
the
slide,
however,
technically
it's
not
very
straightforward,
so
we
might
approach
it
differently
and
shift
the
paradigm
a
bit.
So,
instead
of
saying
that
every
time
we
apply
an
extension
to
the
instance,
we
wrap
this
whole
combination
in
a
proxy.
What
we
can
do
is
actually
ev.
Whenever
we
create
an
instance,
we
get
proxy
right
away,
so
the
instance
itself
is
going
to
be
proxy
when
we
apply
when
we
call
instance.use
method.
A
A
This
is
more
robust
solution.
This
is
not
the
russian
doll
architecture
anymore.
Technically
I
had
I
had
to
change
the
title
here.
This
is
more
of
a
hybrid
of
approach
here.
I
think
this
might
be
more
solid
and
more
robust
solution,
because
we
have
we
create
only
one
proxy,
no
matter
how
many
extensions
we
create.
We
do
not
wrap
proxy
into
proxies
that
that
is
very
soothing
point,
as
I
said,
this
is
very.
This
is
valid
pattern
to
wrap
proxy
in
the
proxy.
A
Now,
indeed,
why
don't
we
discard
the
instance
with
the
extensions
we
don't
need
anymore
and
create
the
new
instance
with
the
extensions
we
we
need.
Why
not
this?
And
I
think
this
is
not
only
can
we
this
is
we
have
to.
This
is
the
way
to
do
the
things,
because
it
makes
the
whole
architecture
so
much
easier.
So
I
would
go
on
and
say
that
we
do
not
use
extensions.
We
have
to
follow
the
path
that
is
already
established
in
the
content
editor
and
in
source
editor.
A
Whenever
we
need
to
unuse
extension
or
extensions,
we
just
discard
the
existing
instance
and
create
the
new
one
with
the
extensions
we
we
need,
because
technically
it's
not
going
to
be
very
heavy,
because
all
of
the
extensions
are
already
should
be
in
cash.
Those
extensions
that
have
been
used
and
those
extensions
that
we
need
to
download
like
the
new
extensions
they
will
have
to
be
downloaded
anyway.
So
this
is
a
very
this
is
pretty
cheap
operation.
A
It
will
have
some
impact
on
the
cpu,
probably
on
on
the
ram,
but
not
that
not
that
big
impact.
So
I
would,
I
would
just
want
to
say
that
probably
we
should
not
unuse
extensions
at
all
in
source
cedar,
and
this
is
this
this.
This
message
from
himanshu
was
an
eye-opener
for
me
and
I
was
puzzled
the
whole
evening
yesterday
thinking.
Why
didn't
I
think
about
it
myself?
A
This
is
not
advised
to
use
this
in
the
production
code
and
you
should
always
think
before
you
do
this.
This
is
primarily
for
the
tests
and
in
the
production
code,
you
always
have
to
have
to
evaluate
them
an
opportunity
to
move
your
extension
into
the
external
file,
because
that
will
increase
maintainability
and
the
code
quality
overall,
but
in
general
this
is
still
available
in
line
extension.
This
is
this
is
just
the
very
basic
task
here,
no
just
just
visual
clue
whether
it
works
or
not.
So
what
do
we
do?
Is
we
initiate
the
create?
A
The
editor
instance
we
use
the?
U
dot.
Use
is
the
main
function.
That
applies
an
extension
in
this
particular
case.
We
apply
the
inline
extension
with
the
property
foo
and
the
method
alpha,
and
then
we
just
go
on
and
try
finding
those
things
in
the
resulting
instance,
and
that's
that's
the
snippet,
the
code
snippet
that
you
can
create,
you
can
add
into
your
console
it
and
it
should
work
as
long
as
you
have
this
editor
instance
definition,
and
in
order
to
get
that
there
is
the
snippet
a
linked
into.
A
So
let's
talk
about
a
more
standard,
more
conventional
extension,
so
extension
as
e6
class
located
in
an
external
file.
So
things
are
pretty
simple
here
as
well,
so
we
import
an
extension
oops
too
early,
so
we
import
an
extension
create
instance
and
use
that
extension
as
simple
as
that,
exactly
as
we
did
with
inline
extensions,
just
use
the
real
real
module
instead
of
the
inline
function.
So
we
can
simplify
this
thing
and
use
like
just
remove
one
line
that
was
instantiating
the
constant
for
the
extension.
A
So
we
can
do
that
in
line
in
in
the
use
call.
We
can
also
work
with
functions,
so
no
new
keyword
done
a
basic
extension
and
that's
it
and
we
also
can
go
bananas
mode.
That's
like
all
possible.
Things
are
supported,
so
the
use
method
in
source
editor
supports
array,
so
you
can
pass
either
one
a
single
extension
or
an
array
of
the
extensions.
This
is
the
example
of
an
array
of
extensions,
so
here
we
create,
we
add
extension
as
an
as
es6
class
as
a
function
as
an
as
es6
class
with
parameters.
A
A
A
There
is
one
thing
to
note
here:
we
actually
have
the
name
conflict
in
this
particular
case,
so
we
have
parameter
foo
added
by
the
by
the
x
with
options2
extension
and
we
have
full
property
in
the
inline
extension,
so
name
conflict.
As
we
have
previously
mentioned.
We
are
following
the
last
in
first
out
principle,
so
the
last
extension
wins
here,
so
the
foo
property
from
the
inline
extension
will
win.
A
So
what's
next,
there
is
the
epic
are
related
to
the
source
editor
to
further
future
source
editor
work
and
the
main
points
there,
in
my
opinion,
are
the
toolbar.
So
we
are
going
to
create
the
mvc
for
the
toolbar
for
the
source
editor
and
this
this
toolbar
will
be
used
for
different
purposes.
For
opening.
Some
panels
like
like,
for
example,
markdown
live
preview
will
be,
will
have
a
dedicated
button
on
this
toolbar.
A
The
toolbar
can
be
used
for
will
will
be
used
for
any
type
of
sort
of
quick
access
commands,
but
we
will
we're
still
figuring
out
what
else
will
be
in
that
toolbar
proper
support
for
extensions
in
the
view
component,
so
source
editor?
There
is
the
source
editor
view
component
and
it
is
used
in
several
places
in
the
product
as
well.
For
for
some
of
the
implementation
that
I
was
talking
about.
A
The
problem
is
that
the
view
component
doesn't
properly
support
extensions,
so
the
extension
in
order
to
apply
extensions
to
your
view
to
the
source
editor
introduced
as
view
component,
one
needs
to
actually
get
access
to
the
to
the
editor
itself.
That
is,
that
is
exposed
on
the
view
component
and
then
do
the
do.
The
same
thing,
like
instance,
dot
use
on
that
on
that
editor.
A
This
is
not
very
convenient,
and
I
would
much
rather
see
us
just
providing
the
list
of
the
extensions
as
the
string
parameter
to
when
we
create
the
view
component
when
we
reference
the
view
component
in
the
in
the
templates
support
language,
moniker
option
and
source
header.
This
is
this
sounds
sounds
a
bit
odd,
but
the
the
thing
is
that
we
do
support
the
moniker
the
language
moniker
option
by
default.
A
However,
there
is
one
specific
case
where
we
do
not
follow
it,
and
it's
when,
when
we
create
an
editor
for
a
file
that
won't
change
its
extension,
so
there
are
no.
There
is
no
input
field
that
would
allow
changing
the
extension.
So
you
definitely
know
what
type
of
file
you're
going
to
edit
there
for.
This
is
true,
for
example,
for
the
pipeline
editor,
where
you
know
that
you're
going
to
be
working
with
the
dot
yaml
file
right.
A
So
in
order
to
to
to
support
the
syntax
highlighting
for
for
the
sender,
we
still
have
to
specify
what
line,
even
though
we
do
not
provide
any
name
for
the
file.
We
have
to
provide
the
language
parameter
to
this
to
this
editor,
so
that
it
would
provide
the
proper
syntax
highlighting
up
until
now.
What
we
do
is
we
were
tricking
the
source
editor
by
passing
the
asterisk.yaml
as
the
file
name,
parameter
and
then
source
editor
would
understand
that
it
works
with
the
with
the
yaml
file
in
it
in
itself.
A
But
monaco
provides
the
support
for
language
options,
so
we
have
in
for
this
particular
cases.
We
just
have
to
be
able
to
specify
language.language
equals
yaml
and
not
hack
around
with
the
with
the
abstract
path
name.
So
this
is.
This
is
kind
of
like
convenient
thing
for
to
improve
the
developer
experience
and
improving
the
markdown
live
preview.
There
is
a
separate
epic
with
different
ideas
and
different
steps
that
we
might
take
there.
A
This
is
really
to
to
make
to
move
it
to
the
next
level
and
one
of
the
things
that
are
not
wrapped
into
an
issue
yet
would
be
again
work
together
with
the
content
editor
to
figure
out.
How
can
we
generate
the
markdown
live
markdown
preview
on
the
client
instead
of
making
the
server
request
every
time
user
makes
changes
in
the
in
the
editor.
A
So
another
thing
that
I
I
was
desperately
trying
to
find
the
trolling
smiling
face
for
this
particular
slide,
because
this
is
this
is
the
topic
that
had
a
lot
of
hit
in
our
group,
so
source
editor
for
viewing
the
files.
This
is
the
for
those
who
are
not
familiar
with
this.
The
context
is
that
the
source
code
group
is
working
on
refactoring,
the
blob
view
blob
view
for
repository
and
one
of
the
ideas
there.
A
The
one
of
the
problems
that
they
have
there
is
that
generating
a
preview
of
any
file
on
the
server
is
pretty
pretty
heavy
task,
especially
if
a
file
is
big
enough,
so
we
had
one.
We
have
one
in
one
instance
in
our
performance
testing
setup,
where
we
have
a
file
that
that
takes
about
50
seconds
to
output
on
the
screen,
in
particular
due
to
the
very
heavy
operations
on
the
back
end.
A
So
the
idea
was
to
use
the
source
editor
for
rendering
the
view
of
the
file,
because
in
this
particular
case
then
we
would
not
need
to
to
have
back
end
generate
the
preview
for
us.
We
would
just
toss
the
raw
content
into
the
source.
Editor
and
source
later
would
present
the
present
the
content
of
the
file
to
us
in
the
in
the
read-only
mode
of
course.
A
So
the
debate
was
pretty
interesting
and
I
came
up
with
three
different
merge
requests
that
I
didn't
link
here.
But
if
anybody
is
interested,
I
can
find
those
links
so
three
different
emerging
quests
for
source
code
group
to
evaluate
so
first
is
the
read
only
extension
for
source
editor.
So
it
sets
up
source
editor
with
all
all
properties
and
all
options
that
make
sense
for
the
read-only
experience.
A
A
So
this
as
himanshu
game
himanshu
brought
brought
up,
wasn't
really
a
good
idea
because,
because
of
the
cpu
because
of
ram,
and
in
particular
because
of
the
differences
in
syntax,
highlighting
between
what
we
get
in
rouge,
when
we
generate
the
previews
on
the
server
and
the
syntax
highlighting
in
monaco
like
the
number
of
languages
supported
in
these
two
is
pretty
signif,
pretty
significantly
different,
so
source
editor
was
you
one
of
the
merge
requests
is
for
source
read-only
mode.
Another
merge
request.
A
So
that's
that's
another
story
that
brings
us
further
from
source
hitter,
but
to
those
who
were
worried
about
whether
we
are
actually
gonna
use
source
editor
for
viewing
the
files.
This
is
not
settled.
This
is
still
the
work
in
progress
and
we
are
still
discussing
the
things,
but
there
is
a
high
chance
that
this
won't
happen.
Source
editor
might
not
be
used
for
viewing
the
files,
even
though
this
option
is
still
under
review.
A
It
was
a
lot
of
things
to
say
and
I'm
very
sorry
for
it
to
be
at
some
times,
sometimes
very
technical,
but
that's
why
it's
called
deep
dive
and
now
I
would
be
happy
to
answer
the
the
questions
I'm
stopping
sharing
my
screen
and
hopefully
yes,
my
screen
didn't
crash.
Okay,
so
whoa.
So
many
things
in
the
chat
are
those
questions.
Should
I
go
through
those
or.
E
D
A
In
most
cases,
it
is
because
why
I
called
it
bananas,
because
it
was
a
mix
of
six
classes,
functions,
configurable
classes
and
inline,
but
in
general
the
whole
idea
of
extensions
is
exactly
to
use
the
arrays,
because
sometimes
you
want
to
apply
more
than
one
extension
at
the
same
time
for
two
to
one
instance.
So
that's
that's.
Why
applying
applying
things
using
the
array
applying
several
extensions
is
the
way
to
go.
This
is
this
is
this
is
advised
this
is
advised.
What
is
not
advised
is
mixing
different
types
of
extensions.
A
A
F
A
Absolutely
absolutely
great
great
question
and
you're
absolutely
right
for
that.
Up
until
now,
I
was
the
the
sort
of
the
sole
owner
of
the
source,
editor
development,
and
that's
that's
not
intended
to
be
like
this
forever.
Absolutely
not
I
when
I,
when
I
was
creating
the
source
editor.
I
had
some
like
first
of
all
why
this
this
is
going
like
this.
A
So
far
when
I
was
creating
the
source
editor
like
more
than
one
year
ago,
I
had
a
certain
vision
on
about
how
I
want
things
to
be
done
in
this
editor,
and
that's
that's
how
I
was
implementing
things
following
this.
This
vision
that
I
had
a
year
ago,
but
obviously
like
the
source
header,
has
grew,
grew
like
outgrew,
the
the
one
developer
sort
of
the
one
developer
table,
so
we
have
to
in
order
to
take
the
ownership
of
this
project
for
several
people.
A
We
have
to
make
this
one
of
the
main
directions
of
the
group.
It's
not
so
far.
It's
it's
like
this
sub-direction
on
the
on
our
direction
page.
We
have
main
categories,
and
this
one
is
not
the
main
one
of
the
main
categories
so
saying
that
we
have.
We
will
have
to
have
the
dedicated
people
for
this
category.
A
What
I
would
like
to
see
instead
is
sort
of
a
rotation
where
different
engineers
get
familiar
with
the
with
the
product
get
familiar
with
with
the
architecture
there
and
suggest
different
ideas,
because,
for
example,
saying
that
ownership
like
we
did
delegate
an
ownership
of,
let's
say
toolbar
to
to
let's
say
to
himanshu
and
and
let's
say
paul
this-
this
is
totally
valid
solution.
I
just
don't
don't
know
whether
whether
it
it
will
make
things
when
it
comes
to
to
the
source
editor
to
sharing
the
knowledge
about
source
editor
itself.
A
Later,
we
might
bring
source
header
to
absolutely
to
much
better
quality
level.
So
I'm
all
for
that.
That's
that's
why
I
initiated
this
process
yesterday
with
the
discussing
and
openly
talking
about
flaws
of
the
architecture
of
existing
architecture
and
inviting
everybody
to
to
talk
about
this
and
discuss
yeah.
So.
F
F
I
can
dedicate
twenty
percent
of
my
time
to
the
source,
eight
or
and
then
eighty
percent
of
my
time
today
to
the
continent.
I
I
think
that
it
won't
affect
our
ability
to
to
to
achieve
our
goals
like
meaningfully,
for
example,
this
medicine,
I'm
dedicating
time
to
other
projects
outside
of
the
of
the
continent
or
like
implementing
like
some
mystery
book
improvements-
and
you
know-
that's-
that's
20
percent
of
my
time
that
I
could
be
dedicating
to
other
projects
within
the
team.
A
That's
that's
certainly
totally
great
and,
as
I
said,
if,
if
you
could
dedicate
time
for
the
source
editor,
I
would
be
more
than
happy
it's
just.
You
know
we
have
this,
this
guy,
whose
name
is
david?
Who
who
sort
of
sets
the
priorities
and
throws
some
deliverables
at
us?
So
it's
just.
I
think
I
would.
I
would
be
happy
if
you
could
take
a
look
at
the
source
editor
and
come
up
with
different
different
ideas
and
implement
different
parts
of
this
project.
That
would
be
great.
G
H
Those
are
always
helpful,
even
if
we
don't
end
up,
live
coding,
because
it's
just
like
a
collaborative
check-in
at
the
very
least,
and
it's
and
it's
always
it's
always
productive,
even
if
there
was
no
result
at
the
end,
because
at
the
very
least
we
worked
through
a
branch
that
was
like
wait.
This
isn't
gonna
work
out.
Those
are
always
always
good
discussions,
and
I-
but
I
I
know
like
given
the
asynchronous
nature
of
of
gitlab
and
the
the
spread
of
our
our
team
across
the
globe.
Sync
conversations,
and
that
is
hard.
H
That's
why
I
think
yesterday,
when
we
had
this
very
dedicated
focus
on,
let's
just
brainstorm
collaborate
on
what
the
editor
extensions
architecture
could
look
like.
That
was
really
that
was
really
productive,
and
that
was
a
good.
That
was
a
good
session
and
I
think
enrique
had
to
have
a
good
eyes
to
how
we're
going
to
follow
this
up
and
finding
both
synchronous
and
asynchronous
collaboration
methods.
I
think,
are
going
to
be
critical.
The
the
best
asynchronous
collaboration
I've
seen
on
this
was
from
when
enrique
and
hamachi
were
working
on
the
content.
H
Editor
extension
on
the
content,
editor
architecture,
and
just
there
was,
I
don't
even
know
if
there
was
code
yet,
but
it
was
it
was
in
a
form
where
it
was
clear
to
see
the
path
we
were
heading
and
but
it
was
also
easy
to
change.
If
there
were
some
things
that
you
know,
requirements
that
weren't
seen
or
something
like
that.
I
think
I
think,
as
as
much
of
a
bad
rap
uml
gets
doing.
G
A
E
A
H
So
I
was
thinking
about
the
discussion
about
unusing
extensions
and
it's
it's
interesting
to
hear
that
tip
tap
doesn't
support
this.
I'm
not
super
surprised
about
it,
but
I
also
am
a
little
surprised,
the.
But
now
when
I'm
thinking
about
the
alternative
for
source
editor
and
some
of
the
use
cases
that
could
come
up
where
we
would
need
to,
you
know
on
basically
unuse
an
extension,
I'm
feeling
like
it's
possible
that
disposing
the
source.
Editor
is
very
different
than
any
use
case.
H
We'd
run
into
tip
tap
like
because
imagining
disposing
an
instance
is
tied
to
the
ui.
So
if
I'm
like
just
doing
a
file,
rename
that's
gonna,
what
I
can
see
it
happening
is,
if
I'm
doing
a
file
rename.
Therefore,
I
need
to
you
know,
turn
off,
or
you
know,
unuse
some
markdown
extensions,
or
something
like
that.
If
my,
if
my
response
is
to
dispose
the
whole
instance,
you
know
that'll
cause
at
the
very
least
some
flickering
effects
and
might
be
a
little
beefy.
A
Is
this
is
a
very
brilliant
point,
paul
so
obviously
disposing?
The
whole
instance
would
create
some
visual
flickering
because,
like
the
instance
is
tightly
coupled
as
you
as
you
mentioned,
is
tightly
gapped
to
the
to
the
ui.
However,
this
is
a
good
thing
about
the
rational
approach
that
I've
showed,
like
the
we
always
have
access
to
the
original
instance.
A
So
technically,
when
we,
when
we
say
about
dispose
in
this
particular
case
when
we
want
to
unuse
the
things
and
the
way
we
do,
this
is
ditching
all
the
existing
extensions
and
applying
the
new
ones.
We
will
preserve
the
original
instance,
so
the
original
instance
is
there.
We
can't
preserve
it.
What
we
do
is
we
ditch
all
the
extensions
and
apply
new
extensions,
but
the
instance
itself
that
is
connected
to
the
ui
element
will
stay
there
and
therefore
there
will
be
no
flickering
whatsoever.
H
Yeah
yeah
and
that-
and
that
makes
sense
yeah.
So
my
main
question
was
I
don't.
I
don't
think
I
think
we
will
still
need
to
pursue
this
unusing
of
extensions.
I
think
that
could
that
could
make
for
some
really
simple
extensions
that
don't
have
to
have
this
god-like
knowledge
of.
When
do
I
need
to
be
enabled
or
disabled,
and
I
think
that's
a
good
thing,
I
think
maybe
tip
taps
extensions
just
because
tip
tap
is
so
focused
on
on
one.
H
It
is
not
as
robust
as
markdown
has
a
very
different
problem
set
about
like
serializing
and
deserializing.
I
think
that
that
might
just
because
that's
not
gonna
be
a
normal
requirement.
I
think
that's
why
tiptop
doesn't
have
extensions
that
you
can't
disable,
but
I
don't
I'm
not
entirely
sure
about
that,
but
I
I
think
it's
likely
source
editor
will
still
need
to,
and
I
think
we
have
some
some
methods
for
doing
that.
F
Scored
highlighting
the
cross
meter,
the
underlying
library,
the
title
users
can
register
plugins,
I'm
going
to
place
the
the
documentation
link
in
there.
I
think
that
it's
just
a
matter
of
implementing
that
support
for
calling
that
underlying
api
into
that.
I
think
that
we
could
even
think
about
pushing
an.
H
F
What
they
documentation
says
right
now,
I'm
throwing
this
like
for
first
time.
Well,
not
the
first
time,
but
it
says
that
it
is
like
creating
a
new
address
state
where
it's
just
like
readjusting
the
active
plugins.
So
I
guess
that
is
just
like
saying:
hey,
I'm
gonna
take
those
plugins
and
remove
it
from
there
from
the
new
state,
but
it's
a
device
at
a
state
that
is
derived
from
the
previous
one.
I
H
And
I'm,
and
if
I'm
thinking
of
monaco
and
I'm
thinking
of
like
vs
code
and
other
ides,
you
have
extensions,
you
can
install
some
of
them
require
restart,
but
some
of
them
don't
and
like
that's,
really
interesting.
That
hints
at
some
of
their
architecture
of
of,
and
I
think
the
problem
set
and
I
think
we're
going
to
likely
want
to
do
something
something
similar.
And
you
know
looking
at
competitors
like
the
github's
online
vs
code
and
the
pod.
H
F
F
A
The
problem,
the
problem
of
monaco,
is
that
monaco's
extension
api
is
it
is
it
nearly
doesn't
exist,
so
monaco
doesn't
provide
any
like
any
tools
for
for
extensions
like
the
way
we
would
like
to
so.
That's
that's
why
source
editor
in
this
particular
case
source
editor,
takes
this
responsibility
and
implements
the
mechanism
of
working
with
the
extensions,
and
this
is
so
far
from
what
I
understand.
This
is
by
design
in
monaco,
so
monica
doesn't
want
to
hasn't
been
created
with
any
echo
system
in
mind.
A
G
A
oh
sorry,
I'm
just
going
to
say.
I
still
think
that
that's
even
more
reason
to
look
at
vs
code
and
see
okay,
how
does
it
manage
its
extension
architecture
right?
Because
it's
still
using
monaco
under
the
covers?
It's
a
very
similar
scenario
to
what
we
have
and
it's
like?
Okay,
what
is
their
architecture?
Because
it's
obviously
very
robust.
You
can
register
and
register
things
and
it's
a
allows.
A
lot
of
extensibility
there's.
A
There's
one
one
one
thing
to
keep
in
mind
when,
when
comparing
the
desktop
editor
with
the
online
editor
like
for
the
online
editor
technically,
it
would
be
very
expensive
for
us
to
to
sort
of
to
even
have
an
overview
of
all
the
available
extensions
to
the
user.
I
mean
like
when
you
open
the
vs
code.
Vs
code
knows
from
the
file
system
that
it
has
that
or
another
extension
that
you
can
install
uninstall
do
different
things.
We
don't
have
this
privilege
in
the
online
editor.
A
A
This
will
directly
affect
the
architecture
of
the
solution
and
the
fact
that
monaco
doesn't
nearly
doesn't
provide
the
extension
api
and
but
the
vs
code
has
has
it
very
robust
means
that
they
just
built
the
thing
from
scratch?
And
that's
that's
what
pretty
much
anybody
building
a
solution
on
monaco
has
to
go
through,
so
it's
just
like
we
have
it
on
one
hand,
this
is
not
convenient.
On
the
other
hand,
we
can
build
the
things
the
way
we
want
and
need
them
to
be,
because
we
are
building
from
scratch.
H
Yeah-
and
I
think
that's
I
think,
that's
going
to
be
the
key
thing
to
collaborate
on
at
the
beginning
is
greenfield.
How
do
we
expect
clients
to
use
source
editor
and
extensions?
And
I-
and
I
think
that's
that's
personally-
how
I
helps
me
make
make
you
know
the
constraints
decisions
is,
is
thinking
how
do
I
want
this
to
be
used
and
then
we're
gonna
work
on
on
making
that
interface,
and
so
I
think
one
of
the
big
things
from
yesterday
was
was
rather
than
exposing
the
monaco
instance
to
clients.
H
Just
I
really
like
using
the
idea
of
a
view
component
that
just
gives
you
this
flow
of
state
constraints.
Of
just
saying
give
me
the
give
me
source
editor
and
here's
the
extensions
and
just
submit
to
me
when
I
get
value
changes,
and
I
think,
having
that
constrained
interface,
for
how
we
want
this
to
be
used
to
be,
will
be
critical
and
will
help
shape
how
we
expect
extensions
and
other
things
to
work,
because
we
are
doing
a
little
bit
of
green
field.
H
We're
not
these
aren't
monaco
extensions,
because
monaco's
responsibility
is
just
editing
code.
These
extensions
have
to
do
with
live,
markdown,
previewing
and
a
whole
bunch
of
other
editing
experience
stuff.
So
it
is.
The
extensions
is
solving
a
different
responsibility
than
just
monaco
and
that's
it's
challenge
and
it's
cool.
F
F
If,
if
that's
the
case
since
the
associator,
like
the
person,
we're
following,
is
a
framework
agnostic
approach,
can
we
use
gitlab
ui
components
in
this
ui
because
you
know
by
just
like
using
the
api
components,
we
are
getting
inheriting
support
for
dark
mode
and
a
lot
of
accessibility
work.
That
is
very
important.
A
But
to
answer
your
question
directly,
we
will
be
able
to
use
gitlab
ui
components,
even
though
the
source
header
is
framework
agnostic.
Do
you
remember
that
demo
that
I
built
when
we
put
the
content
editor
in
its
very
very
early
days
and
the
content
letter
is
view
based
right?
So
we
put
this
in
the
source.
Editor
extension,
that's
going
to
be
exactly
the
same
approach.
A
We
will
we'll
approach
it
here,
so
we
will
just
put
the
view
components
in
a
source
in
source,
editor
extension
and
and
be
done
with
that
that
at
least
like
I
I
make
it
sound
very
easy.
It's
not
going
to
be
a
walk
in
the
park,
but
that's
that's
totally
possible
and
we've
seen
this
previously.
That
making
view
work
within
the
source.
Editor
extension
is
totally
possible.
C
So
that's
my
main
takeaway
and
it's
really
nice
to
get
familiar
with
the
underlying
context
of
why
the
source
editor
has
been
built.
The
way
it's
been
built.
That,
for
me,
is
a
really
valuable
piece
of
knowledge
and
something
now
I
can
kind
of
use
to
move
forward.
So
I
mean
I
think
this
has
been
super
helpful.
I've
really
enjoyed
it.
I've
got
some
good
information.
C
A
Restricting
that-
and
I've
explained
it
yesterday
a
bit,
but
it's
it's
worth
to
to
to
repeat
that,
since
not
everybody
was
there.
So
the
original
idea
was
that-
and
it
is
still
like
this
so
source
editor
is
the
only
the
the
source.
Editor
core
is
the
only
piece
of
software
that
editor
as
a
group
has
to
be
responsible
for
we
are.
A
We
should
not
be
in
like
involved
in
the
development
of
extensions
extensions,
so
this
is
by
architecture
of
the
editor.
Extensions
are
should
be
responsibility
of
any
particular
group
implementing
that
or
another
functionality
with
source
editor,
for
example,
as
I've
mentioned
previously
pipeline
authoring,
creating
the
ci
extension
for
their
implementation
of
the
of
the
source
editor.
A
They
create
it,
they
own
it.
They
maintain
it.
This
way,
we
we,
as
a
group,
avoid
being
constantly
poked
for
new
feature
requests
for
new
additions
for
fixes.
This
saves
us
a
lot
of
time
and
frustration
and
technically
removes
us
from
this
bottleneck
process
like
we
won't
be
a
bottleneck
in
this.
That's
why,
by
architecture
of
this
editor,
we
said.
Okay,
the
source
editor
core
is
as
slim
as
possible.
It
is
just
a
thin
wrap
around
monaco.
A
However,
we
provide
full
potential
full
access
to
monaco
api
to
the
clients,
implementing
that
or
particular
instance
of
the
source
editor
through
the
extensions,
so
that
extensions
are
extensions.
Technically
are
not
extending
monaco
api;
they
extend
the
source,
editor
instance
api,
so,
but,
but
they
also,
the
the
source.
Editor
core
creates
this
bridge
between
the
between
monaco
and
an
extension
for
the
end
users
to
implement
functionality.
A
We
will
be
poped
for
the
new
features
for
the
new
extensions
and
that's
definitely
something
that
we
as
a
group,
I
believe,
have
have
to
desperately
try
to
avoid
first
of
all
for
our
own
mental
health,
but
also
for
the
sake
of
the
processes
for
other
groups.
So
anything
we
can
create
can
do
to
not
create
bottlenecks.
A
Whether
for
other
groups
is
a
good
thing
I'll,
also
allowing
users
to
to
get
to
monocoat
api
documentation
and
like
we're
not
getting
to
how
bad
that
recommendation
is,
but
that
documentation
exists
so
by
allowing
users
to
get
to
the
monica
api
documentation
and
be
sure
that
whatever
they
read
there
will
still
be
true
in
the
extension
they
are.
Writing.
I
think
this
is
a
very
good
and
positive
thing
for
especially
for
us
as
a
group
to
not
stay
in
the
way
of
other
groups.
Implementations.
B
I
think
that's
a
really
important
point
and
I
wanted
to
highlight
two
things:
one
that
that's
part
of
our
strategy
for
the
content
editor
as
well.
Hopefully
you
know
we're
building
the
foundation
and
others
can
start
extending
it
to
support
other
languages.
Community
contributions
can
be
introduced
to
extend
the
functionality
and
I
think,
that's
excellent-
to
have
the
same
strategy
on
both
sides.
The
the
other
example
I'd
like
to
follow
is
something
I
saw.
The
geo
group
do
in
collaborating
on
a
self-serve
or
working
on
a
self-serve
framework,
and
then
my
understanding
is.
B
They
worked
really
closely
with
fran
on
getting
the
snippets
data
incorporated
in
that,
and
then
they
turned
around
and
asked
us
hey.
Could
you
dog
food
our
framework
and
try
and
just
self-serve
group
wiki
data,
and
it
worked
out
great,
and
I
think
it
was
a
great
story
for
them
to
tell,
but
it's
a
it's.
It
was
the
same
approach
like
if
they
just
had
to
do
it
for
everybody.
B
They
would
never
do
anything
else.
So
I
wonder
if,
when
we're
ready,
we
can
identify.
Maybe
one
group
that
is
interested
in
having
an
extension
work
really
closely
with
them
and
use
it
as
a
case
study
to
help
build
out
our
framework
and
then
promote
it
more
widely
and
say:
hey.
You
know
you
want
code
quality
reports
to
show
up
in
web
ide
like
go
ahead.
This
is
how
you
do
it
and
then
yeah
our
backlog
gets
a
little
less
linear.
A
Well,
this
is
this
is
like
providing
some
guidelines
to
the
groups
how
to
how
to
write
the
extensions
and
implementation.
This
is
definitely
will
be
solved
with
with
the
documentation,
and
I
think
we
already
have
some
documentation
on
the
extensions,
but
so
far
all
of
the
implementations
of
source
editor.
I
was
involved
in
pretty
much
all
of
them,
helping
and
guiding
the
groups
to
to
the
to
to
achieve
what
they
what
they
need.
So
technically
we
have
spread
the
knowledge
to
other
groups
as
well
and
other
groups.
A
A
Maybe
we
could
think
about
whether
it
could
make
sense
to
wrap
it
into
an
extension
and
if
it
would,
we
might
if
the
request
comes
from
another
group,
for
example,
we
could
tell
okay,
but
let
us
guide
you
and
help
you
build
this
extension
with
the
functionality
that
you
want.
Maybe
maybe
like
looking
at
this
feature
list
that
we
have
for
web
id
and
single
file
letter
through
this
prism
of
whether
it
can
be
an
extension,
could
could
help
us
to
identify
these
areas
of
potential
collaboration
with
other
groups.
That
would
be
really.
H
H
If,
if
we
give
people
wanting
to
build
extensions,
all
that
they
want
without
any
constraints
we're
going
to
be
adding
more
work
to
ourselves,
because
building
extensions
isn't
going
to
be
clear,
there's
a
huge
difference
with
how
currently
you
can
build
source
center
extensions-
it's
it
is
complex
and
tightly
coupled
to
monaco,
and
if
you
look
at
building
tiptap
extensions,
there's
a
clear
interface,
I
can
copy
paste.
Other
extensions
all
look
somewhere
and
I
think,
even
though
the
goal
may
be
to
there's,
there's
a
side
effect
goal
of.
We
want
building
extensions.
H
We
don't
want
to
be
responsible
for
all
of
that.
I
think
that's
good
and
it
places
special
emphasis
on.
We
want
to
provide
a
clear
api
for
how
to
build
extensions,
not
just
assigning
them.
But
what
can
extensions
do
if
they
can
do
everything?
Then
it's
really
hard
to
make
them
do
anything,
and
I
think
I
think,
there's
still
a
lot
of
work
to
be
done
on
what
is
the
actual
responsibility
of
an
extension
but
yeah.
A
It
was
just
I
just
wanted
to
while
paul
was
here.
I
was
willing
to
note
this,
but
definitely
writing
source
editor
extension
is
not
complex,
like
it
depends
on
the
use
case,
but
that's
that's
the
beauty
of
the
extensions
for
source
editor.
It's
the
end.
User
decides
how
complex
the
extension
should
be
and
what
functionality
they
want
if
they
want
all
functionality
in
the
world.
That's
this
is
the
beauty
of
not
evolving
us
into
building
that
functionality.
A
C
It's
pretty
straightforward
and
I
think
that
that's
that's
a
great
place
to
aim
for
where
we're
empowering
the
rest
of
git
lab
to
be
able
to
do
that,
and
I
like
that,
that's
the
general
direction
that
everybody
seems
to
be
aligned
on
between
source
editor
and
then
even
the
content
editor
in
comparison,
we're
not
acting
as
a
bottleneck,
we're
empowering
other
people
throughout
the
orc
which
look.
This
is
more
power
to
us,
I'm
happy
about
it.
I
think
it's
a
great
direction
to
be
going
on.