►
Description
A sync discussion to discuss whether Toast UI is the right editor to build on for the future of the Static Site Editor.
Issue to follow for updates: https://gitlab.com/gitlab-org/gitlab/-/issues/227131#note_375128985
A
A
A
If
the
things
should
come
to
a
point
where
we
want
to
have
a
discussion
to
determine
whether
shoot
is
toast,
UI
editor
the
right
tool
for
us
for
the
long
term,
we've
made
some
significant
investment
in
writing.
I,
don't
want
to
say,
custom
code
for
it,
but
code
using
the
API
is
that
it
provides
already.
It's
not
features
that
it
comes
with
out
of
the
box,
but
so
we
fixed
ended
the
functionality
through
the
public
API
is
that
it
has.
A
However,
all
of
those
said,
the
purpose
of
of
the
discussion
that
we
are
starting
today
and-
and
that
will
concluding
the
issue
is
to
to
get
to
the
point
where
we
want
to
make
a
determination
whether
we
commit
a
toast
UI
editor
for
the
long
term,
I'm
not
talking
about
the
next
two
or
three
milestones.
I'm
talking
more
six
twelve
months
down
the
line,
do
we
still
want
to
be
building
on
top
of
toast?
You
are
and
you're
in
the
short-term,
it's
there
and
we'll
use
it.
A
We're
not
going
to
pause
with
our
development
efforts
right
now
and
and
and
kind
of
like
switch
everything
if
we
did
I
would
imagine
if
we
do
decide
to
move
to
a
different,
editor
or
different
strategy.
We
would
do
it
behind
the
feature
flag
and
in
parallel,
while
trying
to
achieve
our
main
near-term
objective,
which
is
integration
of
the
handbook
and
allowing
a
easier
editing
experience
of
that.
A
But
we
need
to
start
making
this
decision
now
and
start
understanding
the
impact
of
the
decision
that
we
make
so
that
we
can
factor
that
into
our
roadmap
going
forward.
So
that's
a
brief
kind
of,
like
recap
of.
Why
are
we
meeting
and
the
expectation
of
what
the
outcome
of
the
discussion
needs
to
be?
We
don't
have
to
discuss
if
we,
if
we
end
up
work
on
the
decision
of
year,
we
want
to
explore
it,
we
should
it
be
exploring
it
different
editor.
A
The
objective
is
not
to
identify
which
editor,
yet
it's
merely
a
decision
of
East
Hurst
UI
the
right
tool
to
build
our
static
cited
as
a
product
on
top
of
for
the
next
six
to
twelve
months
with
that,
Eric
gave
a
quick
overview
of
the
product
direction
that
he's
been
exploring
for
a
static
site
editor,
and
that
gives
valid
input
into
this
discussion
as
well.
We
can't
negate
where
we
want
to
go
fix,
12
months
down
the
line
and
exclude
that
kind
of
decision.
A
It
really
has
to
be
pods
but
I'm
gonna
hand
over
to
Eric
and
asking
Eric.
You
don't
have
to
obviously
in
detail
kind
of
like
go
through
everything,
but
just
the
top
level
summary
of
of
conflict.
What
you
do
discussed
in
yesterday's
group
calls
the
videos
off
which
are
available
and
team
members
can
catch
up
on
that
as
well.
So
Eric
thanks.
B
Yeah,
so
let
me
post
a
link
to
the
image
I
shared
in
a
design
group
call,
but
I
think
as
far
as
medium
to
long-term
vision.
What
we're
talking
about
here
is
wanting
to
provide
an
editing
experience
that
is
as
fully
functional
in
the
WYSIWYG
mode
as
possible,
in
that
we
are
I'm
I'm,
not
convinced
by
our
initial
research,
that
a
a
splitview
live
preview
code.
B
Slash
like
rendered
HTML
version
of
the
markdown
is
gonna
solve
our
users,
needs
I.
Think
the
editing
experience
if
I
can
just
use
some
other
products
as
examples.
The
editing
experience
of
something
like
Dropbox
paper
or
notion
or
even
Google
Docs
is
more
familiar
and
more
intuitive
for
our
users
and
the
type
of
content
that
were
we're
hoping
to
target
with
these
changes
is
a
lot
more
editorial,
long,
longer
form
or
or
at
least
structured
by
nature.
B
So
the
ideal
path
in
my
mind
right
now,
would
be
that
we
have
a
fully
fully
featured
WYSIWYG
editor
that
provides
real-time
feedback
of
markdown
formatting,
but
doesn't
require
you
to
know
markdown
syntax,
if
you
do
know
/
trance
coming
and
the
issue.
If
you
do
know,
markdown
syntax
I'm
hopeful
that
we
can
have
formatting
shortcuts
so
that
you
can
actually
type
in
markdown
and
it
would
render
on
the
fly,
we
definitely
want
to
keep
that
in
mind
and
and
I
think
really.
The
the
goal
would
be
to
somewhat.
B
I,
don't
want
to
say,
hide
the
the
underlying
markdown,
but
make
it
unnecessary
that
you
would
even
need
to
switch
to
a
code
editor
and
then
I
would
add
to
this.
If
we
do
need
to
switch
to
a
code,
editor
I
think
strategically.
It
makes
a
lot
more
sense
for
us
to
align
around
the
code
editors
we
already
have
in
the
app
so
considering
using
editor
light
or
putting
or
sending
people
to
the
web
IDE.
A
Well,
Eric
puts
that
on;
it
might
be
with
just
quickly
recapping
the
three
you
know:
fundamentals
that
we're
basing
our
product
vision
on
the
first
one
is:
the
user
should
not
need
to
understand
markdown
syntax
to
be
able
to
contribute.
The
user
should
not
need
to
be
a
need
to
understand,
get
workflows
to
be
able
to
contribute,
and
your
third
one
is.
You
should
not
have
to
have
to
set
up
a
website
locally
to
contribute
on
their
own
they're
looking
they
have
to
go
into
the
terminal
to
country
it.
B
And
and
ultimately,
what
we're
looking
for
is
is
an
experience
as
close
to
writing
in
a
in
a
document
as
you
can
get
so
imagine
someone
who
is
completely
unfamiliar
with
the
template
layout
of
a
static
site
and
has
just
been
tasked
to
create
a
page
we
we
could
provide
a
long
longer
term.
We've
talked
about
providing
something
like
a
block
editor
or
something
like
that,
where
you
can
insert
elements
that
are
from
a
from
a
preset
list
of
supported
types,
and
we
can
almost
build
a
page
like
that
within
the
editor.
C
I
make
a
comment
on
the
the
comment
I
made
about
being
able
to
edit
the
raw
markdown.
So
I
saw
the
just
now
the
comment
that
you
made
John
and
linked
to
the
the
shorthand.
What
we're
calling
it
like
if
you
type
some
markdown
it'll,
automatically
get
turned
into
something
in
the
WYSIWYG
editor
and
I.
Don't
want
to
derail
this
conversation
and
I
know.
C
That's
not
this
meeting
but
I
still
remain
skeptical
that
that
could
work
like
one
example,
I,
think
of
is
a
code
block,
I
tried
three
ticks
and
then,
inter
and
I
start
typing
something,
and
that
turns
into
maybe
a
code
block
and
I'm
typing
code.
That's
all
fine
but
say
oh
I
want
this
to
be
Ruby.
Actually
I
would
want
to
go
back
and
type
room
e
or
SH
or
Y
Amal.
After
those
three
tips.
It's
how
do
I
do
that.
C
Do
I
have
to
right-click
like
I
I
have
to
know
something,
whereas
if
I
just
know
Martin
down
all
I
have
to
do,
is
we
go
to
the
wrong
markdown
and
type
Ruby
there?
So
situations
like
that,
the
the
convert
on-the-fly
approach,
I'm
still
skeptical-
that
that
would
meet
you
know
the
persona
that
I
am
that
I
want
control
over
the
wrong
markdown
and
I.
Don't
want
to
have
to
figure
out
how
to
get
back
to
it.
B
Totally
fair
point
and
I
think
the
the
challenge
there
is
that
I,
don't
think
an
experience
where
you're
flipping
back
and
forth
is
is
what
we
should
be
building
towards
like
I.
Think,
if
anything,
what
we,
what
I
would
say
is
we
would
continue
to
provide
the
side
by
side
until
we
can
build
a
UX
that
allows
you
to
choose
the
language
or
insert
the
language
in
a
code
block
from
the
visual
editor.
That's
a
good
edge
case.
B
D
It's
all
needs
validation,
but
one
thing
to
kind
of
think
about
too
is
and
I
have
a
response
kind
of
mock
with
some
of
them
Michaels
working
on,
but
basically,
when
you
launch
in
the
call
to
action
to
actually
work
on
a
particular
file,
it's
basically
do
you
want
to
edit
it
like.
Are
you
gonna
kind
of
contribute
more
in
the
code
space
or
more
in
the
content
space
and
just,
however,
that's
framed
that
can
be
the
driving
path
to
your
now
in
the
Monaco
editor,
the
web
ID
or
whatever?
D
That's
more,
you
know,
code
ready.
You
know
her,
someone
who
just
wants
to
contribute
content,
which
again
is
our
focus,
hence
the
WYSIWYG,
and
what
Eric
was
just
referring
to
is
maybe
less
the
need
needing
to
go
back
and
forth.
We
still
could
it
just
might
take
another
five
hundred
milliseconds,
because
you're
actually
gonna
link
out
to
the
other
editor
or
something
like
that
and
obviously
even
further
downstream.
If
that
needed
to
be
integrated,
we
could
still
do
that,
so
that
I
think
there's
possibilities
all
around.
B
We
could
potentially
validate
whether
we
could
expose
just
the
markdown
for
a
block,
like
flip,
just
a
block
to
show
the
raw
source
and
then
flip
it
back,
rather
than
changing
the
whole
editor
back
and
forth.
So
if
you
need
to
tweak
the
source
or
if
you
just
want
to
ensure
that
it's
writing
it
in
the
way
that
you
want,
you
could
do
that.
Just
an
idea.
Yeah.
E
A
A
C
General,
okay,
so
V
I
think
there's
benefit
to
be
had
from
the
static
side.
Editor
experience
aside
from
the
fact
of
it
being
a
WYSIWYG
I'm
just
concerned
about
us
being
like
that's
the
overwhelming
they're
like
the
most
important
feature
of
it,
but
I
think
there's
a
lot
of
benefit
of
I
can
edit
it
in
page
in
the
website.
I
don't
have
to
clone
the
repo.
It
has
an
integrated,
merge,
request,
workflow.
It
lets
me
preview.
B
That's
it
it's
totally
valid
and
and
right
now,
I
think
we
should
move
on,
but
I
say
that
we
should
aspire
to
not
having
the
code
view,
but
that's
not
validated
with
users,
and
it's
very
aspirational
in
that
I
want
someone
to
be
able
to
do
anything
that
can
do
in
code
in
the
visual
editor.
But
that
might
mean
that
we
still
continue
to
offer
the
raw
source.
A
All
right,
Derick
and
Enrique,
the
two
of
you
have
been
I,
would
say,
have
gone
down
the
rabbit
hole,
the
deepest
in
terms
of
the
internal
workings
of
toast,
UI
editor
and
the
underlying
editor
project
that
it
uses.
Can
you
maybe
just
summarize
for
us,
challenges
that
that
we
are
currently
experiencing
that
that
you
feel
might
become?
A
F
So
any
clear
describe
before
we
have
high
aspirations
and
a
big
ambition
about
how
much
you
can
achieve
with
the
WYSIWYG
world
for
to
achieve
that.
We
need
maximum
flexibility
in
what
they
food
that
we
use
to
build
that
that
experience
are
not
allows
us
to
do.
For
example,
if
we
want
to
make
that
switch
from
the
cold,
a
tour
to
a
more
rural
experience,
winning
a
cold
block
right
now,
toast
toast
you
I
doesn't
provide
that
kind
of
flexibility.
F
But
when
you
try
to
jump
into
tasks
like
trying
to
explain
the
markdown
syntax
or
trying
to
take,
we
civic
speak
anything
experience
that
you
are
trying
to
8,
which
contains
and
then
converting
that,
but
to
markdown
it
becomes
very
difficult
because
they
either
do
not
provide
the
required
api's
to
extend
narrator
in
that
way,
or
they
api's
that
they
provide
are
are
not
are
not
enough
to
do
the
kind
of
customization
that
we
need.
Oh.
A
D
Sure
yeah,
basically,
the
first
thing
that
comes
to
mind
at
a
high
level
is
basically
we're
running
into
these
concerns,
because,
mostly
because
we're
supporting
existing
markdown
files
that
have
gitlab
flavored
markdown
right.
So
what
that
essentially
means
I
thought
about
this
on.
My
first
bullet
point
is
github
github
flavored,
markdown
gfm,
is
what
it's,
what
it
leverages
but
get
labs
version
of.
That
is
an
extension
of
that.
What
that
means
is
we
have
a
bunch
of
their
syntax
right
now
that
we're
creating
custom
renderers,
for
so
that's
kind
of
where
this
add
to
complexity.
D
Is
that
we're
trying
to
genrika
spoil
everything
toast
UI?
That
gives
us
a
lot
out
of
the
box,
but
then
now,
when
we're
using
it
in
the
context
of
a
lot
of
our
existing
files
and
dot
your
bead
MD
files,
for
example,
right
there's,
that's
where
we're
running
into
these
issues,
I
just
kind
of
want
to
throw
that
at
a
high
level,
that's
kind
of
where
this
is
kind
of
coming
from,
so
whether
that
can
be
solved
through
a
formatting
all
those
files
right,
that's
something
we're
actually
in
process
of
doing.
D
D
D
D
Wasn't
pursued
basically,
but
it's
something
being
considered,
and
so
this
is
kind
of
kind
of
like
the
cons.
I
also
want
to
say,
see:
Enrique
mentioned
that
it's
kind
of
hack
right
now
that
our
implementation
but
they're
I,
believe
and
correct
me
wrong.
There
isn't
Mr
there.
So
there's
there's
some
positives
to
be
said
here
as
well
or
I
like
there
and
so
I
can
kind
of
hit
on
those
they're
in
the
pros,
like
the
maintains,
have
been
pretty
responsive
and
I.
Think
that
what
I'm
referring
to
there
INRI
can
point
your
point.
D
Three
is
I,
think
you
have
an
M
R
for
that
I
think
you
shared
sure
that
so
it's
kind
of
you
know
another
nice
bonus
in
working
personally
and
working
with
the
custom,
renderers
and
I
know
Enrique
seen
some
of
this
through
reviews
and
probably
working
on
it.
A
little
bit
too
is
the
toast
mark
ast
thought
that
they
put
into
that
is
really
valuable.
D
Again,
maybe
that's
choosing
another
solution
that
goes
away,
but
that
has
been
really
nice
because
I
don't
think
what
I'm
trying
to
say
here
is
we're
not
going
to
get
out
of
needing
these
custom
renders
I
don't
think
because
get
labs
version
get
labs.
Flavored
markdown
is
again
an
extension
of
github
is
flavored
markdown,
which
has
a
bunch
of
other
custom
syntaxes,
so
I,
don't
think
that's
I
could
be
wrong,
but
I
don't
think
we're
going
to
get
out
of
having
to
handle
those
in
some
way.
D
A
So
I
want
to
and
I
put
this
in
the
issue.
Description
like
I'm,
not
bashing,
toast,
UI,
editor,
I,
think
it's
a
great
solution,
I
think
it's.
It
falls
a
need
in
in
the
market
very
eloquently
and
ineffectively
and
and
all
the
pros
you
elicit
a
there.
A
guy
I,
fully
agree
with
my
concern
is
that
our
our
use
case
is
deviating
from
from
the
default
experience.
A
Because
the
way
I
see
it
is
thanks
to
our
litter
is
essentially
a
wrapper
over
Squier
and
code
mirror
and
it
on
top
of
that
it
provides
a
whole
bunch
of
added
goodies,
but
we're
essentially
pulling
away
that
goodies
layer
a
lot
of
time
to
peek
behind.
What's
going
on
to
customize
things
and
we've
seen
it
with
the
the
image
upload
dialog
we
implemented
our
own,
we
didn't
use
the
one
that
came
that
worked.
Then
we've
seen
it
now
with
the
the
source
code.
A
Markdown
editing,
we're
customizing
that
because
we
don't
want
it
to
behave
in
the
default
way
that
behaves
in
the
editor.
So
we
seem
to
be
died.
Diverging
a
lot
from
the
default
value
you
get
from
toast,
UI
editor
from
a
user
experience
and
the
user
case
that
it
provides
and
and
morphing
it
into
what
we
needed
to
be.
A
And
so
my
question
is:
does
it
not
make
sense
for
us
to
develop
our
own
wrapper
over
some
editor,
whether
it's
fire
or
whatever
or
editor,
DOJ's
that
we
looked
into
previously
and
until
your
point,
I
fully
agree?
We're
gonna
have
to
write
custom
renders
we
want
to
do
things
like
mermaid
kind
of
like
diagrams
previewing,
in
line
and
in
a
wizard
editor
and
we'll.
We
want
to
create
a
rich
editor
experience
and
so
will
will
will
probably
keep
in
doing
custom
things
on
top
of
standard
markdown.
I.
A
Think
the
other
thing
to
recognize
here
is
that
tertiary
editor
is
it's
built
to
work
on
what
the
common
mark
spec,
which
is
the
you
know,
call
it
the
default,
markdown
the
complex
synthetic
spec
and
so
we're
throwing
at
it
a
lot
more
than
what
its
default
use
case
is.
My
my-
and
this
is
the
the
crux
of
my
question,
and
the
reason
for
this
discussion
is:
does
what
it
provide
out
of
the
box
and,
for
instance,
you
and
I'm
glad
you
mentioned
the
Turlock
ASD,
because
I
remember
you
reference
that
article.
A
They
wrote
about
it
and
and-
and
they
did
a
lot
of
interesting
work
there
there's
things
like
that,
for
instance,
make
it
worthwhile.
Speaking
with
toes,
you
are
editor
and
peeling
the
layers
away
from
it
that
we
don't
need
to
do
more
fit
into
what
we
have
versus
going
more
low-level
and
using
squire,
for
instance,
directly
and
and
creating
our
own
wrapper
around
that
to
provide
the
UI
user
experience
that
we
want,
rather
than
fighting
the
Toshio
extremes.
A
Because
here's
my
concern,
we
keep
customizing
it
and
we're
doing
it
in
the
right
way
by
using
public
api's.
But
every
time
they
potentially
change
something
we
might
need
to
counter
change
that
to
to
match
our
desired
behavior,
so
upgrade
path
as
they
go
along
might
might
diverge,
and
so
it's
it's
the
same.
We
saw
initially
we
thought
we,
you
know
it
might
when
we
originally
thought
about.
What's
that
exciting
and
it
might
be,
it
might
be
in
the
web
IDE,
and
then
we
realized
as
we
got
into
it.
A
How
that
ringers
on
the
page
and
so
the
WYSIWYG
editor
with
and
and
then
we
also
heard
that,
for
instance,
just
knowing
which
page
where,
where
the
pages
to
edit
was
even
more
important
than
even
the
the
syntax
people
were
willing
to
fight
with
the
syntax
as
long
as
they
could
find
the
page
they
need
to
edit.
So
as
we
started
getting
feedback
and
talking
to
our
users,
our
needs
evolved,
and
so
my
concern
is,
as
we
iterate
on
our
product
and
we
keep
evolving
our
product
vision
and
we're
going
down.
A
There's
this
aspirational
road
of
providing
a
really
great
user
experience
from
a
wizard.
We
get
it
whatever.
You
is
toast
you
I
the
going
to
become
heard
a
hindrance
or
or
a
or
a
savior
files
in
terms
of
what
we
want
to
achieve
in
my
my
non-technical
estimation
here
is
that
it
feels
like
it's
going
to
become
a
hindrance
in
that
we're
gonna
have
to
peel
away
too
much
of
it
to
do
what
it
wants
to.
But
that
is
why
I
really
need
you're
almost
like
counter-arguments
to
say,
no
look
at
toad
smoke
ASD.
A
We
still
need
that.
It's
too
costly
Queenston
supposed
to
develop
that
ourselves
and
maintain
that,
for
instance,
these
are
the
these
are
the
the
factors
that
I
really
want
us
to
consider
is:
let's
make
an
assumption?
Oh,
if
there's
no
strong
opposition
to
to
me
saying
that
I
think
that
it's
become
a
becoming
going
to
become
a
hindrance
and,
and
it's
assumed
that
we
we
need
to
go
down,
move
away
from
it.
Let's
talk
in
about
what
what
would
it
take
for
us
to
to
bring
the
nuts
and
bolts
that
toasty
re-enter
brings?
A
That
makes
it
easy,
for
instance,
to
insert
a
custom
renderer
to
do
the
things
like
like
Jacque
researched
on
the
shorthand,
where
you
can
type
the
mark
and
syntax
and
converts
for
you,
so
those
are
all
kind
of
like
nice
C's
that
we
want
and
if
taking
those
things,
if
taking
totally
our
editor
out
of
the
picture,
takes
those
things
away
and
it
it
requires
us
six
months
to
rewrite
that
then
like
that.
That
kind
of
like
makes
the
cost-benefit
analysis
different
again.
A
So
I
guess
my
my
request
from
you
is:
what
are
what
what
counter
arguments
can
we
have
to
say
we
should
stick
with
those
do
I
edit
ER,
even
considering
con
treating
upstream.
If
that's
the
way
we
go
like
that
is
not
out
of
the
question
which
we
can
and
should
do
that
if
it
makes
sense.
But
what
are
the
arguments
for
sticking
with
tais-toi
editor,
rather
than
going
straight
to
to
what
it
uses
under
the
hood
and
and
writing
our
own
wrapper
around
that.
F
F
Delete
that
many
that
is
worth
highlighting
is
that
we
are
trying
to
customize,
not
all
we're
going
to
customize
at
different
levels,
for
example
we're
trying
to
provide
a
customization
at
there
at
the
WYSIWYG
level,
because
we
are
trying
to
create
build
tools
to
create
different
sorts
of
rich
content.
We
are
not
only
trying
to
to
build
a
tool
that
allows
us
to
render
a
different
type
of
rich
content.
F
We
also
want
like
to
find
ways
of
of
generating
that
content
and
that's
a
place
where
I
see
a
limitation
in
those
UI,
not
because
of
those
UI,
but
because
of
the
squire
that
it
was
not
designed
for
that
type
of
use.
Case
Esquire
was
designed
as
email
aping
experience
that
doesn't
require
such
a
powerful
tool
and
that's
something
that
a
tourney
JSP
some
other
fee
for
another
point
is
a
toe
shoe.
I
created
a
current,
a
markdown,
renderer
and
parser
that
is
called
to
mark.
But
who
is
the
only
maintainer
of
those
mark?
F
Ystos
UI
is
only
that.
The
toes
you
are
the
toes
you
are,
I
maintainer,
but
there
are
platforms
that
are
very
open,
and
this
is
this.
That
word
is
very
important.
They
were
platform.
There
are
platforms
that
that
are
created
to
support
different
type
of
abstract
syntax
trees
and
to
create
tools
that
makes
easier
to
to
extend
parsers
and
talking
about
unified.
That
is
also
a
platform
that
I
reference
in
there
in
the
h2
about
replacing
they
toss
UI
code
code
later
so
I.
F
Don't
think
that
if
we
end
up
replacing
those
UI,
we
will
replace
it
with
a
to
the
providers.
The
features
that
we
want
we
have
to,
we
have
to
aspire
to
have
a
up,
let's
say,
a
tool
that
becomes
a
platform
and
I
feel
like
okay.
We
have
supported
a
lot
of
support
from
the
community.
That
is
creating
a
lot
of
plugins
for
that
platform,
and
we
can
just
reuse
them.
We
can
benefit
from
that
active
community
that
tells
you,
I
doesn't
have
either
maybe
told
you.
F
I
have
a
community
that
has
many
people
using
the
tool,
but
I
don't
see
a
lot
of
contributions
from
the
outside
because
it
was
not
designed
to
have
that
kind
of
of
community
and
contributions.
So
I
think
that's
where
we
should
go
like.
How
can
we
allow
to
have
many
doors
open?
So
we
can,
you
know,
play
with
options
as
good
as
we
want
a
brother
same
time
how
we
can
take
advantage
of
a
community
that
is
great,
creating
many
things,
our
prana
liquid
world.
So
it's
like
having
the
balance.
F
B
Think
that's
an
important
point
too.
By
the
way,
with
with
the
platform
and
I
was
thinking
about
this
with
just
the
work
we
have
to
do
to
get
the
get
lab,
flavor
and
mark
down
in
there
the
customer
Enders
that
were
building
and
I
think
we
need
to
just
call
out
that
we're
building
this
not
just
for
the
handbook,
I
know
the
points
been
made
before
and
but
I
think.
We
need
to
remember
that
our
users
are
on
any
number
of
different
static
site
generators.
B
Their
preference
might
be
for
any
number
of
flavors
of
markdown,
whether
it's
cramdown
or
common
mark
or
Caleb
github,
flavored,
markdown
or
whatever.
We
shouldn't
assume
that
we're
going
to
build
in
our
small
team
support
for
all
of
those.
So
having
a
platform,
that's
extensible
enough
and
a
feature,
that's
extensible
enough,
so
they
can
plug
in
their
own
renderer,
either
contributing
back
to
the
product
or
maybe
even
linking
out
to
it,
or
something
like
that.
D
And
I
just
want
to
say
so,
I
think
it's
a
no-brainer
not
to
entertain
the
idea
of
using
something
else
right
there,
like
that's
kind
of
like
a
given
so
and
I.
Don't
want
this
to
be
kind
of
a
sunk
cost
fallacy
kind
of
thing
coming
from
my
end,
but
there
is
a
lot
that
it
they
were
getting
out
of
the
box.
We
run
into
some
kinks
right.
That's
why
we're
having
this
having
this
conversation,
which
is
totally
necessary
and
required?
It
was
good.
D
My
only
concern
is
that
yeah
we
try
something
new
and
again.
We
still
need
to
research,
something
and
maybe
it's
there
and
we
find
it
and
then
boom
like
problem
solved,
but
the
amount
of
work
that's
gone
into,
toast
UI,
how
much
that
we're
gonna
have
to
redo.
There's
that
balance
to
think
about
and
then
Enrique's
point.
If
there
is
a
platform,
then
we
can
already
leverage,
then
that
work
is
already
done
potentially.
D
So
it's
just
a
matter
of
there's
always
going
to
be
a
level
of
customization
I
guess:
if
we
can,
we
have
learned
more.
We
can
maybe
Enrique
and
I
could
sit
down
and
maybe
think
you,
through
this
more
deeply
or
something
in
terms
of
like
what
do
we
really
need
and
now
that
we,
you
know
now
that
we've
gone
through
this
experience
or
something
that
might
help,
because
obviously
we're
not
going
to
switch
right
away
right
now
anyway,
even
if
we
could
it
would
take
time,
but
yet
yeah
we
definitely
need
to
look
for.
D
Is
there
something
better?
We
went
down
this
path
because
it
was
the
best
choice
at
the
time.
Given
the
information
we
had
so
that's
kind
of
where
we're
at
but
I
I
agree
with
Enrique.
We
can,
if
there's
a
better
solution,
that's
more
because
of
what
as
a
larger
community,
and
you
know
that
will
a
platform
an
ecosystem
etc
like
then,
naturally,
everybody
wins.
That's
the
whole
advantage
of
having
a
system
like
that,
so
yeah
totally
totally
worth
looking
into
100%.
D
A
Me
both
Enrique
and
Erika,
I'm
gonna,
take
what
all
what
you've
said
and
from
either
like
the
way
I
would
like
to
summarize
it
now
is
that
I
think
we
need
to
do
some
definition
work
around
the
editing
more
from
the
editing
experience
we
want
to
achieve,
not
necessarily
just
from
a
user
experience
point
of
view,
but
from
a
technical
point
of
view,
as
well.
I
think
when
we
initially
validated
editors
out,
they
would
know.
A
What
tools
you
know,
is
it
editor
jeaious?
Is
it
unified?
You
know
what
are
the?
What
are
the
the
things
out
there?
That
could
potentially
speak
to
this,
and
we
will
probably
never
find
a
hundred
percent
match
for
our
needs
and
desires,
but
we
can
find
something
that
that
speaks
about
its
are
non-negotiable
criteria
that
we
have
for
that
with
the
farm
and
the
race.
A
A
A
Okay,
I
see
a
thumbs-up,
yes,
I
think
we
can
also
make
make
the
assumption
from
the
conversation
that
we,
while
while
we
should,
but
we
shouldn't,
discuss
your
editor
just
yet,
because
we
should
evaluate
it
based
on
our
new
definition
that
we
define
it
is,
it
is
likely
that
it
will
not
be
the
long
term
solution.
First
I'm
not
saying
I'm
not
describing
it
yet,
and
we
have
to
look
at
our
definition
and
and
reevaluate
it
against
that
definition,
but
it
based
on
the
initial
discussion.
A
It's
likely
that
it
won't
be
the
future
editor
for
us
with
that
that
in
mind,
we
just
need
to
be
even
more
cognizant
of
how
much
glue
we
write
between
editors
and
and
I.
Guess,
I'm
saying
it
just
as
a
reminder
reiterating
that
we
should
keep
this
as
loosely
coupled
as
possible,
which
I
know
you're
really
doing
so
that
that
I
think
is
I
mean
the
job
that
Eric
and
I
would
need
to
do
is
to
figure
out
how
this
fits
into
our
roadmap.
Where
we
want
to.
A
We
already
know
what
13-3
is
going
to
bring
more
or
less
and
but
looking
at
13
for
15
5,
how
we
do,
maybe
we
can
give
it
to
the
crew
to
work
on
some
of
the
user
experience
beyond
just
the
the
initial
WYSIWYG
editing
experience
once
we
have,
the
minimum
criteria
met
full
for
the
handbook
editing.
You
know
the
MRO
creation
process
and
approvals
and
stuff
like
that.
So
that's
that's!
The
only
kind
of
like
considerations
I
think
we
we
have
as
well
I.
D
D
If
we
know
that's
why
we
don't
work
that
way
here
in
the
sense
of
like
we
work,
incrementally
it's
good
to
have
the
long-term
vision,
but
we
don't
know
100%
if
that's
going
to
be
it
like,
for
example,
if
today
we
decided
to
do
the
block
editor
in
long-term
vision
and
then
that
isn't
actually
what
we
needed
or
where
the
users
wanted,
then
you
know
we've
kind
of
so
anyway.
You
already
know
this,
but
I.
D
A
A
A
Is
that
something
we
want
to
give
consideration
in
in
the
near
term,
regardless
of
what
our
determination
or
our
definition
and
research
my
monitor,
throw
up
over
the
next
month
or
so?
Do
we
want
to
stick
with
what
we
have
just
considering?
Where
we're
going
or
do
we
want
to
conserve
al
you?
Is
they
enough
value
in
in
saying,
let's
use
the
editor
light
for
for
the
source
code,
editing.
D
Frankly,
but
again,
the
idea
was
we
can
get
that
for
free
if
we
were
to
leverage
Monaco
and
again,
the
maintenance
burden
related
to
that.
So
that's
where
the
it
gets
deeper,
but
really,
if
like
it,
was
vital
to
have
matching
syntax,
a
color
highlighting
and
that
kind
of
thing
like
we
could
do
that
overriding
with
CSS
in
it
and
it
would
be
in
one
location
most
likely.
So
it
wouldn't
be,
like
you
know,
easy
to
pull
out.
Basically,
if
we
from
that
specific
portion
out
that
big
of
a
deal
but
so.
A
What
I'm
reading
reading
your
answer
is?
This
doesn't
necessarily
have
to
be
done
right
now
as
part
of
our
our
short
term
objective
of
successful
integration
of
the
handbook
and
Eric
you
might
want
to
back
back
this
up
in
my
assumption,
is
that
with
no
big
editing
mode
will
be
more
important
than
mark
time.
Editing
work
for
our
initial,
just
integration
of
the
handbook
and
and
and
validation
tasting
from
users.
Yeah.
B
I
think
that
it's
an
accurate
statement,
I
think
we
should
move
towards
a
plan
to
you
to
use
something
like
the
Monaco
Lite
editor
as
our
source
view,
but
it's
not
vital
to
getting
feedback
at
this
stage
and
if
style,
consistency
is
all
we
get,
it
doesn't
seem
like
the
right
time
to
invest
in
building
a
custom.
You
know
bridge
between
the
two
is.
A
Believe
it's
still
the
case,
but
I
would
I
would
argue
that
and
and
again
this
is
just
an
opinion.
I
would
argue
that
the
wizarding
editing
experience
would
be
more
important
to
ensure
that
works
on
mobile
than
than
the
source.
Editing
experience,
that's
just
my
the
way
I
read
kind
of
like
our
user
needs,
but
again
it's
just
an
assumption.
In
my
side,
I've.
B
Talked
to
Kai
about
this
and
mobile
support
in
the
web.
Ide
is
like
less
than
ideal,
but
it's
not
completely
broken
we'll
say
and
a
lot
of
it
has
to
do
with
just
the
overall.
You
know,
structure
and
the
amount
of
information
that
web
ID
needs
to
have,
but
the
actual
editor
itself
is
functional.
There's
prior
would
guess
at
this
point.
A
All
right
before
we
wrap
up
any
parting
thoughts,
I
will
I
will
summarize
the
contract
key
takers
of
we're.
Not
let
me
summarize
the
key
tie
cuts
here
that
I
will
put
in
the
issue
to
formalize
it.
We
are
not
going
to
in
the
short
term
and
when
I
say
short
term.
Next,
one
two
three
miles
the
milestones
switch
out:
the
the
markdown
editor
with
editor
light.
That
does
not
mean
we
won't
do
it
in
the
future.
A
We
are
we're,
also
not
going
to
stop
working
with
toast
UI
editor
in
terms
of
potentially
contributing
back,
keep
integrating
with
it,
but
we're
gonna.
Do
it
in
a
sensible
way
that
it's
as
loosely
coupled
as
possible,
so
that
if
we
move
away
from
it,
you
know
our
coding
back
is
internalized.
I
will
open
an
epoch
that
describes
our
intention
to
to
that
revalidate
the
ideal
editor
platform
to
build
our
product
on,
and
it
will
have
two
issues.
A
F
E
A
Iii
think
in
terms
of
researching
alternatives,
it
would
be
what
is
this
collection
of
tooling
that
we'd
need
to
achieve
what
we
want
to
achieve.
I,
don't
think
like
thirstier
editor
is
by
far
what
I
saw
the
most
complete
mark
standard,
markdown
editor
out
there
from
a
WYSIWYG
and
source
and
preview
point
of
view.
It's
that's
great.
I'll
reiterate
it
I
think
it's
a
great
editor
for
a
specific
use
case.
My
I
just
don't
think
long
term.