►
From YouTube: Editor Lite: Deep Dive #2
Description
The second Deep Dive on Editor Lite from Create:Editor group at GitLab
A
A
Hello,
so
we
are
here
for
this
second
deep
dive
into
edit
light,
we'll
see
how
deep
this
dive
will
be,
but
we
definitely
aim
for
some
some
deep
anyway,
so
the
agenda
for
today's
meeting,
so
so
that
you
could
could
fill
out
the
questions.
If
you
have
any
it's
going
to
be
our
regular
editor's
agenda,
editor
group
meetings
agenda
document,
I
put
the
links
to
slides
and
video
from
the
very
first
deep
dive
into
that
document
and
I'm
gonna
share
the
document
in
chat.
I.
A
We
are
going
to
talk
like
briefly
to
cover,
because
enrique
has
enrique
was
the
very
first
deep
dive,
I'm
not
sure
about
paul
and
chad
and
roman.
Wasn't
there
either?
So
I
will
make
sure
that
we
cover
some
some
some
very
basics
there
now
as
well,
just
to
you
know,
logically
evaluate
it
into
or
evolving
into
what
eddie
light
is
now.
So,
let's
start
there,
I
put
questions
only
after
the
introduction
but
feel
free
to
write
questions
anywhere
in
that
section
for
the
meeting.
A
So,
let's,
let's
start
so
how
the
editor
light
came
to
life
in
general.
All
the
way
from
the
beginning
of
this
group,
the
editor
group,
I
believe
it
was
the
end
of
2008
2019,
all
the
way.
From
that
moment,
we
were
talking
about
unifying
the
editing
experience
across
the
product,
because
we
had
at
that
moment
we
had
two
editors.
A
We
had
ace
editor
for
editing
the
single
file
instances,
single
file,
editing
and
it
across
the
documentation
is
still
called
a
single
file
editor
and
we
have
web
id
right
so
web
id
was
this
full
ide
experience
and
and
no
roman.
This
was
not
january
2020,
because
I'm
talking
about
very
beginning
of
how
the
editor
light
actually
came
like
came
to
to
this
idea,
so
we
were
talking
about
unifying
the
experience.
A
The
editing
experience
in
this
more
or
less
lightweight
ace
and
full
size,
web
ide
editors
and
the
path
we're
talking
about
was
to
move
the
web
ide
into
all
of
these
instances
of
the
editing
experience
and
by
now,
apparently,
you
didn't
know
how
heavy
the
web
id
is
and
what
a
pleasure
it
would
be
to
move
web
id
to
all
of
those
editing
instances
it
was.
It
would
be
very
challenging.
Hence
we
sort
of
we
were
discussing
this,
but
it
was.
A
We
discussed
the
situation
with
him
and
we
we
came
to
some
like
roman
just
through
this
idea
of
like
why
not
to
to
approach
this
from
the
other
side,
stop
the
spoilers
roman
yeah.
So
we
were
thinking
about
how
to
like
whether
we
have
other
options
instead
of
moving
this
really
happy
application.
That
is
really
monolithic,
one,
the
web
id
into
all
of
the
editing
instances.
How
is
there
any
other
way
to
unify
the
editing
experience
and
we
thought?
A
Okay,
what
if
we
start
small
and
actually
flip
this
problem
and
go
from
the
smallest
possible
footprint
all
the
way
to
what
to
to
web
id
and
unify
this,
like
the
editing
experience
this
way?
So
this
that
idea
really
really
was
interesting,
and
I
went
on
and
built
it
for
the
very
first
proof
of
concept
based
on
monaco
as
the
main
engine
for
the
web
ide,
and
that
was
technically
the
beginning
of
the
of
the
editor
light.
So
really
simple,
pro
proof
of
concept
where
we
wanted
to.
A
In
the
beginning
the
web
of
the
idea,
the
light
had
to
have
just
one
purpose
to
replace
a
so.
It
had
to
be
very
bare
bone,
very,
like
lightweight,
wrapper
around
monaco
monoco
editor,
because
we
have
monaco
in
web
id
as
well
and
then
in
the
future
it
would
make
the
transition
or
unification
of
the
editing
experience
much
simpler
for
for
the
whole
product.
A
So
we
started
taking
baby
steps
towards
this,
and
but
several
miles
thousand
months
forward
in,
I
believe
in
september
or
yeah,
it
was
the
end
of
september.
I
think
we
finally
got
rid
of
ace
in
the
code
base
or
no,
it
was
october.
Actually,
we
got
rid
of
ace
and
we
replaced
all
the
instances
of
ace
with
edited
light.
A
A
C
A
Yes,
yes,
so
technically,
when
we
were
implementing
web
ie,
ace
was
already
in
the
code
base,
but
it
was
much
sort
of
we.
We
always
wanted
this
sort
of
paramount
idea
of
building
the
second
vs
code
right.
So
what
is
the
sort
of
idealistic,
editing,
environment,
it's
vs
code
that
is
familiar
to
most
of
the
developers
and
it's
it
makes
a
lot
of
sense
to
to
provide
similar
editing
experience
in
the
browser
similar
to
what
users
have
on
their
desktops.
A
So
that's
that's
how
we
came
to
this
situation
when
we
had
to
replace
ace
with
monaco,
and
now
we
are
talking
about
using
the
same
thing
in
web
id
so
like
circular
dependency,
but
eventually
we
are
going
to
get
out
of
this.
I
believe
so.
The
editor
light
architecture-
this
is
this
is
a
very
interesting
point.
So,
from
the
very
beginning,
editor
light
has
been
intended
to
be
a
very,
very
lightweight,
wrap
around
monaco.
A
A
The
task
of
editor
light
to
be
as
a
little
intrusive
into
the
process
of
communicating
between
extensions
and
monaco
as
possible
by
providing
convenient
api,
convenient
bridges
between
monaco
and
extensions,
editor,
light
itself,
eddie
light
core
is
framework
agnostic,
so
that
it
would
be
possible
to
use
it
in
gitlab
product
in
all
the
instances
of
our
views
not
only
view
based,
so
it's
possible
to
use
it
in
view,
it's
possible
to
use
it
in
hammer
views,
it
will
be
possible
if
at
some
point
we
decide
to
ditch
view
and
go
to
react.
God
forbid.
A
We
are
going
to
be
to
be
fine
there
as
well,
so
edit.
The
light
will
just
keep.
Keep
working,
yeah
react,
so
that's
that
is
sort
of
in
the
dna
of
editor
light.
It
has
to
be
a
framework
agnostic
for
it
to
be
universal
enough.
Also,
we
have
more
than
just
gitlab
product.
We
have
different
projects
and
it
should
be
possible
to
use
editor
like
in
those
projects
as
well.
A
A
A
A
A
Properties
for
that
particular
instance
like
what?
What
kind
of
properties
can
it
be
like?
We
have
blobs
for
different
extensions.
For
example,
we
have,
we
have
blob
for
markdown
file
and
javascript
file.
In
this
particular
case,
we
might
want
to
provide
different
different
settings,
for
example,
for
javascript
file.
A
So
all
of
the
options
that
you
can
find
if
you
can
find
those
in
the
documentation
for
monaco
and
that's
really
challenging,
but
if
you
can
find
those
options,
all
of
them
will
work
both
for
the
global
editor
object
and
for
each
particular
instance,
editor
light
doesn't
add
anything
on
top
of
that.
We
have
all
those
bare
bear
options
here
so
again,
getting
back
to
the
extensions
extension,
extends
the
properties
of
a
particular
instance,
not
the
global
editor
but
particular
instance.
A
Their
editor
light
still
provides
the
abstraction
to
extend
all
of
the
instances
of
this
glow
of
the
global
editor.
So
we
can
say
we
can
create
global
editor,
object
same
and
then
say
editor,
dot
use
and
then
the
list
of
the
extensions
to
use
those
extensions
will
be
applied
to
all
of
the
instances
of
this
global
editor.
A
But
we
can
also
do
call
use
method
on
on
the
particular
instance,
and
then
only
that
particular
instance
will
get
the
extensions
that
we
are
about
to
apply.
So
we
came
to
the
core
thing
dot
use.
This
is
the
construction
that
we
will
be
using
most
often
when
we
deal
with
extensions
this.
It
follows
the
the
paradigm
introduced
in
view
where
to
to
use
a
plugin
for
view.
You,
you
type
view
dot,
use
and
then
the
plugins.
You
want
to
use
the
same
thing
here.
A
Now
there
is
the
merge
request
that
is
assigned
to
energy
canal
as
maintainer,
but
we
are
very
close.
I
hope
we
are
very
close
to
the
situation
when
extensions
can
be
defined
in
more
than
one
way.
So,
as
I
said,
extensions
in
general
are
simple
objects.
So,
technically,
let
me
just
share
my
screen
to
to
show
you
how
this.
B
A
Right
so
here
is
the
spec.
That
explains
what
can
extend
an
instance,
so
we
can
use
es6
classes.
We
can
use
multiples,
es6
classes
passed
as
an
array.
We
can
use
simple
object.
That
is
just
the
inline
object,
you
can
say
instance
dot
use,
and
then
you
pass
raw
javascript
object
with
methods
to
extend
the
instance.
You
don't
need
a
separate
extension
file
to
do
that.
If
you
are
talking,
we
are
talking
about
just
one
one-off
use
case
of
this
extension.
A
Let's
say
I'm
again
getting
back
to
this
multifile
snippets
example
right,
so
we
have
several
several
instances.
For
example,
we
have
five
blobs
right,
all
of
them
for
different
file
file
extensions,
and
there
is
just
one
one
instance,
for
example,
for
the
yaml
for
the
yaml
file
right,
so
the
blob
representing
yaml
file-
and
we
want
to
to
say
okay
for
this
particular
instance
of
the
yaml
file
we
want.
We
want
this
instance
to
provide
some
functionality
like
when
I
click
somewhere
in
the
field.
A
It
will
pop
up
and
alert
to
me
or
something
like
this.
We
don't
want
this
to
be
used
by
any
other
instance
on
this
page,
and
we
know
that
this
is
not
going
to
be
used
by
any
other
instance
anywhere
in
the
product.
So
it's
just
one
off
thing,
for
example
to
like
to
notify
user
about
something
we
can
say.
A
Okay,
when
we
change
the
file
name,
for
example,
in
this
instance,
we
want
to
notify
user
that
we
are
reapplying
the
intellisense
and
syntax
highlighting-
and
this
is
for
for
one
particular
instance-
it's
not
going
to
be
reused
anywhere
else.
It's
not
to
say
that
this
is
the
preferred
way
of
extending
instances.
It's
just
there
for
very
simple
use
cases
in
reality,
most
like
99
of
the
extensions
will
obviously
be
stored
in
the
separate
files,
and
those
files
will
be
either
plain:
javascript
objects
or
es6
classes.
A
A
This
is
the
valid
extension
for
the
instance
of
edit
light,
so
out
of
the
box
instance
of
the
editorial
light
won't
have
the
method
for,
but
we
want
it
to
provide
this
method
for
some
reason
for
some
particular
file
extension
or
for
some
particular
scenario
where,
where
this
might
be
useful
right
so
in
for
for
this
math
to
be
available
to
the
instance,
we
can
say
like
I'm,
not
talking
about
how
we
got
to
the
instance
thing,
but
we
say
instance
use.
Then
we
say:
okay.
A
This
is
it
now,
after
this
instance,
foo
oops,
who
will
return
for
res.
That
is
just
the
string.
I
believe.
Oh
no,
it's
just
just
this
sort
of
mock
thing
and
yeah.
So
this
is
the
simplest,
the
simplest
way
in
reality.
Obviously
you
will.
You
will
have
several
several
methods
that
probably
work
together
and
the
best
example
of
how
this
is
this
is
implemented
will
probably
be.
Let
me
just
get
to
know
a
little
light
and
mark
down
extension,
so.
A
This
is
the
markdown
extension
as
it
is
in
master
now,
so
it's
just
the
default.
The
javascript
object,
where
we
have
several
methods
to
work
with
markdown
files
whenever
we
initialize
the
instance
of
the
editor
light
to
work
with
markdown
file,
it's
probably
probably
smart
to
include
this
mark
this
extension
into
and
use
it
in
editor
line,
because
it
provides
some
handy.
A
Handy
editing
capabilities
when
one
clicks,
for
example,
on
the
toolbar
clicks
to
edit
to
add
the
bolded
text
or
underscore
text
or
like
italicized
text.
So
all
of
this
handled
this
thing
and
initially
this
extension
has
been
implemented
following
the
api
of
ace,
so
that
editor
light
could
be
plug
and
play
solution
for
the
instances
where
ace
was
used
for
markdown
files.
A
So
these
files
might
be
not
very
descriptive,
even
though
they
are
to
some
certain
extent,
but
they
follow
the
api
provided
by
ace
previously
nowadays
or
not
nowadays,
but
with
the
merge
request
in
progress
now
in
in
review
at
the
maintainer
level,
we
switch
to
defining
extensions
as
es6
classes
in
addition
to
the
to
the
standard
javascript
objects.
So
these
two
can
be
used
properly
together,
side
by
side,
but
there
are
some
cases
when
we
want
to
set
up
editor
light
from
our
extension
and
in
this,
in
this
case
we
want
to.
A
Yes,
we
want
to
send
some
configuration
options
to
our
extension
and
in
this
case
achieving
this
with
a
simple
javascript
object
is
nearly
impossible
because
it
won't
work
as
sort
of
setting
up
the
extension.
It
will
work
as
just
method
on
the
instance,
and
we
do
don't
want
to
expose
all
our
configuration
options
to
on
on
the
instance
to
be
publicly
available,
so
we
want
to
set
up
our
extension
before
it
gets
applied
before
it
gets
used
by
the
editor.
So
because
of
this,
we
are
starting
supporting
the
es6
classes.
A
A
E
A
The
problem
is
that
at
this
moment
our
constructor
knows
nothing
about
instance,
so
we
use
our
extension
only
later
in
the
process
we
say
instance,
dot,
use
and
then
our
extension,
but
at
that
moment
our
extension
already
has
to
be
configured
so
constructor
and
the
actual
methods
are
called
with
different.
This
keyword.
A
So
to
speak,
when
you
call
when
you
initialize,
the
extension
as
you
set
is
six
class.
This
points
to
the
extension
module
itself
when
you
call
a
method
later
in
the
process,
for
example
replace
selected
text
later
on.
This
will
point
to
the
instance
on
which
you're
running
this
extension,
so
there
is
the
lack
of
this
synchronization,
so
we
have
two
options.
First
or
like
not
two
options
we
still
have.
If
you
want
to
store
our
our
configuration
options,
we
have
to
pass
instance
to
our
constructor.
A
So
how
is
it
how
it's
done
well
in
this
particular
case,
we
don't
send
anything
because
we
don't
need
any
configuration
options,
but
this
is
how
how
we
deal
with
es6
classes.
So
in
this
particular
case
we
get
it
a
dynamically
import
imported
dynamically.
Then
we
say
this
editor.
This
is
actually
the
instance
we
say
use
and
then
new
markdown
extension.
This
will
apply
this
markdown
extension.
A
In
this
particular
case
again,
we
do
not
need
any
configuration
options,
so
we
can
emit
both
instance
and
options.
We
just
initialize
the
extension,
but
if
we
would
be
about
setting
up
this
extension,
we
would
have
to
send
instance
and
pointing
to
this
editor
and
then
we
would
send
the
object
with
options
or,
like
I
don't
know,
like
full
bar.
If
we
want
to
use
this
as
the
configuration
option,
all
right-
I'm
sorry
we
can.
A
A
This
base
base
extension
is
sort
of
a
helper
so
that
we
could
in
real
extensions.
We
could
extend
it,
but
nobody
prevents
you
from
doing
from
not
extending
that
that
thing
and
doing
just
your
oops.
That's
not
gonna
work
from
doing
your
own
constructive
thing.
No
problem
here,
just
keep
in
mind
that,
in
order
to
store
the
configuration
options,
you
have
to
pass
the
instance.
A
The
problem
with
these
configuration
options
now
is
that
if
you
take
a
look
at
this
code,
this
line
at
the
moment
we
oops,
we
follow
the
same
principle
as
with
extensions.
We
extend
the
instance
itself
with
the
configuration
options.
This
means
that
we
are
polluting
the
global
instance
scope.
This
is
bad.
A
F
C
C
A
The
motivation
is
pretty
simple:
we
need
to
keep
the
core
of
the
editor
live
as
simple
as
possible
and
to
to
prevent
actually
to
reduce
the
clashes
of
name
of
names.
Definitely
so
answering
I
will
start
from
from
the
beginning.
So
what
happens
if,
let's
say
instance,
has
the
same
math
name
the
method
name
exactly
the
same
as
our
instance
or
if
two
extensions
get
applied
and
both
of
them
have
method
with
exactly
the
same
name
right.
A
A
So
that's
that's,
obviously
not
ideal
solution,
but
this
is
by
far
the
simplest
one.
Now
when
we
have
very
limited
number
of
extensions
and
all
of
the
extensions
are
very
well
controlled,
so
we
know
what
names
the
methods
in
our
extensions
have.
The
reason
behind
this
was
very
simple.
We
needed
this
to
be
fast,
simple
and
reliable.
A
It's
not
reliable
in
terms
of
like
naming
conflicts,
but
again,
as
I
said,
there
is
the
there
is
an
mr
in
the
pipeline.
That
is
like
work
in
progress
for
me
now
to
create
the
registry
for
for
the
extensions,
so
technically,
I'm
still
playing
with
the
idea
of
arc
how
to
architect
this
registry
of
the
extensions.
But
obviously
it
will
deal
with
the
things
that
with
reinstantiating
an
extension.
A
A
So
we
we
have
to
get
rid
of
the
markdown
extensions
so
that
they
don't
stand
in
the
way.
But
then
you
change
your
change,
your
decision
again
and
switch
it
back
to
markdown.
We
don't
want
to
re-download
the
extension
and
reapply
it.
We
want
it
to
be
available
to
us
right
now.
So
that's
where
that's,
where
we
get
reach
out
to
the
registry
on
the
global
editor
and
pull
in
the
already
existing
and
already
pre-configured
markdown
extension.
A
This
is
even
more
important
for
multi-file
solutions
where
we
have
several
instances
of
the
editor
on
the
same
page,
for
example
multifile
snippets,
where
we
store
we
have
different.
Let's
say
we
start
with
one
file
a
markdown
file
right
and
that
we
pull
in
the
markdown
extensions
and
we
put
them
into
the
registry
in
the
global
register
of
our
editor.
Then
we
click
add
new
file
and
we
create
another
markdown
file,
so
it
only
makes
sense
to
reach
out
to
the
registry
and
without
redownloading
the
extension
or
redoing
any
other
configuration.
A
We
just
pull
in
the
existing
markdown
extension
with
pre-configured
options
and
apply
to
this
newly
created
blob.
So
so
it
helps
us
to
to
be
very
performant
with
this
editor
and,
at
the
same
time,
save
resources
by
not
like
by
reducing
the
round
trips
in
this
work
of
creating
this
registry.
For
the
extensions,
I
will
keep
in
mind
how
we
might
solve
this
name
in
conflict
situation.
A
A
Investment
at
the
moment
because,
as
I
said,
we
have
very
limited
number
of
extensions
and
all
of
them
are
very
well
controlled
and
if
you
technically
it's
very,
very
early
discoverable
very
early
in
the
process,
if
you
try
to
call
some
method
on
the
on
the
instance
and
it
does
something
completely
random
that
you
don't
expect,
you
just
see
that
okay,
I
did
something
wrong
with
my
naming
for
for
the
methods.
Apparently,
so
that's
that's
something
I
will
be
probably.
A
I
will
probably
put
some
warnings
so
throw
some
warnings
to
say
like
okay,
we
have
naming
conflict
but
don't
think
we
have
to
go
further
than
that.
You
know
just
answer
the
question.
Yes,
thank
you
dennis
cool.
Thank
you!
So
yes-
and
you
have
so
it
was
the
question
from
paul
and
then
yeah.
You've
you've
asked
your
question
as
well
right.
A
So
again,
the
my
main
idea
behind
the
edited
light
is
that
the
edited
light
core
itself
has
to
be
as
simple
as
lightweight
as
possible,
and
all
the
heavy
lifting
has
to
happen
in
the
extensions,
because
extensions
have
all
the
context
of
the
instance,
so
they
have
access
to
instance.
They
have
access
to
all
the
all
the
other
extensions.
So
it's
like
the
ecosystem.
There
is
pretty
well
defined.
A
D
Edited
one
question
yeah,
so
I'm
curious
like
what
is
your
general
vision
yourself
for
the
accent
extensions
going
forward,
like
you
mentioned
a
few
like
with
the
markdown
one
or
so,
or
kind
of
the
yaml
linting,
let's
say
right:
what
is
your
vision
for
saying?
Okay,
how
can
I
or
we
as
a
team?
How
can
we
help
like
drive
this
forward
in
general
to
say:
okay,
like
how
should
we
think
about
extensions,
and
how
should
we
kind
of
like
think
about
it
that
we
want
to
drive
the
adoption
within
gitlab?
D
A
A
This
is
the
main
benefit
of
using
editor
lite,
as
it
is
now
and
using
the
using
this
architecture
as
the
basis,
so
that
heavy
lifting
is
done
in
the
extension.
So
any
group,
absolutely
any
group,
can
write
an
extension
for
edited
light,
because
this
is,
as
I
said,
just
a
plain:
javascript
object.
You
just
think
about
it
as
something
that
gives
you
the
editor
with
this
keyword.
If
you
want
to
do
something
with
the
editor,
it's
with
the
instance
of
this
editor,
you
just
use
this
keyword.
A
Otherwise
it's
all
just
a
plain
javascript
object,
so
any
group
can
write
any
extension
for
themselves
and
we
are
at
the
moment
at
least
one
other
group
is
writing.
Their
own
extension
pipeline
authoring
has
their
own
extension
to
validate
the
gitlab
yaml
file
in
editing
light,
and
they
are
going
to
maintain
it.
They
they
are
going
to
own
this
extension.
A
Should
we
need
a
similar
extension.
We
can
either
extend
that
extension
right,
our
own
extension
or
just
use
that
extension
for
our
needs
as
well,
so
there
are
different
opportunities
and
but
absolutely
no,
we
should
not
write
all
of
the
extensions
ourselves
now.
The
very
very
important
question
is:
how
do
we
increase
the
traction
or
like
not
actually
do
the
country?
How
do
we
increase
the
adoption
of
the
edited
light
in
the
product?
This
is
a
very
good
question.
A
I
believe
that
we
should
find
some
some
balance
where
we
replace.
We
still
have
plenty
of
fields
where
editing
experience
is
delivered
with
just
text
areas.
I'm
not
talking
about
the
discussions
or
notes.
We
know
how
that
story
goes
now
in
the
group
right,
but
there
are
other
places
other
instances
in
the
product
where
we're
talking
about
really
editing
of
something,
but
only
the
text
area
is
used
for
for
the
purpose
there.
A
So
we
could
extend
those
places
over
time
when
we
go
with
edited
light
to
and
start
implementing
it
as
the
basis
for
web
id,
we
will
be.
We
will
inevitably
build
some
other
extensions
anyway
and
those
will
be
owned
by
us
and
those
can
be
reused
by
other
groups.
At
the
moment
I
have.
Let
me
just
check
this.
A
I
have
the
proof
of
concepts
again
when
we
were
discussing
things
with
with
the
pipeline
authoring
group.
They
reached
out
to
me
to
give
their
to
give
the
perspective
on
whether
they
should
go
with
web
id
or
edit
the
light,
and
obviously
I
was
I
did
my
best
to
be
as
neutral
as
possible,
but
for
their
particular
use
case.
Eddie
light
made
much
more
sense
so,
and
I
I
built
some
some
prototypes
so
technically
I
have
the
proof
of
concept
with
live
preview
for
markdown.
A
I
think
you
have
you
already
seen
that
that
should
be
wrapped
into
proper,
proper
extension.
We
have,
let
me
check
so.
Yes,
we
have
the
inline
editing
like
this.
The
inline
editing
will
be
probably
the
place
that
brings
editor
light
to
as
many
places
in
the
product
as
possible.
So
if
we
are
able
to
to
to
come
up
with
an
interface
where,
where
we
can
inline
edit
using
the
editor
light-
and
this
is
totally
possible-
I
showed
this
with
snippets-
then
the
adoption
will
be
will
be
much
better.
A
I
have
the
proof
of
concept
where
we
have
the
div
editor
for
editor
light
where,
for
example,
you
type
in
something
and
you
get
the
diff
building
up
right
there
for
your
document,
so
you're
writing
the
things
you're
changing
your
heading,
you're
removing
and
then
you
have
the
deep
right
here.
This
is.
This
is
one
more
thing
that
that
was
important
for
pipeline
authoring
team.
A
This
is
very
convenient
and
the
cool
thing
is
that,
since
we
are
using
the
using
monaco
under
the
hood,
we
can
create
the
div
editor
in
read
mode.
So
like
right
now
it
is
even
editable,
so
you
you
can
edit
and
you
have
all
these
changes
visible
right
where
you
are
editing,
but
we
can
split
it
into
the
separate
panel
where
we
that
that
we
show
in
read-only
mode-
and
we
show
all
the
like
the
full
div.
For
example,
it
might
be
convenient
when
you're
dealing
with
several
files
and
before
you
commit.
A
We
show
this
right
as
we
do
in
web
id,
but
it
might
be
useful
for
the
single
file
editing
experience
as
well.
If
you
are
do
making
a
lot
of
changes
in
one
file
having
the
div
right
here
might
be
very
useful
anyway,
tabbed
multi-files
view,
I
have
the
poc
proof
for
that.
So
when
we
create
something
that
looks
kind
of
similar
to
web
id
with
several
tabs,
but
we
have
one
global
editor
object
and
every
top
represents
one
instance
of
this
global
object.
A
C
No
no
worries,
I
have
a
question
the
same.
You
know
in
the
same
theme
of
of
the
future
about
on
and
how
I
turn
light
will
evolve
in
relation
to
the
to
the
web
id.
So
what
probably
you
see
ate
or
like
playing
the
web
id
like
right
now,
it
represents
the
the
source
editor
right,
like
the
the
core
component,
where
the
the
user
edits
a
source
file.
So
how
do
you
see
that
evolving,
like
will?
Will
it
provide
more
features
than
that?
How
do
you
see
that
drawing.
A
Again,
I
don't
see
editor
light
core
growing
on
features
at
least
not
extensively
like
it
will
stay
core
to
the
like
to
the
very,
very
basic
wrapper
around
monaco,
all
the
functionality,
all
the
heavy
lifting
will
happen
in
extensions,
so
we
can
create
extension.
That
does
a
lot
of
heavy
lifting
thing
and
then
add
one
more
extension
on
top
of
that
to
do
to
provide
some
some
other
functionality,
but
I
don't
envision
anything
like
to
grow
at
a
little
light
itself
to
grow
significantly
the
core.
A
Then,
technically
we
take
the
functionality
that
is
missing
after
this
move
right.
We
do
it
in
the
same
iteration.
Obviously,
but
we
start
with
introducing
the
little
light.
Now
we
take
the
functionality
that
that
is
not
there,
but
was
the
the
the
the
difficulty
with
web
id
is
that
tons
of
functionality
has
been
implemented
as
part
of
the
core
editor
in
web
id,
and
now
the
challenge
is
to
take
it
out,
wrap
it
into
the
into
an
extension
and
saying
like
this
is
web
id
extension
and
ideally
split
it
even
further.
A
So
technically
in
my
idea,
the
core,
like
the
editing
of
the
file,
is
going
to
be
the
edit
to
light
core
right,
like
with
extensions
based
on
the
file
file.
Extension
then
tabs
are
each
tab
represents
one
instance
of
the
edited
line.
On
top
of
this
we
have
global
editor
object.
Then
we
have
the
panel
on
the
left
side.
A
A
It
extends
the
the
paradigm
of
widgets
in
monaco,
so
monaco
comes
bundled
with
two
types
of
widgets:
the
content,
widget
and
overlay
widget.
The
content
widget
is
the
widget
that
is
shown
as
on
top
of
your
content,
so
you
specify
the
line
number
and
the
column
number
where
you
show
some
some
information,
for
example
like
validation
of
some
syntax,
so
you
can
pop
pop
up
a
content
widget.
So
when
you
scroll
the
content,
widget
will
be
com
tightly
coupled
with
the
place
you
you
initialize
it.
A
There
is
the
paradigm
of
the
overlay
widget,
it's
something
that,
for
example,
when
you
use
vs
code
with
mini
map,
minimap
represents
something
that
is
it's
technically,
not
an
overlay
widget,
but
it
represents
the
same
paradigm.
So
it's
something
absolutely
positioned
within
the
editor
within
your
editor.
So,
like
I
don't
know
again
some
some
information
about,
like
some
validation
of
your
document,
again
like
how
many
like
failures,
how
many
problems
or
warnings
something
like
this.
When
you
scroll
the
overlay,
widget
stays
intact,
stays
on
the
same
place.
A
B
A
Right
so
the
panel
widget
is
something
that
creates
the
panel
outside
of
your
editor
editor
frame.
It
can
be
placed
on
top
of
the
editor
on
sides
or
below
the
editor,
and
you
can
technically
put
technically
add
any
right.
We
we
lost
on
weekend,
but
okay,
we're
still
recording.
So
I
will.
I
will
keep
going
so.
The
panel
widget
paradigm
creates
a
panel
that
is
still
tightly
coupled
with
the
with
the
editor.
A
It
knows
about
anything
happening
in
the
editor,
but
it
is
outside
of
your
editing
context,
kind
of
so
using
the
paradigm
of
panel
widget.
We
can
build
and
getting
back
to
the
web
id
story
using
the
paradigm
of
the
panel
widget.
We
can
build
the
navigation
tree
on
the
side
of
the
of
the
editor.
We
can
build
the
side
panel
as
the
panel
widget.
A
We
can
do
different
things
like
this
with
extensions.
So,
for
example,
the
panel
the
side
panel
with
navigation
tree
is
going
to
be
the
the
panel
widget
that
comes
from
its
own
extension.
Then
side
panel
on
the
right
is
going
to
come
from
its
own
extension
and
we
completely
decouple
the
editor
from
those
things.
Yet
it's
going
to
be
the
editor
that
orchestrates
all
of
those
pieces
and
all
of
those
pieces
through
the
editor
will
be
familiar
and
we
will
know
about
context
of
all
other
pieces.
A
B
A
Is
a
this
is
a
very,
very
good
question
chad,
so
eddie
to
light
this
is
we
have
only
two
minutes?
I
will
try
to
make
it
so
edit.
The
light
itself
is
very
is
totally
framework
agnostic
right,
but
that's
sad,
nothing
prevents
you
from
building
your
extensions
in
any
framework
you
want.
Do
you
want
to
pull
and
react
feel
free?
Do
you
want
to
pull
in
view
feel
free?
You
build
your
extension
with
view
now
you
when
you
want
to
create
two
extensions
that
share
the
same
store.
E
A
We
there
is
the
there
are
some
callbacks
or
like
events
that
monaco
emits.
Obviously
when,
for
example,
the
content
is
changed
or
the
focus
got
obtained
by
the
editor,
so
any
extension
can
listen
to
those
events
and
provide
some
processing
based
on
that
information.
So,
when
editor
updates
the
the
content,
all
of
the
extensions
can
listen
to
this
event
and
do
their
their
own
work.
They
can
put
things
in
the
store
they
can
do
do
anything.
A
This
is
the
event
yeah.
This
is
the
beauty.
Thank
you,
roman.
So
this
is
the
beauty
where
you
technically
outside
of
like
once
you
get
to
the
extensions
level.
You
are
free
to
build
it
anyhow,
you
want
eddie
to
like
doesn't
care
about
this.
What
editor,
like
does
is
provides
the
breach
for
your
extension
to
monaco
and
from
monaco
to
your
extension.
A
So
it's
up
to
you
to
decide
how
you
want
to
to
to
sort
of
exploit
that
information
right,
so
you
can
build
one
mata
extension
that
dispatches
things
to
other
extensions
or
something
like
this
and
editor
editor
light
won't
object
that
architecture
at
all.
So
it's
very
non-opinionated
thing.
This
is
the
beauty.
It's
not
opinionated,
editing
experience
where,
where,
as
I
said,
all
the
power
and
all
the
responsibility
should
we
say
that
is
on
the
extensions
and
the
authors
of
of
the
extensions,
so
how
we
approach
that
architecturally.
A
That's
another
thing
like
how
we
want
to
build
those
extensions,
how
we
want
to
orchestrate
those.
This
is
going
to
be
another
thing,
but
we
take
small
steps
because,
as
I
said,
if
we
build
extensions
for
different
components,
combining
them
or
splitting
them
will
be
will
be
very
trivial
because
they
are
sort
of
like
like
lego
blocks.
A
A
Using
this,
we
will
be
able
to
provide
the
multi-file
editing
experience
there,
where
we
say
okay,
for
this
instance
of
the
editor
light.
Please
pull
in
this
file
tree
extension
and
it
will
provide
you
with
the
list
of
the
files
and
you
will
be
able
to
click
a
file
open,
a
tab
and
edit
another
file
within
the
repository,
but
we
can
provide
this
gradually
sort
of.
We
do
not
pull
in
the
whole
monstrous
web
ide
to
the
user.
A
User
starts
easy
starts
simple,
for
example,
the
ideal
path
is
user,
creates
a
new
file
in
the
repository
right.
Now
they
get
the
bare
minimum.
Just
plain
edited
light,
no
extensions
applied
whatsoever
because
we
don't
have
any
extension
yet
user
types
in
the
name
of
the
file
and
puts
the
extension.
We
know
that,
for
that
extension,
we
need
to
pull
in
data
and
that
extension
we
do
that.
Then
user
does
some
other
action.
A
We
pull
in
another
extensions
to
to
extend
this
editing
experience
and
that's
how
and
then
the
user,
for
example,
clicks
the
tab
like
show
nav
tree
in
the
toolbar.
That's
where
we
pull
in
this
extension
for
the
for
the
navigation
tree
and
we
just
we
are
going
to
be
able
to
build
extensible
user
experience
for
editing,
and
this
is
super
cool.
In
my
opinion,
this
is
the
most
powerful
part
of
this
editor.
A
E
Here
I
think
it's
good
and
to
bring
up
my
favorite
point.
I
think,
like
that's
another
example
of
metadata
state
that
if
we
ever
want
to
save
and
and
restore
sessions,
that
would
be
an
example
like
what
extensions
am
I
using
for
editing
this
particular
file?
Okay?
Well,
maybe
we
renamed
or
deprecated
one
of
them,
but
then,
when
they.
E
A
Yeah
but
again
like
before,
before
getting
to
the
point
of
like
storing
the
and
like
reacting
to
the
changes
in
schema,
we
really
need
to
iron,
like
some
simple
parts,
because
that
one
will
be
really
challenging
how
we,
how
we
implement
that
part.
It's
like
it's
gonna,
take
the
whole
milestone
of
just
discussions,
I
guess
but
and
prototyping,
but
if
we
have
all
the
simple
and
basic
parts
in
place
for
that
to
happen
properly,
then
then
I
don't
see
any
any
reason
not
to
deal
with
that
part.