►
From YouTube: Source Editor introduction and AMA
Description
High-level introduction to the Source Editor category for the Source Code group.
A
A
A
No
cool?
Okay.
Now
let
me
just
share
my
beautiful
screen,
which
is
going
to
be
let's
just
try,
sharing
the
I'm
actually
not
sure
whether
it
will
show
so.
Okay.
Do
you
see
my
slides
now
very
well?
Okay,
cool,
oh
I,
so
like
talking
about
Source
editor,
so
you
have
to
stop
me
at
some
point.
So
Source
editor
after
the
recent
reorganization,
The
Source
editor
category
is
moved
out
of
the
editor
group
and
to
source
code.
A
My
congratulations.
You
also
got
me
with
this
category,
which
yeah
it's
just
bonus.
The
category
is
itself
is
pretty
straightforward,
so
oops,
what
is
Source
editor?
Let's
talk
about.
What
is
this
Source
editor
is
the
editor
and
under
the
hood,
the
core
of
the
source
editor
is,
is
the
Monaco
editor.
This
is
editor
built
on
top
of
editor.
A
Monaco
is
the
same
editor
which
Powers
not
only
source
editor
but
also
vs
code,
the
application
that
a
lot
of
you
are
using
on
your
desktops
and
the
same
vs
code.
That
is
which
is
powering
the
new
web
ID
gitlab.
Now
the
point
of
source
editor
is
to
be
a
very
thin
layer
on
top
of
Monaco
The
Source
editor
core
should
be
stable
at
any
time.
A
That's
why
we
architecturally
it's
not
overloaded,
it's
as
close
to
the
core
of
Monaco
as
possible,
so
that
at
any
point
of
time
an
engineer
could
get
to
a
Monaco,
API
documentation
and
figure
out
how
the
source
editor
works,
because
it's
technically
all
of
the
Monaco
API
is
supposed
to
work
in
Source
editor.
So
at
any
point
of
time,
we
try
to
make
sure
that
the
core
of
the
source
header
is
staying
stable.
A
All
the
power
of
source
editor
comes
from
the
extensions.
The
extensions
are
sort
of
the
separate
pieces
of
software
which,
as
the
name
implies,
extend
the
functionality
of
source.
Editor
extensions
are
what
brings
new
functionality
to
Source
editor
and
every
instance
of
source
header
can
support
any
number
of
extensions.
A
Any
extension
can
bring
any
functionality
and
we
will
dive
deep
into
how
the
extensions
work,
how
all
the
bits
are
glued
together
in
the
engineering
Deep
dive.
But
now
it's
enough
to
say
that
the
source
header
core
is
very
thin.
It
should
be
very
stable
at
any
time
and
all
the
functionality
all
the
power
of
source
editor
comes
from
the
extensions
that
are
extending
this.
This
Source
core.
A
A
What
source
header
is
not
so.
This
is
a
very
important
thing
to
understand.
Source
editor
is
not
an
IDE.
This
is
a
clear
distinction
which
has
to
be
has
to
be
made.
It
is
not
the
web
ID.
The
architectural
decisions
behind
behind
Source
header
are
contrary
to
web
ID
to
to
IDE.
So
IDE
is
have
everything
solution,
so
you
open,
ID
and
you
get
access
to
all
of
the
Power
of
IDE.
A
Source
editor
by
Design
is
as
lightweight
as
possible,
so
it
is
very
lightweight,
but
it
can
be
as
close
to
your
real
ID
as
user
might
need,
and
we
will
talk
about
gradual
complexity
a
bit
further
in
in
today's
session
and
the
engineering
Deep
dive.
A
source
editor
introduces
this
Paradigm
of
gradual
complexity,
where
the
editor
might
become
more
complex
and
complex,
provide
more
functionality
on
user
request.
A
So
it's
user
driven
experience
instead
of
IDE,
which
provides
all
of
the
functionality
right
away
at
the
user
and
user
has
to
decide
what
to
do
there
so
who's
using
Source
header.
This
is,
of
course,
Legacy
web
ID.
This
is
this
used
to
be
the
the
main
user
of
source
header,
but
Legacy
webrt
is
on
its
on
its
way
to
to
die.
A
What
general
pipeline
editor
structure
so
pipeline
editor
has
a
source
header
in
three
different
parts
of
the
overall
pipeline.
Editor
security
policy,
editor
in
yaml
mode,
is
using
the
source
editor
as
well
and
who
would
have
guessed
Snippets,
which
are
already
part
of
source
code
and
web
editor
or
single
file
editor
as
some
call
it,
but
I
prefer
the
web
editor,
because
this
is
the
name
that
we
have
in
the
documentation
about
this
page
and
in
general.
I.
Think
web
editor
gives
us
a
bit
more
freedom.
A
A
So
if
we
talk
about
the
groups,
who's
using
Source
header
source
code,
editor,
Pipeline,
authoring
and
security,
so
all
of
these
are
users
of
source
header
at
the
moment.
So,
with
Source
editor,
moving
to
source
code
source
code
extends
the
influence
on
the
product
in
general
and
has
more
more
influence
on
the
overall
product,
because
several
other
groups
depend
on
this
in
the
context
of
source
code.
The
parts
that
we
own
from
those
use
cases
that
I
mentioned
are
Snippets
and
web
editor.
A
What
are
the
challenges
and
some
notes
about
Source
editor,
but
we
have
to
be
aware
of
so.
First
of
all,
as
I
said,
four
is
very
lightweight,
so
core
is
virtually
Mankind's
free,
the
core
of
source
header
I,
think
the
last
commit
that
has
been
made
into
the
source.
Editor
core
was
about
one
and
a
half
years
ago.
A
It
is
very
lightweight
and
shoot,
as
I
mentioned
should
be,
should
be
error
free
at
any
time.
So
that's
why
it
is
very
lightweight
and
it
is
maintenance
free
at
the
moment,
the
main
challenge
when
it
comes
to
Source
header
comes
from
upgrading
dependencies
as
trivial
as
it
might
sound.
We
have
three
different
dependencies
which
power
source
editor,
Monaco,
editor,
Monaco,
editor,
webpack,
plugin
and
Monaco
yaml.
A
The
the
tricky
part
with
this
is
that
each
of
this
depends
on
a
particular
version
of
one
of
the
two
remaining
and
those
versions
at
some
point
start
conflicting
each
with
each
other
and
editor.
We
had,
we
had
an.
We
have
had
an
issue
to
upgrade
Monaco
to
the
latest
version,
but
that
attempt
technically
failed
because,
with
the
with
pulling
all
the
latest
versions
of
these
three
packages
led
to
the
problem
in
the
pipeline,
where
building
production
assets
in
nearly
doubled
the
time
for
the
job.
A
A
There
is
the
issue
somewhere.
I
will
find
the
link
and
provide
some
more
details
for
the
for
the
engineering
Deep
dive.
So
this
is
the
main
challenge
not
coming
from
Source
header
itself,
but
from
upgrading
the
dependencies
and
the
question
is:
do
we
need
to
upgrade
to
the
latest
dependencies?
Yes,
in
particular,
Monaco
editor
it
with
we
are
quite
lagging
behind,
and
the
new
versions
brought
a
lot
of
new
improvements
related
to
Performance
related
to
Mobile
support,
so
things
that
would
be
great
to
have
in
the
product
of
course.
A
So
what
is
the
current
state
of
the
source?
Editor?
First
of
all,
there
are
three
points
of
additional
functionality
for
the
for
the
source:
header,
the
contextual
menu.
This
menu
comes
from
it.
This
is
the
native
menu
coming
from
Monaco.
We
have
the
tools
to
add
new
functionality,
new
entries
to
this
contextual
menu.
This
is
one
way
to
add
functionality,
common
with
the
keystroke
keyboard
shortcut.
This
is
again
standard.
A
Monaco
thing
you,
the
users
of
vs
code,
might
say
that
this
looks
familiar
because
this
as
I
said,
comes
from
Monaco
and
Monaco
Powers
vs
code
as
well.
So
these
things
might
look
familiar
and
then
the
third
point
of
the
functionality
where
we
can
add
functionality
is
the
toolbar
on
this
screenshot
you'll
see
the
the
toolbar
about
the
editing
interface,
so
the
first
two
points:
contextual
menu
on
common
short
keyboard
shortcuts
come
from
Monaco.
The
toolbar
is
the
thing
coming
from
Source
editor.
A
Only
this
molecule
does
not
have
does
not
provide
any
toolbar.
So
toolbar
is
purely
Source.
Editor
thing,
which
is
again
as
I
said.
All
the
functionality
comes
from
extensions,
so
even
the
toolbar
itself
is
the
extension,
because
we
have
use
cases
where
toolbar
is
not
needed.
So,
like
the
pipeline
editor,
for
example,
there
is
no
need
in
the
toolbar,
so
we
want
the
source
header
to
be
lightweight
and
where
it
is
needed,
we
do
add
the
toolbar.
We
do
add
new
functionality.
A
A
A
This
is
behind
the
feature
flag
and
hence
we
still
have
to
roll
out
the
feature
flag.
In
order
this
Toolbar
to
be
available,
there
are
still
two
two
merge
requests
that
need
to
be
merged
before
this
toolbar
is
anyhow
useful
for
the
users
on
on
the
broader
scale,
but
the
the
conclusion
is,
the
work
related
to
the
toolbar
has
to
be
finished.
Before
we
can.
We
can
say
that
we
we
introduce
new
functionality
through
this
through
this
toolbar
and,
of
course
the
biggest
thing
is
updating
the
documentation.
A
The
vision,
so
what
is
coming
with
Source
editor
The
Source
there
was.
There
were
a
lot
of
discussions
about
future
of
source
editor
when
it
was
part
of
the
editor
group.
There
were
a
lot
of
efforts
for
different
functionality
introduced
for
for
the
source,
editor
and
all
of
those
discussions
that
were
not
implemented
yet
tours
are
coming,
along
with
the
source
header
for
the
for
the
source
code
group
to
consider,
and
in
the
first
place
for
Torsen
to
to
think
about
whether
we
are
interested
in
doing
those
or
not.
A
Unfortunately,
I
didn't
have
enough
time
to
put
all
the
things
on
the
slides,
but
if
you
I
have
put
everything
in
the
in
the
notes
on
the
in
the
agenda
and
I
will
just
go
through
those
points
to
to
mention
some
that
which
might
be
interesting
to
to
know,
and
some
of
those
will
have
links
to
pocs.
Most
of
them
have
different
pocs.
Some
of
them
have
video
recordings
of
how
things
are
supposed
to
work,
just
for
broader
understanding
of
how
things
work.
A
So
in
the
vision.
The
first
point
is
it:
the
editor
is
Lightweight
by
Design.
This
is
this.
Has
this
is
like
this
now
and
it
has
to
stay
in
my
opinion
for
the
future,
so
when
we
say
that
we
put
new
features
into
the
source
editor,
this
should
mean
we
put.
We
create
new
extensions
or
we
put
new
functionality
into
the
existing
extensions.
We
do
not
overload
Source
header
core
itself.
Everything
comes
from
the
extensions
it
comes
with
performance
in
mind.
A
Sense,
Source
header
is
based
off
Monaco
editor
The
Monaco
code
base
is
let's,
let's
be
honest,
it's
monstrous
it's
a
very
big
and
or
some
period
of
time.
It
was
the
main
abuser
of
the
loading
performance
for
the
pages
where
Source
editor
has
been
used,
but
we
are
past
that
time.
Source
editor
now
is
using
performance
techniques
to
pre-fetch
Monica
early
on,
so
that
the
source
header
is
very
like
it.
At
least
it
feels
to
the
users
as
very
fast
and
lightweight
editor.
A
Moreover,
now
that
source
code
owns
everything
within
the
repository,
so,
for
example,
for
the
web
editor,
we
have
many
more
possibilities
to
improve
performance,
even
more
for
loading
for
interaction
with
the
editor.
So,
whenever
we
work
with
Source
header
performance
always
comes
comes
first
in
whatever
is
related
to
The
Source
editor,
The,
Source,
editor
based
off
Monaco
is
not
the
the
most
lightweight
when
it
comes
to
Performance,
unfortunately,
but
there
are
a
lot
of
things
we
can
improve.
A
So
this
is
these
are
the
general
points,
but
what
are
the
exact
things
where
the
source
header
can
be
used
in
the
context
of
source
code
group,
for
example?
And
we
had
a
coffee
chat
with
eager
yesterday,
and
he
said
maybe
maybe
it's
the
the
code
owners
is
is
a
good
example
of
this,
and
then
I
was
looking
around
and
I
found
this.
It's
linked
here,
the
wonderful,
a
wonderful
issue
that
explicitly
says
code
earners,
editor
and
validation
tool
based
off
pipeline
editor.
A
This
is
this
is
wonderful
example
where
Source
editor
can
be,
can
be
very
helpful
because
we
can
provide
custom,
schema,
validation
right
in
context,
while
you're
editing,
we
can
provide
syntax
highlighting
we
can.
We
can
write
the
custom,
syntax
highlighter
specifically
for
the
code
owners
file
based
on
the
rules
that
we
Define.
A
This
is
one
thing
another
one
in
context,
editing
experience.
We
talked
about
this.
Excuse
me
briefly
with
the
torson
and
some
other
Engineers.
There
is
the
POC
for
Snippets,
which
is
pretty
old
but
still
relevant,
and
it
also
contains
the
the
video
of
how
how
this
can
be
done.
The
idea
is
you
look
at
the
snippet
or
you
look
at
the
blob.
A
You
click
the
button
to
edit
and
instead
of
loading
the
new
page,
the
viewer
gets
converted
into
the
editor
right
there
in
context,
so
you
get
a
much
smoother
much
more
responsive
user
experience
this
again,
at
least
within
the
responsibility
of
the
source
code
group
for
Snippets
and
for
the
for
the
blobs.
This
would
be
a
great
performance,
Improvement
and
user
experience,
Improvement,
of
course,
as
well.
If
you're
interested
the
video
is
here,
the
POC
I
think
it's
yeah.
It's
here
well
actually
yeah
this
and
this.
A
The
fact
that
Michael
is
working
with
source
code
makes
me
happy
because
a
lot
of
the
pocs
you
will
see
in
this
list
a
lot
of
the
ideas.
A
lot
of
the
Visions
have
been
discussed
with
Michael
prior
to
to
this
to
to
me
coming
to
source
code
and
Michael
was
the
driving
force
for
a
lot
of
those
ideas.
So
that's
that's
great
to
to
consolidate
those
ideas
again.
A
So
in
context,
editing
is
actually
one
of
those
solution,
validation
and
who
is
the
author
Michael?
So
we
get
to
the
next
thing.
There
is
the
general
epic
for
the
in-context
editing
that
we
created
back
in
the
in
the
editor
Group,
which
will
be
moved
to
source
code
as
well,
so
tight
integration
of
Snippets
into
single
file
editor
another
idea
so
and
this
this
is
the
year
that
I
expressed
a
couple
of
times
already
so
up
until
now.
A
Snippets
are
something
that
sits
in
the
product,
because
competitors
do
have
similar
concept,
but
we
do
not
use
it
the
full
power
of
Snippets
really
so
they
are
there.
They
are
in
maintenance
mode,
but
you
do
not
use
those.
So
there
is
the
POC
of
adding
the
Snippets
into
the
into
the
workflow,
so
this
POC
suggests
using
Snippets
as
as
the
source
for
shared
content.
A
Like
templates
code
Snippets,
you
name
it
where
you,
while
you're
editing
a
document
you
can
using
the
contextual
menu,
for
example,
or
a
keystroke
command
or
the
toolbar.
What
any
of
those
three
entry
points
for
the
functionality
you
can
say:
insert
snippet
the
PO,
the
the
pop-up
shows
up
where
you
can
browse
to
the
snippet
you
want
you
want.
A
You
can
even
drill
down
to
a
particular
blob
in
that
snippet
and
click
Bank
blob
and
the
content
of
The
Blob
gets
injected
into
your
into
your
editing,
edited
document
right
there
great
way
for
shared
code,
Snippets
or
templates
as
a
side
note
as
a
as
another
idea.
This
is
for
putting
Snippets
into
the
code,
and
but
we
can
do
exactly
the
same
thing
where
you
you
work
with
a
document
and
then
some
particular
code.
Snippet
would
be
great
for
you
to
save.
A
A
For
example,
we
are
on
the
blob
viewer
or
pretty
much
anywhere
in
the
in
the
project,
probably
even
in
the
merger
Quest
review
when,
when
you're
a
reviewer,
you
see
some
interesting
code
pattern
and
you
want
to
save
it
for
yourself,
this
can
be
done
very
Universal
and
will
allow
us
to
actually
bring
a
lot
of
sense
to
the
Snippets
category
and
bring
it
to
life
and
make
it
an
integral
part
of
the
workflow
again.
Should
we
need
this?
A
A
A
new
file
I
would
like
to
have
context,
even
if
for
just
psychological
reassurance,
that
I'm
in
the
right
place
within
my
repository
I
do
want
to
see
the
file
tree
I,
but
not
only
that
I
want
to
be
able
to
click
the
file
in
the
file
tree
and
edit.
That
file
as
well
get
to
the
multi-file
support
in
a
bit,
but
I.
Don't
in
this
particular
case
when
I
talk
about
file
tree
I,
don't
even
mention
I,
don't
even
necessarily
mean
multi-file
support
right
away.
A
Now,
without
even
touching
or
altering
the
commit
workflow,
it
will
still
be
sort
of
single
one
file
at
a
time
workflow,
but
things
will
be
much
more
Consolidated
and
consistent
and
users
will
get
the
feeling
of
editing
several
files
at
a
time
without
going
to
web
IDE,
which,
in
the
new
version,
becomes
much
more
complex
and
much
more
overwhelming
for
a
regular
user.
Who
is
not
a
developer
with
this?
A
Out
of
the
way-
and
actually
yesterday,
I
was
told
that
the
pipeline
authoring
group
would
be
very
interested
in
this
as
well
in
file
3,
support
and
Source
editor,
because
in
in
gitlab
we
do
not
have
CI
configuration
in
one
file
like
it
is
spread
in
across
several
files
and
having
proper
overview
of
dependencies
and
configurations
put
into
different
files
would
be
beneficial
for
pipeline
authoring
group
as
well,
but
then
we
get
to
the
biology
file
support.
So
if
we
talk
about
the
file
tree,
probably
we
could
talk
about
multi-file
support.
A
This
is
sort
of
a
Shaky
Ground,
because
at
this
point
we
are
we're
approaching
that
moment
where
I
said
that
Source
header
is
not
IDE,
but
this
might
actually
bring
us
to
the
ID
area,
but
only
in
terms
of
Mal
editing,
multiple
files.
At
a
time,
if
we
have
the
file
tree,
we
might
take
a
very
boring
approach
of
of
the
current
Legacy
web
ID,
where
we
have
you
click
the
button.
A
You
click
on
file
name
and
the
new
tab
is
open
in
the
source
header
and
you
just
added
several
files
at
a
time,
then
you
check
the
diff
divs
for
the
for
all
for
the
changes
of
all
the
time,
all
the
files
and
commit
all
of
the
changes,
as
just
one
commit
instead
of
several
commits
for
several
files.
So
this
would
require
a
bit
more
effort,
but
I
believe
that
would
be
a
very
welcome.
A
This
is
multi-file
support,
then
visual
editor
for
markdown
files.
This
is
actually
one
of
the
topics
that
we
got
to
consensus
back
in
the
editor
group,
where
we
discussed
the
consolidation
of
source,
editor
and
content.
Editor
content
editor.
Now
is
under
the
it
has
has
moved
to
plan
stage
now,
but
the
consolidation
still
can
happen
really
well
what
this
means
it
doesn't
mean
smash
together
the
two
editors.
A
But
for
those
who
want
to
add,
for
example,
some
Advanced
smart
markup
into
the
markdown
files,
they
will
still
be
able
to
switch
back
to
the
code
code
version
sort
like
using
the
source.
Editor
write
that
code,
for
example,
inject
some
HTML
snippet,
and
use
this
as
the
as
the
basis
for
the
markdown
file.
So
this
is
about
consolidations
and
consolidation
of
two
editors
and
providing
the
best
possible
user
experience
to
the
end
user.
There
is
the
POC.
A
A
A
So
these
are
like
big
things
that
we
discussed
over
time
in
the
editor
and
which
I
would
like
source
code
to
be
aware
of,
in
terms
of
where
the
editor
might
go.
What
the
editor
might
bring
to
the
group
for
different
for
different
use
cases,
so
this
is
pretty
much
all
I
wanted
to
tell
about
the
introduction
of
the
source
editor
and
now,
let's,
let's
get
to
the
IMA
part,
I
will
stop
sharing
my
screen
and
I
will
start
reading
the
questions.
A
So
the
first
one
I
believe
Sean
asked.
Is
this
the
correct
dementation
link?
Yes,
as
I
mentioned,
the
documentation
link
is
correct.
However,
it
is
very
outdated
and
needs
to
be
updated,
and
this
this
should
be.
This
should
be
done,
or
rather
sooner
than
later,
for
our
own
sake
really
person.
Do
you
want
to
verbalize
I'm
sorry,
Sean,
I
didn't
I,
didn't.
B
B
C
A
Which
is
what
it
does
and
right,
so
let
let
me
start
with
with
some
Theory.
So
up
until
a
couple
of
weeks
ago,
editor
group
was
owning
four
editors:
the
new
web
ID,
which
is
vs
code,
the
Legacy
web
ID,
which
is
source
source,
editor
powered
The
Source
editor,
is
itself
and
content
editor,
so
the
main
editor
for
the
for
the
product
used
to
be
Source
editor,
and
it
remains
as
as
such
the
web
ID.
A
The
the
new
web
ID
is
the
separate
thing
which
now
is
going
to
play
more
into
the
remote
development
world.
Then
we
are
left
with
content.
Editor
content.
Editor
is
the
dedicated
editor
for
editing
markdown
files.
This
is
the
main
purpose
of
the
content
editor.
This
is
the
editor
in
which
Powers
Wiki
and
now
after
it
moved
to
plan
I
believe
the
the
idea
is
that
it
will
power
all
the
content.
All
the
comment,
Fields
descriptions
and
merge
requests
and
issues
so
anywhere
we
write
markdown
will
be
powered
by
content
editor.
A
A
A
A
Is
no
editor?
No,
no.
This
is
not
Source
editor.
This
is
just
the
regular.
This
is
the
conventional
markdown
field,
which
you
can
find
in
comments,
descriptions
and
different
issue
things.
This
is
this.
Is
the
problem
like
this
is
one
more
way
of
editing
things
in
gitlab,
but
it's
kind
of
now
with
content,
quantitative
moving
to
plan,
so
all
of
those
things
are
owned
by
plan
now
so
plan
will
come
up
with
the
a
generalized
idea
of
how
to
to
to
make
things
better.
A
And
that
being
said
at
some
point,
we
discussed
the
idea
of
complete
unification
of
the
things
and
actually
use
Source
editor
for
comments,
descriptions
as
well
with
consolidation
of
content
editor,
so
that
anywhere
you
face
a
markdown.
You
will
be
greeted
with
exactly
the
same
functionality
exactly
the
same
interface.
Should
it
be
comment?
Should
it
be
description
for
the
issue
or
merge
request?
Should
it
be
a
markdown
Blob?
Should
it
be
marked
down
snippet?
A
A
A
Just
from
from
some
code
from
this
is
the
this
is
just
the
view
component
and
the
toolbar
comes
from
from
The
View
component,
but
so
here
here
what
you
can
do
here
is
you
write
proper,
proper
markdown
subtitle,
so
you
write
markdown
code.
This
is
exactly
as
you
would
do
for
the
for
the
sake
of
it.
Let's,
let's
compare
this
field
to
the
source
editor,
so
we
will
just
create
the
new
file
here,
run
it
let's
make
it
even
Define,
so
we
are
gonna.
A
Do
this
so
first
of
all
this
is
this:
is
the
the
the
difference
that
you
can
spot
right
away?
Source
editor
follows
all
the
preferences
for
the
visual
theme.
So
if
the,
if
your
visual
theme
is
not
there,
so
it's
not
Source
editor
in
this
particular
case
I'm
using
solarized
dark,
it's
defined
in
my
preferences,
so
solarized
dark
I
actually
prefer
solarized
light,
but
so,
let's,
let's
switch
to
this
one.
A
This
is
important
thing
to
understand
why
extensions
are
the
core
source
of
functionality,
because,
as
you
can
see,
we
gave
the
MD
extension
to
this
file
now
and
the
toolbar
with
all
which
is
related
to
markdown
appeared
here.
If
we
rename
it,
for
example,
back
to
I,
don't
know
to
txt,
the
toolbar
is
gone
because
all
those
buttons
make
no
sense
and
are
not
relevant
for
for
txt
files.
A
This
is
so
technically
what
happened
under
the
hood.
We
uninstalled
the
markdown
extension
and
users
are
left
with
what
what
is
what
is
left
after
that,
but
in
this
particular
case,
this
is
what
we
do
here.
So
we
can
write
some
code.
We
can
do
some
I.
Don't
know
some
formatting,
for
example
bold
this
one
and
we
can
have
the
live
preview.
A
So
now,
when
I'm,
adding
adding
the
things
here,
I
I
see
those
in
the
live
preview,
so
this
should
have
better
spacing
this
field
on
the
right
is,
as
I
said,
just
the
regular
regular
text
area.
But
if
we
switch
to
the
reach
text,
this
will
convert
be
converted
to
virtually
like,
let's,
let's
make
them
the
same.
A
However,
it's
not
only
the
preview,
it
is
editable,
so
we
can
do
Sub,
Sub
sub
header
here
and
then
this
is
the
way
to
work
with
the
markdown
here.
If
we
switch
back
to
the
to
the
regular
one,
so
our
Sub
sub
header
is
here
and
technically
that's
that's
the
purpose
of
the
markdown.
It
is
the
purpose
of
content
data.
It
is
for
Rich,
Text,
editing
of
the
markdown
files
and
what
I
propose
by
consolidating
sourceader
and
content.
A
Editor
is
technically
instead
of
this
part,
the
text
area
to
have
the
source
editor
with
all
the
power
that
sourceiter
might
bring
to
the
table
and
combine
it
exactly
the
same
way.
It
is
done
here
to
combine
it
with
the
reach
text
editing.
So
when
editing
markdown
file
in
repository,
we
would
be
able
to
visually
edit
the
markdown
file,
which
is
which,
for
some
is
more
convenient.
A
C
A
A
We
go
to
to
snippet,
and
this
is
the
base,
the
most
basic
Source
header.
You
can
see
this.
The
source
editor
in
Snippets
does
not
employ
any
any
extension.
So
even
we
are
working
with
markdown
file
here
there
is
no
markdown
toolbar
here
and
that's
something
that
we
might
want
to
to
change
as
well.
But
this
is
the
the
simplest
version
of
source
editor
foreign.
A
There
is
an
example
of
so
hypothetical
extension,
which
contains
all
the
which
kind
of
like
self-documented
extension,
where
the
users
of
sourceater
can
get
to
figure
out
how
the
extension
is
supposed
to
work
and
things
like
this,
but
we
have
the
extension
for
CI
schema.
This
is
used
by
pipeline
editor.
We
have
the
base
extension.
This
is
the
extension
which
is
installed
for
most
of
the
use
cases
with
Source
editor,
and
it
has
core
things.
Core
functionality
like
remove,
highlights,
highlight
lines
and
toggle
soft
wrap.
A
So
it
extends
it
with
get
item,
get
all
items,
get
items,
remove
items
update
item,
so
different
sort
of
extensions,
bring
extended
API
to
the
to
the
to
the
source
editor
there
is,
and
the
the
interesting
thing
is
that
the
whole
Legacy
web
IDE
is
an
extension
so
because
there
are
a
lot
of
different
functionalities.
All
of
the
things
that
Legacy
web
ID
does
are
coming
in
the
form
of
extension,
and
this
again
like
compare
the,
for
example,
the
the
the
thing
like
the
toolbar
and
the
whole
web
ID.
A
So
all
both
of
these
can
come
in
the
form
of
a
web
of
the
extension,
so
this
shows
the
power
that
can
can
come
with
the
extension.
This
is
this
is
super
cool,
in
my
opinion,
so
coming
back
to
your
question,
toolbar
is
the
extension
and
pretty
much
all
of
the
functionality
is
the
extension.
So,
for
example,
this
live
preview
comes
as
part
of
the
live
preview
extension,
it's
not
even
part
of
the
of
the
markdown
extension.
B
F
B
C
B
A
So
we
have
buttons
on
the
right
here
when
we
switch
to
the
reach
text,
the
buttons
are
on
the
left
so
and
the
buttons
are
quite
different.
So
considering
this
is
the
user-driven
action.
I
think
we
for
the
for
the
beginning.
We
might
accept
this
this
level
of
ux
disturbance,
but
it's
it's
up
to
Michael
to
decide
whether
it's
it's,
okay
or
not.
I
think
it
might
be
be
okay,
but
it's
fundamentally
important
to
understand
that
content.
Editor
is
a
completely
different
editor.
It's
not
even
running
Monaco,
it's
it's!
A
It
has
its
own
architecture,
it
has
its
own
engine,
it
has
its
own
functionality.
Source
header
is
another
thing,
and
what
we,
the
only
thing
we're
talking
about
when
we
talk
about
consolidation,
is
take
two
different
things
and
put
them
on
the
same
page
and
provide
the
mechanism
of
switching
between
the
two
and
they
in
the
POC.
It
is.
It
is
achieved
by
actually
shared
view
component,
which
introduces
Source
error
content
editor
and
manages
the
state
between
the
two,
the
again
the
performance
there
is
so
to.
B
B
A
Toolbar
we
could,
we
could
try.
The
problem
is
that
the
way
since
content
editor
is
operating
with
with
with
HTML
markup
at
the
at
the
end
of
the
day,
so
it
injects
the
HTML
markup
here
which,
using
the
the
tokenizers
and
the
serializer,
is,
gets
converted
to
the
market
mark
down
when
we
switch
back
to
to
this
form.
A
So
they
might
look
the
same,
but
they
won't
behave.
Won't
won't
produce
the
same
result.
So
again
answering
your
question:
it's
it's
going
to
be
very
tricky
to
use
exactly
the
same
toolbar
for
both
editors,
because
they
they
produce
completely
different
results
because
they
expect
different
content.
A
A
A
Another
package
called
Tip
Top.
So
those
all
of
those
are
view
based
things
when
it
comes
to
Source
header.
Source,
editor
core
is
framework
agnostic.
It
can
work
in
the
view
Con
in
View
application,
it
can
be,
it
can
work
in
rails.
Application
can
work
anywhere.
Nevertheless,
we
do
have
the
view
component
for
the
source
editor
for
the
scenarios
where
we
want
to
use
it
in
the
view
context,
so
it's
just
component
is
which
wraps
around
the
framework
agnostic
editor.
A
E
A
This
is
so,
as
I
said,
we
have
to
update
the
documentation,
and
this
this
is
also
true
for
the
for
the
extensions
the
documentation
that
we
have
here
about.
The
extensions
a
lot
of
it
is
is
still
correct.
However,
it's
V
it's
pretty
outdated
because
exactly
after
we,
after
the
source
later
went
through
the
refactoring
of
the
architecture.
A
Thank
you,
okay,
cool
Sean.
If
we,
if
we
have
like
we
are,
we
are
past
the
the
time
I
I
can
continue.
Talking
about
this,
as
I
said
you
have
to
stop
me.
Source
header
is
something
I'm
very
passionate
about,
so
I
can
continue
like
till
Monday.
Probably,
but
do
we
address
the
two
questions
here
or
no
wonder
of
that
I
think
yeah.
A
Yeah
I
can
I
just
need
to
drink
water
from
time
to
time.
Okay,
let's,
let's
get
to
this
two
questions
very
quickly,
so
Sean
Sean
is
not
on
the
call
anymore
right,
so
I
will
verbalize.
What
is
the
connection
between
the
source,
header
and
the
back
end?
Is
the
back
end,
just
a
data
store
or
does
the
source
area
consume,
other
apis?
What
happens
with
plugins?
This
is.
This
is
a
very
good
question.
So
Source
header
is
frame
front-end
heavy.
It
is
front
end
only
so
to
speak.
A
The
only
connection
to
the
back
end
might
happen
in
the
back
ends
in
the
back
end.
So
if,
if
we,
for
example,
talk
about
Snippets
integration,
so
here
we
go
no.
This
is
the
in
context.
If
we
talk
about
the
Snippets
integration
into
the
web
ID
into
the
web
editor
the
what
happens
is
that
we
write
the
extension
to
integrate
the
Snippets
and
then
within
the
extension.
What
we
need
is
we
need
to
to
query
API
to
return
the
Snippets
to
us
right.
A
So
in
this
particular
case
we
used
gracul
and
we
just
get
to
to
the
to
the
endpoints.
We
just
get
all
the
Snippets
available
for
the
current
user
and
that's
what
we
use
so
with
with
the
current
state
of
of
of
the
API
I.
Think
the
support
from
backend
is
minimal
required
for
the
source
editor.
However,
by
implementing
different
features,
we
might
figure
out
that
the
current
API
doesn't
provide
enough
flexibility,
for
that
particular
one
particular
feature,
and
but
that's
that's
like
on
a
case-by-case
basis
in
in
in
general.
A
Editor
I'm,
not
aware
of
such
queries
or
such
demand,
but
this
all
depends
on
what
we,
what
we
formulate
as
Vim
style
web-based
code
editor.
Does
it
mean
theme
as
an
engine
that
would
be
super
tricky
and
also
switching
switching
engine
to
something
dramatically
different
from
Monaco
as
Vim
is,
would
mean
dramatic
change
in
the
user
experience
of
the
editor
and
I.
Don't
think
this
is
something
we
would
like
to
have,
especially
considering
that
other
groups
depend
on
this
editor.
A
A
D
A
Yeah
Monica
beam.
Okay,
this
there.
The
interesting
thing
to
to
keep
in
mind
is
that
since
we
are
using
Monaco,
any
Monaco
plugins
can
be
installed
for
Source
editor.
This
is
important
to
understand:
Monaco
plugins,
Monaco
extensions,
not
vs,
code
extensions,
but
Monaco
extensions.
There
are
very
few
of
those,
but
there
are
some
and
I
I'm,
not
sure
about
this,
probably
the
key
bindings
for
Monica
weather.
We
can
just
try
this.
A
So
if
it's
about
only
about
the
key
bindings
again,
then
this
will
behave
as
just
yet
another
extension
which
technically
brings
brings
the
veeam
style.
I
would
I
would
Envision
this
as
some
as
a
new
preference
for
the
user,
where
user
says
Okay
I
want
theme,
style,
editing
experience
and
then
we
just
for
users.
B
A
B
A
D
D
Slash
slash
is
a
search,
so
you
can
do
like
a
regular
expression
after
this
slash
and
it
will
just
match
the
the
instances.
But
then
we
have
a
bunch
of
commands
that
Empower
you
to
do
quick
edits
using
the
keyboard
you
can
do,
search
and
replace
you
can
do
actual
commands.
That
will
you
know,
oh
save.
If
you
use
a
colon
W
would
write
the
file
which
in
this
case,
doesn't
really
apply.
D
I
guess,
but
does
it
just
enables
a
bunch
of
a
world
of
possibilities
for
you
to
interact
with
the
content
stuff
like
multiline,
edits
stuff,
like
that?
It's
as
long
as
it
supports
Vim
for
people
that
talk
the
language
of
them
is
just
opens
a
different
world
that
wasn't
there
before,
like
I
said
it's
it's
big
and
the
fact
that
they
have
vim
and
emacs.
Essentially,
there's
two
types
of
developers:
yeah
people
they
use
Vim
the
people
who
use
emacs.
A
The
only
the
only
thing
is
to
make
it
a
really
opt-in,
because
for
anybody
like,
if
I
am
the
technical,
writer
and
I
need
to
to
do
some
very
simple
stuff
and
we
would
throw
veeam
at
at
the
technical
writer
it'll
be
much
worse
than
sending
them
to
the
to
the
vs
code
based
web
idea.
In
my
opinion,
so
we
have
to.
We
have
to
make
it
performance,
not
performance,
but
preference
driven
for
those
who
want
to
do
this.
Of.
A
Know
I
think
I
think
I
think
the
very
yeah.
The
very
first
thing
that
that
people
start
learning
on
both
on
veeam
and
emacs
is
how
to
quit
it.
That's
that's.
The
very
first
thing
one
starts
to
to
learn:
I
think
it's
it's
the
most
viewed
stack
Overflow
question:
is
it
how
to
exit
them
yeah
I'm,
pretty
sure
it
makes
sense,
because
that's
like
everybody
wants.
F
A
It's
it's
exactly.
It's
going
to
be
exactly
as
as
here,
for
example,
we
we
are
in
the
markdown
file,
but
if
we,
if
we're
in
a
txt
file,
we
don't
have
any
toolbar,
so
the
toolbar,
technically
it's
not
removed
or
destroyed,
because
at
any
point
of
In
Time
the
user
might
get
it
back.
But
if
we,
for
example,
if
we
load
this
page
at
this
moment,
there
is
no
toolbar
loaded
at
all.
A
So
it
is
performance
again
performance
first
here
so
toolbar
is
not
loaded
here,
it's
loaded
only
when
it's
needed
in
this
particular
case
it's
needed
based
on
the
file
extension,
but
in
case
of
veeam
or
emacs,
it
will
be
based
on
the
user
preference.
So
when
we
load
the
editor,
we
create
the
instance
and
then
we
figure
out.
Okay,
do
we
have
this
preference
on?
If
we
have
we
install
the
extension?
If
we
don't,
then
we
just
don't
load
this
extension.
That's
it.
A
B
C
So
I'm
not
great
at
film,
the
but
I
still
use
it
anyway,
and
the
reason
why
is
that
it's
ridiculously
fast,
so
the
the
editor
itself,
you
can
load
million
line
files
into
it
and
they
just
load
up
and
work
and
any
of
the
like
the
more
visual
based
ones
so
like
the
visual
studio
and
stuff
just
aren't
as
fast
as
that
for
me,
and
I
really
love
how
fast
it
is
to
to
work
through
files.
It
doesn't
matter
how
big
a
file
you
pick
up
so
mine's,
quite
modified.
C
Most
firm
users
do
a
lot
of
modifications
so
like
picking
up
weird
loading
systems
and
stuff
like
that,
but
it's
just
very
quick
and
sort
of
scrolling
through
files.
It
just
that's
why
I
use
it
and
for
the
main
fundamental
of
them.
I
guess
is
that
you
have
different
modes
so
by
default
here
in
a
in
like
a
navigation
mode.
So
if
I
started
typing
now
it
would
just
start
doing
random
stuff
to
the
file,
because
every
single
letter
is
some
sort
of
shortcut.
C
So,
for
example,
if
I
press
V,
it
starts
putting
it
into
visual
mode,
and
you
can
start
selecting
things
which
you
can
then
also
do
with
modifier
shortcuts.
So,
like
shift
the
highlights,
the
entire
line
and
control
V
doesn't
block
highlight
across
multiple
lines.
Stuff
like
that.
So
it's
got
lots
of
these
modifiers
based
around
things
like
that,
and
then
to
actually
make
changes.
You
go
into
the
insert
mode,
so
you
navigate
to
where
you
want
to
go
and
you've
either
got.
For
example.
C
Here
oh
would
start
inserting
on
a
new
line
or
you've
got
I,
which
goes
where
it
currently
is,
or
you've
got
a
which
does
it
after
the
character.
You're,
currently
highlighting
I
think
there's
lots
of
ways
of
doing
that
and
then
you've
got
so
going.
The
thing
that
people
always
get
confused
about
is
how
to
get
out
of
them,
which
is.
C
C
B
It's
very
interesting,
I
think
I
heard
two
things
that
are
very
important.
If
we
go
down
that
path,
which
is
the
neutral
word,
you
said
two
things
you
said
for
me:
the
one
that
the
first
thing
that
you
said
is
it's
extreme
speed
right.
So
if,
if
this
runs
on
top
of
Monaco,
we
don't
know
whether
that
speed
is
still
there.
So
that's
something
we
have.
E
C
Main
reason
why
people
like
these
bindings
for
different
editors
is
that
when
you
get
used
to
the
Vim
key
bindings,
for
example,
by
default
people
don't
navigate
using
the
arrow
keys
in
Vim,
so
they
don't
I
do
because
I
I've,
just
always
navigated
that
way,
but
by
default,
people
use
hjk
and
L
to
navigate
up
and
down
lines.
So
J
is
down
a
line,
K
is
up,
L
is
Right.
C
H
is
left
this
sort
of
stuff
when
that
when
people
are
really
used
to
those
sort
of
key
bindings-
and
they
don't
exist
in
their
editor,
it
can
be
quite
frustrating
so
those
sort
of
navigation
bindings.
So,
for
example,
for
me,
I
use
shift
and
the
the
braces
to
move
up
and
down
these
sort
of
things
when
that
binding
doesn't
exist.
C
That's
quite
irritating
and,
for
example,
on
a
Mac
I
despise
the
fact
that
the
home
end
page
up
page
down
keys
on
Macs
do
not
work
correctly,
like
they
they're
just
wrong
compared
to
Windows
and
Linux,
never
understood
why,
but
in
Vim
it
doesn't
matter
because
the
shortcuts
are
there
anyway,
so
shift
doing.
A
dollar
symbol
is
to
the
end
of
the
line,
doing
a
hat
I've,
never
what's
the
term
for
that
one
over
the
six.
It
goes
to
the
start
of
the
line.
C
C
C
Bmrc
gets
copied
from
from
computer
to
computer
and
it
is
a
mess.
I,
don't
even
know
what
half
this
stuff
does
anymore
like
yeah.
Some
of
these
are
probably
completely
pointless.
I
have
to
copy
the
same
font
over
from
computers
to
computer
I
use
like
really
old
things.
It's
got
hooks
in
for
specific
color
schemes
and
all
this
sort
of
stuff
I
wouldn't
expect
to
handle
any
of
that
sort
of
customization
in
in
the
Monaco
stuff.
C
I'd,
probably
just
leave
it
as
the
default,
because
I
think
if
people
want
the
Vim
bindings,
they
probably
want
the
default
ones.
I
don't
know
if
you
could
allow
custom
key
bindings,
but
it
would
be
a
cool
feature,
but
I
just
don't
know
whether
it's
worth
the
time
investment,
but
it
could
be.
You
know
you
could
always
do
that
later.
F
Just
yeah
a
couple
of
couple
of
notes
regarding
important
stuff
that
was
mentioned,
yeah
about
Wim,
I,
think
first
and
the
most
important
part
I
think
Andrea
mentioned
yeah
that
it's
like
a
religion.
So
if
we
add
at
this,
so
it's
more
like
some
cool
features
that
some
particular
class
of
people
will
would
say.
Oh
gitlab
has
a
whim,
and
so
it's
like
just
a
featurement
of
brand
I,
think
yeah
and
Robert
mentioned
yeah.
F
A
very
important
thing
is
like
a
habit
because
I
I
think
multiple
times,
I
pressed
escape
on
some
Chrome
page
and
was
asked
to
leave
the
page
here.
Do
you
want?
Do
you
really
want
to
leave
the
page
here
just
because
I
accidentally
clicked
the
Escape
as
a
habit
and
regarding
escape
the
previous
version
of
MacBooks,
with
the
touch
bars?
You
don't
have
SK
button
yeah.
It
was
a
pain
for
me
that
I
don't
feel
it
when
I
click
escape
and
yeah,
so
religion
and
habits,
so
yeah
I
think
there's.
B
E
A
F
A
A
C
Think
it'd
be
kind
of
fun
to
have.
If,
for
example,
we
did
that
the
Vim
support
into
the
vs
code,
stuff
that
we
add
in
it
would
be
kind
of
fun
to
have
it
as
more
of
a
global
setting.
So
if
you
use
it
in
that,
it's
also
available
in
the
other
settings,
but
also
some
of
the
Vim
key
bindings,
you
can
get
a
we
used
to
be
able
to
get
until
some
of
the
browser
API
has
changed.
C
You
could
get
Vim
keybinding
support
for
your
web
browser
so
that
you
used
your
vimkey
binders
yeah
and
you
could
use
them
for
like
navigating
websites
and
stuff
like
that,
and
people
I
tried
it
and
it
got
like
a
little
bit
too.
Weird
like
it
was
a
bit
challenging
then,
but
on
something
like
gitlab,
potentially
stuff
like
that
could
make
sense
like
changing
the
the
hotkey.
C
That
brings
up
the
search
bar
to
be
slash
stuff,
like
that,
you
know
you
could
maybe
offer
it
as
a
like
a
site-wide
sort
of
feature,
but
it
I
don't
think
it's
something
that
I
don't
think
it's
something
that
anybody's
like
Oh.
We
must
have
this
or
we'll
never
use
gitlab,
but
it's
more
like
if
you
do
have
these
sort
of
settings,
people
might
end
up
relying
on.
C
It
if
other
products
don't
have
them.
That's
then
frustrating
like
if
you
get
used
to
navigating
something
in
that
sort
of
way,
especially
with
keyboard
shortcuts.
They
become
very
second
nature
and
that's
why
I
I
just
never
change
my
Vim
RC
file.
If
I
lose
that
file
I'm
quitting
programming,
I
I
won't
be
able
to
do
any
work
anymore.
C
B
A
To
conclude,
to
conclude
this
discussion,
we
can
we
can
use
it
as
an
extension
for
Source
header.
We
can
try
with
emacs
to
to
to
get
to
get
complete
hype
box
in
place.
We
it's
just
it's
just
going
to
be
like
opt-in
option,
but
it's
it's.
It
should
be
totally
possible.
I
haven't
tried
this,
but
but
should
be,
should
be
possible.