►
Description
In this call, we meet with Brett Walker, Senior Backend Engineer in Plan: Project Management to talk about the following topics:
- A brief introduction to the Content Editor.
- How GFM is rendered in the backend and what are the current challenges.
- Updating our commonmarker dependencies to provide inline source maps in the Markdown API.
- Rendering GFM in the client
A
A
A
A
A
What
we
are
building
now
is
pretty
much
we
segue
gator
to
allow
it
in
flat,
flavor
markdown,
you
know
like,
without
without
wisdom,
experience
we're
gonna.
I
have
the
continuator
open
here
and
that's
basically
it
like.
We
have
some
goals
in
the
development
of
the
continuator,
ux
goals
and
and
product
goals.
One
of
them
that
is
very
important
for
us
right
now
is
that
we
want
to
have
an
explanation
experience
that
still
allows
a
user
to
type
somewhere
down.
B
A
Besides,
that,
we
have
like
more,
like
the
more
usual
appreciating
tools
where
you
have
like
the
toolbar,
and
then
you
can
select
text
a
market
as
bold.
We
have
like
some
complex
editing
tools
for
tables.
That
is
like
one
of
the
main
pain
points
of
using
gfm,
where
you
can
insert
a
table
right
here,
insert
columns
and
rows.
A
A
So
we
are
aspiring
to
be
a
at
the
default
editing
experience
for
markdown
in
the
github
application.
However,
we
acknowledge,
like
from
a
lot
of
feedback,
that
there
is
a
a
great
amount
of
users
who,
with
referrals,
actually
writing
markdown
directly
in
the
source.
So
we
don't
want
like
to
remove
the
source
sighting
that
just
like
provide
this
choice,
that
if
you
want
to
use
a
visualizator
you
can
you
can
do
it.
C
Yeah,
I
was
just
I
was
wondering
if
there
are
any
plans
to
enhance
the
the
text,
editing
experience.
So,
for
example,
you
know
you're,
you're,
you're,
building
a
list
and
you
hit
enter
and
it
builds
the
next.
The
next
item
in
the
list
you
know
automatically
puts
the
mark
down
for
text
setting.
I
understand
that
it's
probably
there
for
the
ones.
A
A
B
Yeah,
so
we
don't
convert
mark
down
to
html,
we
just
send
it
to
back
end
and
back
and
converts
it
to
html,
and
then
html
is
actually
converted
to
the
pros
mirrors,
json
format
that
is
used
to
render
the
whatever
content
you
see
on
content
editor
and
when
you
try
to
save
it
again
it
it
is
converted
back
to
markdown
using
closed,
mirror
markdown.
It's
a
it's,
a
library
that
sits
on
top
of
rosemary,
and
it
has
some
of
its
own
extensions.
B
We
just
we
are
adding
our
own
extensions
on
top
of
it
like
to
serialize
custom
elements
like
tables
and
get
lab
references,
and
all
that
we
already
have
this.
We
already
had
this
in
our
codebase
for
about
three
years.
We
are
already
using
it
for
paste
as
markdown
feature.
So
whenever
you
copy
something
anything
inside
like
anywhere,
you
try
to
paste
it
inside
the
any
text
box
in
gitlab.
It
will
convert
everything
into
markdown
and
then
paste.
It.
A
So
yeah,
that's
that
that's
pretty
much
the
process
and
present
recently
something
that
that
we
know
that
is
a
a
big
problem
is
that
when
we
try
like
when
we're
using
the
content
editor
well,
let
me
share
my
my
screen
again
and
if
you
save
this,
this
content,
the
container
which
here
is
marked
down
from
scratch.
So
if
you
are
like
editing
an
existing
wiki
page
with
some
formatting,
this,
like
formatting
preferences,
that
the
content
directory
is
not
adopting
the
contenator
could
just
like
rewrite
all
of
those
formatting
preferences.
A
B
B
So
let's
say
you
have
a
huge
page
of
markdown
content
and
you
just
change
one
little
paragraph
in
there
and
you
you
realize,
with
the
current
content,
it
will
reformat
the
entire
document.
It
will
forget
all
your
line
breaks
your
list
list
style
types
like
all
your
preferences
are
gone
is
going
to
format
the
entire
page.
It's
probably
not
the
way
you
want
it,
so
I
use
source
position
to
figure
out
that
whether
the
markdown
that
was
that
existed
previously
is
the
same
as
the
markdown
that
was
rendered.
B
A
Yeah-
and
that's
that's
one
of
the
reason
brett
that
we
wanted
to
to
talk
with
you,
because
we
are
relying
on
the
source
map
annotations
that
are
coming
in
the
html
output.
However,
we
notice
that
there
are
parts
of
that
html
that
are
not
annotated,
because
the
version
of
common
mark
that
we
are
using
right
now
doesn't
have
annotation
for
for
mark.
You
know
like
for
inline
content,
like
all
texts.
A
And
we
were
thinking
like.
Why
are
we
not
updating
the
our
common
mark
version
to
include
that,
because
now
there
are
newer
versions
of
common
mic
that
provides
source
mapping
for
for
inline
elements,
yeah
that
that
part
of
the
obviously
of
this
of
this
call
like
asking
questions
about
efa
implementation
comes
now.
So
do
you
have
like
any
questions
read
about
what
we've
talked
so
far
about
the
content
directory.
C
No,
actually,
you
covered,
we
covered
most
of
things
and
the
and
that
the
pros
mary
does
operate
completely
on
the
json
and
then
it
and
then
you
convert
it
back.
So
that's
that's
pretty
cool
about
doing
just
saving
the
changes
at
the
block
level.
That's
that
preserves
quite
a
bit
in
the
market.
So
that's
cool.
C
C
Yeah,
that's
true,
it
could
have
been
turned
on,
but
we
we
use
it
in
some
other
places
as
well
in
the
code.
So
we
actually
use
that
to
help
track
down
which
which
individual
to
do
items
being
clicked,
so
that
we
can
only
update
that
in
the
markdown
without
re-rendering
the
whole
the
whole
page.
So
we
we.
Actually,
we
do
utilize
as
well.
A
That's
a
that's
a
night,
a
nice
point,
you
know,
so
I
I
I
sure
read
that
as
well.
There
are
acrylic
forge
to
mark
down
that
we're
working
with
the
ux
from
the
foundation
team.
So
now
the
way
that
we
display
markdown
is
not
specified
in
our
design
system
and
we
are
working
with
them
on
creating
a
specification
as
a
markdown
type
scale.
To
make
it
look,
you
know
not
only
look
better
but
from
an
accessibility
point
of
view
also
like
make
it
easier
to
to
consume
for
for
users.
A
A
C
I
I
can't
tell
you
exactly
why,
because
that
was
that
existed
before
I,
I
even
got
on
board,
but
you
know
we
used
to
use
red
carpet
for
our
for
our
markdown
back
when
I
joined,
and
there
was
a
already
a
small
effort
that
I
helped
accelerate
a
little
bit
to
use
switch
to
common
mark,
which
is,
you
know,
very
well,
specified,
very
well
tested
out
and
all
that
stuff,
it's
still
young,
but
it's
a
it's
a
good
base.
Github
of
course
uses
it.
C
They
rebased
on
that
as
well
before
we
didn't,
but
I
mean
the
one
part
you
can
say,
but
for
the
pipeline
you
know
we
we
have
to
be
able
to
add
filters.
We
have
to
be
able
to
take
whatever
the
the
the
basic
render
does
and
apply
a
variety
of
changes
to
it.
Right,
that's
and
that's,
basically
what
the
pipeline
gives
us.
It
gives
us
a
set
of
filters
for
any
pipeline
and
allows
us
just
to
go
through
it
and
okay.
We
need
to.
We
need
to
handle
external
links.
C
We
need
to
handle
images
so
that
they're
lazy
loaded.
We
need
to
do
all
our
references
and
go
through
all
those,
so
it
gives
us
a
linear
way
to
really
go
through
and
do
that
not
that
there's
there's
probably
not
some,
certainly
some
optimizations-
that
we
need
to
keep
putting
in
there
and
we
do,
but
so
far
that's
it's
worked
out
pretty
good.
A
C
You
know
the
biggest
challenge
right
now
is
is
references
and
because
they
they
really
they
need
access
to
the
database.
You
need
to
know
if
what
the
what
the
title
is
for
for
this
thing,
you
need
to
know
what
project
and
all
this
you
need
to
be
able
to
resolve
some
of
that
stuff
out
as
well
as
redacting.
C
So
we
can't,
we
can't
show
confidential
information
to
a
user
that
doesn't
have
access
to
it
so
when,
when
they
put
a
reference
in,
if
they
don't
have
access
to
that
reference,
they
can't
see
the
title
of
it.
They
can't
see
any
information
about
it.
It's
just
a
dead.
You
know
it's
just
text
and
that's
a
that's
a
real,
that's,
a
real
critical
thing.
C
So
that's
that's
been
a
big
set
of
challenges
and
then,
of
course,
adding
you
know
it's
easy
for
us
to
add
additional
features
that
that
we
can
that
don't
need
to
be
parsed
at
the
markdown
level,
for
example,
our
block
quote
structure
or
something
else
or
the
way
we
handle
image
tags
is
audio
and
video.
If
we
were
to
add
a
new
language
construct,
then
that's
more
difficult
and
we
actually
ran
into
an
issue
with
that
recently,
where
that's
in
handling
escaped
markdown.
C
C
C
C
Basically,
had
we
had
to
pre-process
the
markdown
run
it
through
the
run
it
through
the
the
common
mark
render
and
then
pre-process
it
again
looking
for
these
special
sequences
so
that
we
could
escape
a
hash
sign
so
that
we
could
later
know.
Oh,
this
was
originally
escaped.
We
need
to
ignore
it
as
a
reference.
A
Exactly
and
that
that's
something
that
I
noticed
while
I
was
reading
the
the
pipeline,
so
we
are
like
taking
some
constructs
like
preferences
and
the
syntax
that
we
use,
define
them
and
like
they
are
coming
like
like
from
the
markdown
parser.
As
you
know,
like
aspects
putting
a
paragraph
and
then
we
are
like
extracting
that
from
the
html
and
actually
processing
the
reference
right.
C
A
Like
did
the
team
that
work
on
on
maintaining
this
pipeline,
you
know
like
consider
to
to
extend
the
the
markdown
partial
in
the
in
the
same
way
that
github
extended
common
mark
to
support
those
expect
special
synthesis.
I
know
that
is,
it
is
very
challenging
and
it
makes
sense
not
to
do
it
if
there
is
an
easier
way.
C
Well,
the
the
you
know,
there's
there's
several
challenges
to
that.
One
is
the
the
common
mark.
C
mark
is
written
in
c,
so
you're
you're
going
to
be,
then
writing
additional
extensions
to
c
in
c
in
order
to
provide
that
and
from
experience
extending
the
parks
down
marker
with
the
new
language
project.
It's
it's.
It's
not
trivial,
that's
not
true!
C
C
C
A
This
is
kind
of
a
tangential
question,
but
you've
been
following
the
common
market
spec
for
a
while.
How
often
do
they
add
new
support
for
new
features
like
is
that
something
that
happens
often
like
table
sand
and
dust
leasing
in
gfm
has
existed
for
a
while,
and
they
haven't
included
that
in
commonwealth.
Yet.
C
No,
the
the
problem
with
the
common
mark
spec
is
it's
it's
a
very
slow
process
which
has
frustrated
me
as
frustrated
other
people
too,
and
partly
they're,
focusing
on
the
real
core
of
markdown
and
having
that
fully
specified
and
the
extensions
piece
tables
to-do
lists
those
kinds
of
things
they
still
consider
as
extensions
and
they
haven't
they.
You
know
everybody's
always
proposing.
Why
can't
we
have
it
do
this
and
why
can't
we
have
it?
C
B
Okay,
yeah
one
more
thing
about
the
table
thing
is
that
there's
there's
not
there's
a
couple
of
table
implementations
and
if
they
move
forward
with
one
so
one
kind
of
table
implementation,
the
other
other
people
who
use
the
other
table
implementation
like
the
markdown
eight
tables,
they
would
complain.
Hey
this.
Our
implementation
is
better.
Why
you're
not
picking
our
implementation
over
this
implementation?
C
C
A
I
wouldn't
I
don't
know
if
we
could
say
stale
or
it
is
like
it
has,
it
is
like,
like
it
hasn't,
been
updated
to
the
latest
contributions
to
the
to
the
mark
implementation
that
has,
among
other
things
like
source
map
for
inline
elements
and
we're
relying
on
that,
and
we
have
like
the
same
problem
as
a
result
like
we
don't
have
like
we
are
not
getting
receiving
these
updates
from
from
common
mark.
So
what
do
you
think
about
this
situation?
C
C
C
B
So
either
this
is
already
included
in
gfm
and
it's
turned
off
by
default
and
we
don't
know
about
it.
If
that
is
the
case,
then
that's
great.
We
just
need
to
turn
it
on
and
maybe
like
pass
an
extra
query
parameter
and
we
can
turn
on.
I
think
it
needs
some
parameters
like
it
needs
type
format,
type
to
be
xml
and
you
need
to
enable
source
positions
explicitly.
C
B
B
A
A
B
B
B
Yeah,
so
my
concern,
my
question
is
mainly
like
first
question
is:
is
it
already
there
in
gfm
cmr
gfm,
if
yeah?
If,
yes,
then,
then
I
think
we
just
need
to
get
see
mark
see
the
the
ruby
library
common
marker
to,
like
maybe
add,
support
for
enabling
this
yeah,
so
that
so,
in
this
case,
like
most
of
our
work,
is
already
done.
B
C
It
is
based
on
the
on
the
zero
two
nine
version
of
of
c
mark
as
far
as
as
far
as
I've
found,
I
you
know
I'll,
look
at
it
again
once
we
get
off
here.
So
my
question,
though,
is,
do
you?
Do
you
really
need
the
text
node?
The
key
seems
like
part
of
the
key.
Is
that
as
long
as
the
the
bold
tag
and
the
emphasis
tag
and
stuff
like
that,
have
source
position
attached
to
them,
then
you
may
not
need
then
everything
else
falls
out
as
text.
Basically
right,
yeah
does
everything
else
around.
B
A
C
All
right,
I'll
I'll,
I'm
sure
you
will
too
but
I'll
look
more
into
the
inline
source
stuff
and
see
where
we're
at
with
and
see.
If
I
can't
poke
those
guys
to
start
moving
forward.
If
we
need
to,
I
mean
I,
of
course
we
could
always
fork
off
of
it
and
start
doing
that.
That
was
always
a
consideration
early
on
and
maybe,
if
they're
not
moving
it
forward
and
putting
fixes
in
them.
Maybe
we
need
to
do
that
so
we'll
have
to.
B
A
A
For
that
cool,
so
let's
jump
to
the
to
the
next
question.
So
obviously,
after
finding
those
those
requirements
and
like
wanting
to
use
a
source
position
for
inline
elements
and
seeing
how
they
did
the
gfm
brick
is,
we
were
wondering
like.
Oh
maybe
we
can
implement
gif
a
gitlab,
flavor,
markdown
trender
in
the
client
and
right
and
it
there
are
other
benefits.
A
Besides
source
positioning
like
it
could
be
a
huge
performance
wins
when,
like
we
are
just
like
moving
the
the
entire
trading
process
with
a
client.
However,
I
know
that
that
there
are
challenges
that
there's
like
big
challenges,
and
I
know
that
preferences
is
one
of
them
and
I
was
wondering
where
are
your
thoughts
on
it?
C
Yeah
we
we
have
thought
a
little
bit
about
it.
I
mean
some
of
the
big
challenges
is
what
I
mentioned
before
is
the
database
access
and
you
know
dealing
with
the
references
dealing
with
redaction,
so
those
those
have
to
be
handled
you
would,
you
might
have
to
then
still
query
into
the
into
the
back
end
to
resolve
those
issues.
C
C
A
Pre-Preprocessing
step
for
the
markdown.
Imagine
that
we
take
a
martin
file
american
source
file
and
we
find
the
reference
definitions
within
the
markdown
and
we
just
convert
them
into
urls.
If
a
user
has
access
to
that
information
and
then
we
move,
we
send
that
mark
down
source,
and
you
know
they
we
don't
have
to.
We
don't
have
to
do
reference
processing
in
the
client,
because
those
references
were
pre-processing
the
back
end.
However,
the
bike
that
was
not
rendered.
C
C
A
A
C
C
B
B
Javascript
is
definitely
going
to
be
slower
than
c,
but
the
performance
benefit
would
be
moving
the
stuff
to
the
front
end
like
offloading
that
stuff
that
the
backend
has
been
doing.
Let's
say
if
you
have
a
2mb
file
right
now,
it
gives
you
a
like
500
error,
but
if
you
like
offload
it
to
the
front
and
then
do
it
in
batches,
it's
still
possible
to
render,
depending
on
what
kind
of
computer
the
person
has.
C
C
We
are
moving
to
to
using
the
c
version
of
the
renderer
which
we're
not
today,
because
we
had
a
when
we
did
the
conversion.
There
was
a
a
mismatch,
so
we
used
the
ruby,
render
and
common
marker,
but
that's
slower,
so
we're
actually
we're
actually
working
on
on
fixing
that
so
that
we
can
use
the
c
render.
C
But
there's
a
there's
a
bug
in
how
they
and
how
they
render
some
of
the
code.
So,
like
I
gotta
I
gotta
track
down
exactly
whose
problem
it
is,
whether
it's
common
marker
or
cmark
or
spec,
but
that's
some
progress,
so
that
should
actually
be
a
huge,
a
big
win
on
performance,
at
least
from
the
back
end.
So.
A
C
You
know,
mark
markdown
is,
is
a
common
mark
compliant
the
there's,
a
reference
implementation,
js
representation
of
common
mark
itself,
markdown
that's
got
various
gfm
extensions
and
all
that
kind
of
stuff.
So
there's
that
it's
not
as
it's
still
not
as
fast
as
the
c
version,
but
it's
it's
pretty
optimized,
though
it
can
be
a
pain
to
extend,
there's,
also
a
ruby
version
of
mark
dunnett
that
reported
from
javascript
to
ruby,
but
that's
that's
even
slower,
there's
also
titus
warm's
new
new
one
called
micro
mark.
C
A
C
C
B
C
But-
and
you
know,
if,
if
you
never
go
edit,
that
comment,
it
doesn't
change
except
in
one
condition
where
we
update
the.
We
can
break
the
cache
system
wide.
So
when
we
have
security
problems
and
stuff
like
that,
then
we
can
or
or
advancements
that
we
need
to
get
into
everything.
Then
we
bust
the
cash
system
wide
and
when
you
load
it,
then
it
gets.
B
I
mean
when
the
person
is
trying
to
edit
his
comment.
We
would
want
to
burst
the
cash
off
like.
Maybe
we
fetched
the
preview
at
that
time
again.
So
when
you
fetch
it
again,
we
would
want
to
post
the
cash
and
fetch
the
fresh
content
so
that
when
you
enable
the
inline
inline
source
position
feature
which
is
which
we
just
discussed,
that
is
already
there
and
see
mark.
C
A
C
C
So
that's
that
html
is
served
up
after
running
through
our
redaction
process
that
make
sure
that
there's
no
confidential
information.
So
so
every
time
we
display
it's
not
that
we're
we're
running
this
whole
bonsai
thing
every
time.
It's
it's
it's
just
in
those
cases
where
the
cat,
where
that
cash
has
been
busted.