►
From YouTube: Integrating WYSIWYG Editor into Editor Lite
Description
Denys demonstrates how we can implement a WYSIWYG editor as a panel view extension in Editor Lite. We discuss future implementation concerns like a full screen WYSIWYG view, a shared toolbar, and implementing different versions of the WYSIWYG view that satisfy the various editing requirements across GitLab features.
B
Yeah
we
are
here
to
talk
about
integration
of
the
wiz
week.
Editor
the
reach
editor
markdown,
editor
that
enrique
came
up
with,
based
on
tip,
tap
and
pros,
mirror
into
editor
light
as
an
extension,
so
to
to
see
whether
it's
possible
at
all
and
spoiler
alert.
It
is
possible,
it
works
flawlessly,
it's
just
beautiful
now
before
we
before
we
begin.
B
B
A
B
Cool,
thank
you.
So
it's
it's
technically
like
the
before
we
before
we
proceed.
I
just
had
one
question
so
technically
we
do
not
like
in
general,
I'm
not
saying
that
this
is
what
we
what
we
have
to
do,
but
in
general
we
do
not
even
need
to
use
steep
tap
right,
like
the
parts
that
we
are
more
we
are
interested
in
are
pros,
mirror
and
market
markdown
right,
tiptop.
A
A
What
tita
does
is
making
us
productive,
so
brush
meter
was
not
designed
to
be
used
directly.
It
is
a
toolkit
to
implement
a
rich
text
editors,
but
then
out
everything.
That
is
that
we
have
to
do
to
provide
a
visual,
a
visual
user
interface
like
a
toolbar
or
when
you
want
to
select
some
text
and
display
a
menu
to
change
the
format
of
that
text.
Selection
tip
that
provides
an
api
as
some
and
you
know,
an
infrastructure
to
to
implement
that
easily
right.
B
A
Things
from
tiptop
there
was
a
preview
attempt
to
create
that
we
see
with
ether
in
gitlab,
but
that
didn't
come
true
that
didn't
come
to
fraction.
Oh
okay,
so
there
wasn't
enough
resources
like
to
continue
with
the
implementation
and
at
some
point
we
rolled
back
all
of
those
all
of
that.
Well,
we
were
switching
from
some
custom
dfm
code
to
convert
markdown
to
html.
Today,.
A
B
Wait
wait
a
second
but
you're,
saying
that
the
scripts
in
javascript,
slash,
behaviors,
slash
markdown
are
not
used,
those
those
are
dead.
That's
right!
Oh
wow!
Okay.
That
confused
me
thanks
for
the
clarification.
Nevertheless,
we
are
using
those.
Now
we
will.
We
will
okay
cool.
That's
that's
really
nice
to
know,
because
I
I
thought
this.
This
is
the
part
that
we
are
using
for
gitlab,
flavored
markup
and
seems
like
it's
not,
but
it's
great
to
have
that
basis.
A
From
that
is
that
what
what
one
way
of
going
about
about
these
two
to
deliver?
We
see
we
cater
quickly
in
places
like
the
issue,
description
and
the,
and
the
comment
box
is
that
we
can
convert
the
markdown
using
our
markdown
preview
endpoints,
and
then
we
can
map
that
html.
That
returns
the
markdown
preview
endpoint
to
our
pros
mirror
document.
So
all
of
that
code
that
is
in
the
behaviors
folder
is,
is
doing.
That
is
that,
like
teaching
from
mirror
how
to
convert
that
html
to
a
right.
B
Can
use
it
very
well.
That's
that's
really
good
to
know.
Okay,
thanks
for
the
clarification,
so
this
this
was
the
part
that
I
I
thought
we
were
using
already,
but
we
don't
we
we
are
not
so,
but
this
is.
This
already
gives
us
the
basis
for
the
extensions
to
use
in
tiptop
or
like
in
in
this
wysiwyg
editor.
Okay.
Now
how
do
we
approach
this?
So,
let's?
B
No,
yes,
no,
okay,
cool!
Let
me
just
I'm
just
here:
okay
I'll
share
this
screen.
Apparently
this
can
go
away.
So,
okay,
we
are
on
this
I've.
I've
started
implementing
this
for
blobs,
just
regular
blobs
just
because,
because
I
don't
know
why-
just
just
because,
because
blobs
might
benefit
from
this
as
well
so
blobs,
the
editing
interface
called
the
blobs
is
already
driven
by
editor
light
right.
B
B
I'm
back
we,
while
we
are
in
the
code
editor
we
do
not.
Do
we
don't
do
anything
with
the
wizard
week.
Editor
like
I
envision
this
as
we
are
getting
to.
First
of
all,
it
would
be
great
to
have
a
setting
for
the
user,
like
I
prefer,
wysiwyg
editing
and
then,
when
the
user
has
this
on,
whenever
they
get
to
to
a
markdown
file,
they
get
the
wizard
editor
by
default.
B
Still,
there
will
be
editor
light
underneath
that
is
catching
all
the
things,
so
they
will
not
be
shown
side
by
side.
Normally,
that's
why
we
do
not
update
what
each
of
them,
while
we
are
typing
just
to
to
save
time
and
to
save
the
events,
the
defense
noise,
obviously
so,
and
that's
how
I
how
it
was
done
in
in
the
demo
that
you
showed
enrique
where
you
you,
you
didn't,
have
two
tabs.
I
mean
two
views
side
by
side.
B
B
B
So
whenever
we
do
manipulations
with
the
wysiwyg
editor,
all
of
them
have
to
be
mapped
to
the
content
editor
to
the
code
editor,
but
not
the
other
way
around,
because
when
we,
for
example,
clicks
commit
changes,
we
take
content
from
the
code,
not
from
the
wizard
week,
so
we
can
obviously
do
some
blah
blah
blah
blah
blah
and
then,
when
we
focus
out
of
this
con
wizard
we
getter
the
code.
Editor
gets
updated,
so
we
can
add.
For
example,
I
don't
know
we
can
add
the
list
items.
B
Oh
I'm
sorry,
the
list
items
for
example,
and
then
they
show
up
here
in
the
wiz
we
get
it
so
with
editor,
has
been
implemented.
As
I
said
as
the
this
is
not
so
interesting
now
so
wizardwick
editor
has
been
implemented
as
the
extension
to
editor
lite,
and
in
this
extension
I
took
your
whole
proof
of
concept
enrique
and
just
wrapped
it
into
the
extension.
So
it's
not
like
I
was
trying
to
mimic
anything.
I
wasn't
trying
to
to
to
to
change
at
least
not
a
lot
of
things
like
I
did.
B
B
Things
are
fine
right,
so
we
also
reflect
what's
going
on
and
it's
just
working
fine.
There
are
some
some
glitches
when
we
communicate
between
wheezy
week,
editor
and
editor
live,
but
we'll
we'll
get
back
to
those
in
a
second
one
of
those
you
you
see
instantly.
So
if
we,
for
example,
remove
this
and
we
use
the
markup
that
is
actually
required,
but
when,
when
one
pushes
the
new
documentation
to
our
documentation,
portal
danger
will-
or
I
don't
know-
I
don't
remember
the
the
job
name.
B
I
think
it's
danger
will
complain
if
you
are
not
using
the
oh,
it
was
it's
the
markdown
linting.
So
if
you
are
using
the
asterisk,
that
is
still
the
valid
list
bullet
list
item
marker,
the
linter
will
complain
and
the
job
will
fail.
So
it
will
require
you
to
use
the
dash
and
it
does
work.
But
if
we
take
the
content
out
of
the
wizardweak
editor,
they
get
converted
into
the
asterisks.
So
technically,
this
document
won't
pass
the
limiting
to
our
documentation
portal.
B
B
A
B
No
like,
if
we,
if
at
some
point
we
decide
to
use
this
as
the
editor
for
documentation
portal,
we
will
have
to
make
sure
that
it
passes
the
lint
linter
there
right.
That's
why
I'm
saying
this
is
something
a
premature
optimization
at
the
moment,
but
if
we
are
about
to
introduce
any
linting
that
is,
for
example,
for
documentation
portal,
this
document
won't
pass
the.
A
B
That's
that's
exactly
it,
so
I
I
assume
it's
just.
We
just
need
to
tweak
it
really
like
minor
tweak
to
say
like
okay.
A
bullet
list
item
is
not
asterisk
by
dash
and
that's
because,
as
I
said,
asterisk
is
still
valid
mark
a
markdown
for
for
the
bulleted
lists.
It's
just
our
linter
prefers
dashes
over
asterisks
and
fails
if
we
don't
follow
that.
So
this
is
something
just
to
keep
in
mind.
If
and
when
we
get
to
that
point,
it's
just
something
that
that
is.
B
B
B
There
are
plenty
of
commits
here,
but
some
of
them
are
so
the
first
one
is
just
updating
updates
to
edit
the
light
itself
to
to
introduce
new
functionality
that
we
will
need.
Then
I
I
just
copy
over
everything
that
was
in
the
wysiwyg
editor's
proof
of
concept,
and
then
some
tweakage
goes
on
there.
So
the
most
important
things
are
to
look
at
are
definitely
the
extension
itself,
and
this
is
this
is
all
it
takes
to
connect
or
no
I'm
lying
this
and
one
more
one
view
component.
B
So
this
is
what
is
needed
on
the
editor
lights
side
of
the
things
to
to
make
things
work
together
between
these
two
editors,
editor
light
supports
extensions
and
every
extension
can
have.
It
can
has
this
innate
method.
So
this
is
the
method
that
every
extension,
every
extension
can
have
to
introduce
some,
not
the
extension
to
the
to
the
editor,
but
to
set
up
editors
at
to
some
degree
to
introduce
new
elements
to
do
to
do
different
things.
So
in
this
particular
case
we
are
introducing
yeah.
I'm.
A
But
if
there
is
a
use
case
for
that,
we
can
definitely
do
that.
So
one
of
the
of
the
use,
I
I
see
that
the
we
see
we
you,
I
think
that
we,
it
should
be
configurable,
because
imagine
that
we
are
we
are
implementing
well,
we
are
using
that
we
see
with
view
in
pictures
like
the
wiki,
a
feature
like
the
star
excitator
both
offer
offer
a
rich
average
text,
editing
experience
right,
but
they
have
very
different
features.
A
B
B
B
B
So
that's
that's
pretty
much
it.
So
if
we
need
to
pass
the
parameters
we
just
we
can,
we
can
do
this.
It's
just
a
matter
of
specifying
how
those
parameters
are
sent
to
the
extension
from
from
sort
of
from
the
end
users,
for
example,
from
the
actual
implementation
in
the
blobs
or
in
in
snippets,
or
something
like
this,
and
what
makes
this
process
a
bit
a
bit
a
bit
challenging
is
that
we
also
have
the
view
component
for
led
light
and
passing.
B
A
C
A
So
see
this
ater
class
is
like
basically
the
the
main
import
of
tiptop,
and
then
we
are
possibly
passing
their
pretty
much.
All
of
the
pictures
that
they
wish
would
hate
or
would
would
support.
So
these
are
you
know,
as
an
initial
demo.
I
I
just
take
those
arguments.
I
took
those
create
these
parameters
where
you
pass
an
array
of
extensions,
but
you
know
that's
good.
That
would
be
like
they.
They
go
like
to
actually.
B
That's
that's
the
thing,
that's
thing
as
you,
as
you
might
see
this
particular
editor.
This
particular
file
has
been
changed,
comparing
to
the
to
your
proof
of
concept
and
the
reason
why
I
had
to
change
this
exactly
because
I
had
to
pass
the
options
that
were
not
acceptable
previously,
so
I
removed
those
hard-coded
extensions
and
now
I
actually
use
all
the
extensions
that
we
have
in
the
behaviors
markdown
folder.
B
So
we
use
those
extensions
here.
We
use
the
extensions
that
are
passed
to
the
to
the
constructor
and
also
we
have
the
options
and
how
we
are
using
this.
We
are
going
to
look
at
in
a
second.
Let
me
just
let
me
just
get
back
to
the
to
the
extension
part
at
the
moment
to
show
what
is
what
is
it
responsible
for
so
we
have
this.
We
create
a
panel
widget,
so
edit
the
light
allows
allows
users
to
create
three
types
of
widgets
content,
widget
overlay,
widget
and
panel
widget.
B
So
the
first
two
content,
widget
and
overlay
widget
come
from
monaco.
They
are
native
widgets
of
monaco.
The
third
one
the
panel
widget
is
the
widget
specific
to
edit
the
light.
What
does
panel
widget
do?
What
is
the
difference
between
these
three?
So
let
me
switch
to
the
browser,
so
the
over
an
overlay
widget
would
create
a
widget
that
is
fixed
on
the
screen
of
the
editor
whenever
like.
If
you
scroll
the
widget
stays
there
the
com,
it's
it's
useful
to
show
some.
B
I
don't
know
validation,
information
or
some
some
other
document-wide
information.
There
is
another
type
of
widget
the
content
widget
that
is
connected
to
a
particular
place
in
the
text.
This
is
useful
to
show,
for
example,
some
particular
errors
or
something
with
when
validating,
so
it
is
related
to
particular
place
in
the
document
and
the
panel
widget.
The
concept
that
input
that
is
introduced
by
editor
light
is
some
is
the
widget
that
exists
outside
of
the
editor's
context.
So
this
is
the
panel
widget.
It
leaves
outside
of
the
editor.
B
But
that's
again,
that's
another
story.
This
is
panel
widget,
the
the
the
new
concept,
and
this
is
technically
the
main
part
of
the
of
the
extension
another
important
part.
Obviously,
is
we
initialize
the
view?
So
the
interesting
part
is
that
editor
light
itself
is
framework
agnostic.
However,
one
can
use
any
framework
they
need
in
the
extensions.
So
in
this
particular
case
we
use
view,
would
we
want
to
write
an
extension
in
react?
B
B
B
This
is
technically,
I
took
the
basis
from
the
stories
file
in
the
in
the
proof
of
concept
of
yours,
enrique
and
converted
it
into
more
like
more
suitable
format
here.
So
this
is
based
on
that
on
that
story
thing,
so
we
have,
instead
of
I
just
renamed
the
methods
update
with
a
week
and
update
markdown
to
not
confuse
with
the
with
the
ones
that
we
import,
not
a
big
deal.
I
think
the
main
things
here
are.
B
The
main
change
here
is
that
on
in
the
created
hook
right
first
of
all,
we
inject
the
instance.
This
is
passed
down
from
the
extension,
so
instance
is
the
editor
light
instance.
So
should
the
extension
should
the
weak
editor
in
this
particular
case
do
something
with
the
editor
light
instance,
it
has
all
the
all
the
power
and
all
the
possibilities
to
to
do
that.
So
all
the
like,
the
full
api
of
edited
lite
is
available
too,
with
week
editor,
but
getting
back
to
this
component,
so
we
inject
the
instance
and
then
in
created
hook.
B
I
moved
it
to
create
it
instead
of
mounted
because
it
was,
it
wasn't
mounted
now
it's
in
created
where
we
actually
initialized.
This
main
wizardweak
editor
right,
and
this
is
where
I
actually
needed
to
needed
the
editor
to
accept
the
options.
So,
instead
of
passing
just
the
extensions
as
it
used
to,
we
also
passed
to
handlers
for
on
focus
and
on
blur
events,
and
this
is,
as
I
said,
on
focus.
We
update
the
markdown
like
the
wizardweak
editor,
based
on
the
code
editor
and
on
blur.
B
B
I
just
use
all
the
extensions
that
we
have
in
the
product
now
in
the
editor
extensions,
so
it
extends
our
capabilities
and
also
I
I
also
copied
the
tokens
in
order
to
support
like
inline
code
fans
code,
things
that
things
that
we
definitely
need.
So
I
copied
these
things
from
the
default
markdown
parser
in
prose
mirror,
and
now
we
can,
we
can
write,
I
don't
know
inline
code
or
like
fenced
code
like
javascript.
B
B
D
B
What
can
I
do
we
don't
have?
We
don't
have
a
lot
of
options
here
to
do,
but,
okay.
This
is
one
more
thing
that
I
noticed
like.
If
I
try
to
change
the
heading
for
for
sub
header
now
it
changes
the
first
line
as
well.
That's
that's
something
to
to
to
keep
an
eye
on
and
it
is
updated
here
as
well
to
the
wrong
thing.
This
is
something
I'm
not
sure
it
is
introduced
now
or
it's
somewhere
deep
in
the
in
the
edit,
but.
C
B
A
B
So
this
is
something
to
to
keep
in
mind,
but
this
is
interesting.
I'm
not
sure
I
didn't.
I
didn't
fire
up
the
gitlab
ui
for
proof
of
concept
to
see
whether
it
worked
it's
working
there,
but
I
I'm
sure
it's
working
there
right,
enrique
yeah,
it
is
yeah.
So
do
we
have
anything
in
the
there
are
no
javascript
errors.
Nothing
like
this,
so
this
is
old,
so
oops
I
suddenly
switched
to
the
editor
here.
So
the
text
gets
updated,
but
we
cannot
inject
any
markup
here.
That's
that's
odd.
A
Okay
and
I
have
a
unrelated
question
yeah-
I
need
to
solve
that
problem.
So
that's
something
that
probably
we
can
face
quickly,
but
my
question
is
related
to
a
toolbar.
So
eventually
we
will
have
a
a
single
toolbar
that
should
work
for
for
both
headers
right,
sorry
for
for
both
modes
for
the
wysiwyg
mode
and
the
under
text
mode.
So
in
the
in
the
case
of
the
of
that,
the
visualizator,
the
way
that
the
toolbar
works
is
that.
A
How
do
you
envision
having
a
a
common
interface
that
knows
how
to
interact
with
the
with
the
comments
that
come
from
the
whiskey
creator,
and
also
that
that
it
can
change,
or
you
know,
make
changes
in
the
in
the
in
the
code
later
for
later,
like
like?
How
can
we
have
this
common
toolbar
that
interacts
with
both
objects?
B
Yeah,
it
obviously
does
make
sense
and
that's
how
it
should
be
done.
No
no
question
there
and
I
don't
think
there
will
be
any
issue
with
that
as
long
as
we
as
we
have
some
public
api
to
to
introduce
the
like,
how
do
we
do
this
update
at
the
moment?
So
let
me
take
a
look
at
the
so
editor
content.
All
right
here
we
go.
So
these
are
the
buttons
responsible
for
the
things.
Oh
ease
active
heading
right,
okay,
it's
active!
B
D
A
B
That's
but
as
I
said
I
I
I,
I
think
there
should
be
no
problem
with
with
the
shared
toolbar.
I
didn't
have
time
to
to
do
that
like
because
obviously
this
this
is
not
looking
good,
so
it
has
to
be
just
shared
title
and
branch
thing
and
then
the
toolbar
should
be
shared
for
the
for
the
two.
So
that's
that's
definitely
has
to
that.
Definitely
has
to
be
done,
but
the.
B
So
I
don't
I
don't
envision
any
issue
with
this.
This
is
this
is
going
be
not
so
hard
and
it's
we
can
even
take,
for
example,
this
existing
toolbar
and
make
it
work
for
the
wiz
week
editor
instead
of
this,
this
toolbar
should
we
want
this,
but
probably
we
don't
because
this
I
don't
think
this
is
the
gitlab
ui
components.
B
A
A
You
know,
from
a
technical
point
of
view,
a
standalone
one
that
we
see
with
view
is
working
like
full
screen,
and
then
you
switch
between
the
code
and
the
remotes.
So
I
didn't
fully
understand
when
you
explained
the
the
panel
widget
and
that
we
can
eventually
make
it
full
screen.
So
could
you
go
over
that
again
and
yeah?
Let's.
B
B
Oops
accepts
three
parameters
for
getting
the
getting
its
position,
so
you
can
place
it
on
top,
like
above
the
editor
to
the
right
below
and
to
the
left
of
the
editor.
So
this
is
just
the
position
in
this
case.
We
are
seeing
like
place
it
to
the
left.
Then
it
has
the
width
index
and
height
index
instead
of
specifying
hard-coded
pixels,
I'm
using
just
the
ratio
of
the
editor's
height.
B
It's
going
to
look
a
bit
odd
with
the
editor
still
sticking
on
the
side,
but
it
gives
the
idea
of
how
this
this
is
supposed
to
look
like
like
that.
Blinking
obviously
won't
happen
so,
and
this
is
this
is
how
we
do
the
thing
so
yeah
not
like
not
a
big
deal
so
technically
the
the
answer
is
we
somehow
remove
the
editor
light
from
the
view
it's
either
hidden
using
css
or
like
we
can.
We
can
say:
okay,
visibility,.
D
Does
this
also
like
mean
with
like?
Could
we
like
prepare,
like
the
the
wizard
week
version
of
edit
to
light
with
like
a
plugins?
Is
this
something
we
can
really
configure,
as
is
kind
of
like
a
pre-configured
layout?
This
is
how
it
looks
and
if
you
kind
of
open
it
up
for
the
wiziwik
kind
of
work,
or
so
that
says,
okay,
you
will
just
kind
of
be
presented
with
this
view
by
default,
and
it's
like
it's
pre-configured
to
say
this
is
exactly
how
we
want
it
to
behave
with
all
the
plugins.
B
That's
a
brilliant
question
man
because
technically
that's
that's
where
editor
editor
light
shines
right,
so
we
can
like
it's
all
about
just
adding
the
adding
the
extensions
to
the
edited
light
and
we
can
even
prepare
a
view
component
saying
like
reach
text
editor
that
under
the
hood,
will
include
the
editor
light
view
component
with
predefined
set
of
extensions
and
you're
done.
That's
it
as
easy
as
that,
no
problem.
B
So
yeah,
I
think
it's
it's
it
shouldn't
like
the
places
where
we
do
this
replacement.
Don't
even
need
to
be
view
aware,
because-
and
this
is
again
like
I
I
can-
I
can
talk
about
nice-
things
in
edit
live
for
for
hours.
Obviously,
but
this
is,
as
I
said,
this
is
one
of
the
strongest
points
like
the
burden
of
pulling
in
dependencies
and
managing
those
is
on
the
extensions.
B
So
we
can
use
wysiwyg
adder
with
view
powered
toolbars
and
everything
in
any
surrounding,
because
the
editor
light
itself
is
framework
agnostic
and
it
pulls
the
extension
and
the
extension
pulls
in
everything
it
needs.
So
this
is
beauty.
This
is
the
beauty
of
editor
live
because
it
doesn't
need
view
to
be
around
it's
it's
framework
agnostic,
so
we
can
yeah.
A
B
Obviously,
and
and
like
you
saw
how,
how
small
the
the
extension
is
right
so
technically
we
create
the
extension
with
the
new
set
of
options
to
be
sent
to
the
wizard
edit
and
that
that's
as
simple
as
that
done
within
five
minutes
right.
We
don't
need
to
create
any
internal
logic
to
check
whether
we
are
on
this
view
or
this
view,
or
that
view
just
two
different
extensions
done.
B
I'm
I'm
you
know
I
I
might
sound
like
overly
optimistic
and
I
I'm
I'm
afraid
of
myself,
sometimes
as
well,
but
seriously
like
whenever
I
accept
the
challenge
to
to
implement
something
in
editing
light.
It
just
just
works
man
like
I'm
scared,
myself,
and
I
I
don't
know
when
when
it
will
shoot
me,
it
should
be
in
the
food,
but
it
just
works.
So
that's
that's,
really
cool.
Okay.
We
can't
make.
B
B
How
cool
is
that
man?
I
know
you
spent
enormous
amount
of
time
figuring
this
out,
but
that's
that's
the
the
cool
thing
like
we
can
we
do
the
research
separately
on
different
things,
and
then
we
have
the
platform
that
can
combine
all
those
researches
without
stepping
into
each
other's
tools.
That's
that's
the
beauty,
cool.
B
D
A
Yeah,
so
okay
sounds
good
well
well,
so
I
think
that
what
I
would
like
to
do
now
is
explore
the
proof
of
concept
that
you
implemented
and
see
how
well
I
think
that
there
are
things
that
I
that
I
would
like
to
have
more
information
about.
For
example,
I
want
to
understand
how
we
can
implement
a
toolbar
that
is
shared
between
the
the
two
modes.
I.
A
I
want
to
understand
more
also
about
the
extensive
I
mean
the
extensibility
of
the
of
that
we
see
with
both
across
all
of
the
pictures.
I
know
that
probably
the
the
the
simplest
way
is
just
like
reading
creator
like
extensions,
but
I
want
to
understand
that
a
bit
more,
but
you
know
the
your
introduction
and
everything
that
you've
shown
now
is
like.
It
really
speeds
sp
that
that
process,
yeah
and.
B
B
Because
it's
going
to
be
shared
toolbar,
it
might
be
useful
for
for
different
things.
Right
and,
as
I
said,
I
have
an
issue
to
introduce
the
toolbar,
because
I
want
this
toolbar
to
be
universal,
to
the
point
of
every
extension
being
able
to
add
items
to
this
bar
or
remove
the
items
from
that
bar
so
that,
for
example,
we
have
a
toolbar
and
it
is
used
for
markdown
files
for
markdown
file.
So
we
add
all
of
those
like
bullet
lists,
headers
things.
B
So
all
those
buttons
come
from
the
markdown
extension
not
from
the
wizard
week,
editor
extension,
but
from
the
markdown
extension.
Then,
for
example,
we
are
editing.
I
don't
know
like
what
we
can
do
like
any
other
type
of
file
right.
So
we
can
introduce
the
buttons
that,
for
example,
do
like
injection
of
some
snip
of
some
code
snippets,
for
example,
from
from
from
the
snippets
in
your
gitlab
account
right.
B
So
I
want
a
button
that
will
allow
me
access
to
that
to
those
snippets,
if
I,
for
example,
work
with
ruby
or
with
javascript,
so
that
sort
of
flexibility
and
this
toolbar
is
outside
of
the
scope
of
the
wizard
getter.
And
I
have
the
issue
for
that
to
create
such
a
proof
of
concept
for
such
toolbar
and
because
I
want
again
the
extensions
to
be
able
to
to
do
different
things
when
they,
when
they
are
used.
Instead,
without
touching
the
editor
light
core.
A
B
I'm
not
sure
we
have
to
separate
those
developments
now,
since
we
are
the
same
team
right.
So
that's
like
that's
up
to
the
manager
to
decide
who
will
be
responsible
for
that.
I
have
some
ideas
on
on
how
this
should
be
implemented:
how
to
how
to
implement
this
to
to
follow
the
the
concepts
that
are
in
the
other
light
and
make
it
like
extensible
again-
and
that's
that's
the
thing,
but
there
is
again
this
will
be
an
extension
because,
again,
not
all
the
instances
of
editor
light
need
toolbar.
B
A
B
The
only
thing
that
I
would
like
us
to
to
keep
in
mind
is
that,
apparently,
we
will
be
willing
to
implement
this
with
view
components
right
like
to
for
it
to
be
consistent
with
the
rest
of
the
product,
and
this
might
be
a
bit
of
a
like.
Not
a
problem,
but
pulling
view
in
different
in
different
extensions
could
be
a
bit
of
a
performance
bottleneck.
So
if
we
could
implement
this
with
just
html
and
our
utility
classes
from
gitlab
ui,
that
would
be
perfect.
B
A
A
You
know
to
to
make
the
the
text
the
modifications
like
inserting
some
characters
to
make
a
a
text-
selection,
bold
or
emphasized,
in
the
same
way
that
that
that
ticked
up
those
right
or
cross
mirror
like
it
exposes
commands.
There
are
an
api
to
modify
the
content,
but
then
the
visual
part
is
decoupled
from
the
from
the
actual
editor.
B
Yes,
yes,
so
technically,
this
is.
This
is
a
very
good
point,
like
every
every
extension
has
the
context
of
and
knows
about,
the
editor
light
instance.
So
every
extension
has
has
this
keyword
pointing
to
the
to
the
instance.
This
extension
is
used
at.
So
all
the
extensions
now
know
about
the
instance
and
the
way
I
envisioned
this,
the
toolbar
should
be
implemented
as
the
pound
widget
panel
widget.
B
B
But
that's
that's
that's.
Every
extension,
like
extensions,
are
really
decoupled
right
and
as
long
as
you
intentionally
do
not
couple
those
they
are
decoupled,
they
are
not
like
above
editor
light
or
on
the
same
level
they're
just
like
separate
modules.
That's
that's
it
so
they're.
The
only
thing
that
connects
them
to
the
edited
light
is
this.
D
C
Yeah,
I
was
really
mostly
just
listening
to
be
sure.
I'm
up
to
date
on
what's
happening
to
be
informed.
I
love
what
I'm
seeing.
I
think
anything
we
can
do
to
make
sure
that
greece
week,
but
also
marked
an
editor,
is
working
both
at
the
same
time
in
different
situations
in
different
contexts.
That's
just
gonna
bring
us
forward
so
much
and
giving
us
this
kind
of
flexibility.
D
Thank
you,
my
two
cents
also
I'm
going
to
throw
in
a
mix.
So
I
really
like
what
I
saw
as
well
like
I
like
the
concept
of
things
being
like
kind
of
like
puzzle,
pieces
or
so,
and
whatever
kind
of
things
we
try
to
solve
for
our
users
for
our
product,
which
just
kind
of
take
these
pieces
and
assemble
them
in
certain
directions
or
so
or
combinations.
D
That
kind
of,
like
just
yields,
perfect
user
experience.
I
really
like
this
approach
and
we
see
okay
like
on
the
wiki.
We
want
to
use
wysiwyk
for
people
like
to
edit
or
so,
but
also
if
they
want
to
switch
over
to
the
editor
view,
because
they
just
feel
some
developers
feel
more
comfortable
in
working
in
kind
of
like
code
per
se.
Like
I
really
like
this
approach
that
we
can
find
like
really
custom
configurations
for
each
kind
of
like
setting
or
kind
of
try
to
achieve
it.
B
D
They
say,
oh,
like
this
person's
responsible
is
weak,
like
I
really
want
all
of
us
to
be
responsible
for
the
wysiwyg
as
an
extension,
for
example,
and
that
we
all
kind
of
share
and
can
contribute
and
feel
comfortable
in
contributing,
but
I
also
kind
of
really
want
to
have
enrique
coming
in
with,
like
all
the
knowledge
that
he
says.
Okay,
I
feel
like
very
big
ownership
about
everything
and
I
feel
comfortable
in
contributing
to
editor
light,
as
is
right
now
to
kind
of
provide
more
extensions
or
make
kind
of
things
more
usable.
D
C
C
We
are
setting
a
smart
default
for
where
we
show
which
kind
of
version
version,
but
still
let
the
user
decide
to
switch
to
the
other
version.
Still
let
the
user
decide
how
they
prefer
to
write
content
in
some
kind
of
way
and
make
that
a
fixed
setting
it
doesn't
all
have
to
be
ruled
by
just
one
line.
C
It
can
make
a
lot
of
sense
to
to
think
very
deeply
about.
Where
would
which
kind
of
view
make
the
most
sense
as
a
default
and
then
see?
Do
we
want
to
allow
this
flexibility
in
each
and
every
single
case,
and
do
we
want
to
make
this
a
setting
everywhere
or
are
there
cases
where
it
just
doesn't
make
sense
to
switch
to
the
other
one?