►
From YouTube: JupyterLab Team Meeting - April 20, 2022
Description
A meeting to share and discuss features, ideas, issues, and pull requests in JupyterLab and other Jupyter frontends. This meeting is open to anyone and everyone.
Join future calls via the Jupyter community calendar: https://docs.jupyter.org/en/latest/co...
Notes for upcoming meetings can be found on the agenda: https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg
Past notes can be found on the JupyterLab team compass: https://github.com/jupyterlab/team-compass/issues?q=is%3Aissue+label%3A%22Dev+Meeting+Minutes%22
A
All
right
welcome
everyone
to
the
april
20th
jupiter,
lab
weekly
call.
Today
we
currently
have
15
people
on,
but
I
bet
more
people
will
show
up
and
if
you
just
joined
the
call,
please
check
out
the
meeting
minutes
in
the
chat
and
add
your
name
to
the
attendees.
A
If
you
like
and
add
a
bullet
point
in
the
agenda,
if
there's
something
you'd
like
to
talk
about,
if
you
have
something
to
talk
about
that
will
take
more
than
roughly
five
minutes,
please
add
it
at
the
bottom
to
the
additional
discussion
section
so
that
we
can
spend
more
time
on
it
at
the
end
of
the
call,
and
before
this
call
ends,
I
will
stop
the
recording
in
case
there
are
short
announcements
that
you
want
to
make
that
don't
belong
posted
in
perpetuity
with
that,
let's
get
started
so
the
first
person
on
the
agenda
today
is
isabella.
B
Yeah
isabella
who's
still
laughing
at
nick's
pun,
but
yeah
anyway,
hi
good
day.
Whatever
time
it
is
for
you,
I
just
have
my
usual
kind
of
announcements.
One
last
week
we
were
like:
where
are
the
recordings
for
the
these
meetings?
How
do
we
get
them
to
be
places
where
they
are
actually
kept
us
they're
all
on
youtube?
Now
I
think
up
to
today.
Obviously,
so
I
don't
know
that
we
have
a
process
that
we
want
to
do
for
that
in
the
future.
It's
not
a
hard
thing,
it's
just
very
manual.
B
So
just
bringing
that
up
is
I
I
don't
know
what
we
want
to
do
again
doing
it
in
a
batch.
Wasn't
too
bad,
but
I
don't
know
I
don't
know
what
else
to
say,
I'm
just
pointing
out
that
this
will
be
a
problem
again
in
the
future,
but
for
now
there
is
something
happening
so
yeah,
that's
cool.
B
We
also
have
april's
jupiter
community
call
next
week,
it's
at
a
slightly
different
time,
I'm
assuming
slightly
earlier
for
most
people
because
we're
trying
to
dodge
various
still
daylight
savings
meetings
have
converged
and
removed
all
normal
windows
that
we've
had
for
jupiter
community
calls
in
the
past
I'm
trying
to
resolve
this
long
term.
I
don't
know
what
to
do
honestly.
Just
so
you
know,
so
this
upcoming
one
will
probably
be
painful
for
anyone
in
pacific
time,
but
hopefully
that's
still
good
for
everyone
else.
B
I
know
we
get
a
lot
of
people
in
time
zones
where
it's
later
so
I
figured
it
was
better
to
go
a
little
earlier,
but
yeah.
We
have
that
and
of
course,
if
you
haven't
heard
about
this
sorry,
my
usual
spiel,
it's
like
a
show-and-tell
and
celebration
of
things
across
the
jupiter
community.
You
can
share
anything.
You
want
something
you've
made
something
other
people
have
made.
That's
my
kickoff
ask
me
for
more
questions.
If
you
want,
and
finally
the
jupiter
lab
accessibility
meeting
will
take
place,
15
minutes
after
this
one.
B
Yes,
I
don't
think
I
have
more
to
say
about
that.
Everyone
is
also
welcome
there.
So
yeah
thanks
any
questions.
B
B
I
don't
know
if
we
want
to
not
have
any
specific
people
they're
likely
to
be
there
for
the
foreseeable
future,
so
I
you
know
actually
I'll
paste
that
I
have
a
poll
on
twitter
right
now.
If
there's
like
a
cadence
thing
that
we
should
change
like
I
don't
know,
we've
been
having
like
some
months
where
things
are
really
packed
and
somewhere
they
aren't.
So
I
was
seeing
I'll
link
that
yeah.
C
Hey
everybody,
so
lots
of
announcements
on
my
site.
We
did
a
release
of
patch
version
for
3.3,
I'm
still
merging
lots
of
backward
pr
for
3.4
the
latest.
That's
missing
the
cell
toolbar,
because
it's
introducing
new
packages.
I
was
waiting
for
that
one
to
be
the
latest
before
releasing
should
come,
I'm
still
fighting
with
some
update
of
snapshots,
and
hopefully
I
will
do
that
by
tomorrow.
I
think
then
another
announcement
we
have
discussed
like
two
weeks
ago.
C
I
think
now
that
we
need
a
specific
discussion
about
introducing
the
toolkit
toolkit
in
jupiter
lab,
and
this
is
going
to
be
a
discussion
this
friday
on
april
22.
I
hope
the
the
time
is
correct.
I
think
that's
correct.
It's
8
30
a.m,
pacific
time,
but
I
linked
the
event
so
that
everybody
can
check
in
this
time
zone
what
what's
the
correct
time.
C
So
that's
all
for
the
announcement
and
also
last
week
we
discussed
about
mardon,
parser
and
probably
first
step
for
that
discussion
is
to
get
some
reference
test
for
that.
So
I
started
the
pr
on
the
jupiter
benchmark
repository
for
now.
C
I'm
downloading
the
test
suit
from
github
flavor
command
mark
and
I'm
testing
those
tests
against
nbconvert
and
jupyterlab
renderer.
Most
of
them
are
fading,
but
yeah.
That's
for
a
start-
and
I
put
the
same
bullet
points
for
discussion,
because
if
we
have
time
I
think
it's
we
could
discuss
that
a
bit
more,
but
it's
gonna
take
more
than
five
minutes.
So
I'm
stopping
there.
A
This
is
really
helpful,
so
I
think
maybe
one
good,
I
think
the
lowest
common
denominator
that
came
out
of
last
week's
markdown
conversation
was
at
the
bare
minimum,
even
if
we
had
no
spec
or
anything
having
a
comprehensive
test.
Suite
is
really
helpful.
So
thank
you
for
working
on
this
any
comments
before
we
move
on.
A
D
You
know
I
thought
there
was
a
lot
of
people
for
me
all
right,
so
those
of
y'all
that
are
watching
along
at
home.
If
you've
used
the
jupiter
lab,
shared,
editing,
collaborative
editing
experience,
then
you
have
been
using
the
probably
been
using
the
built-in
document
provider
which
uses
the
python-based
websocket
server
that
implements
the
webrtc
or
that
implements
the
yjs
protocol.
There
is
another
one
called
y
webrtc
and
it
allows
you
to
use
the
webrtc
spec,
which
is
a
peer-to-peer
spec
that
has
a
signaling
server
step
up
front.
D
Basically,
you
don't
have
to
give
someone
else,
the
login
to
your
jupyter
server
and
you
can
still
work
on
documents
together.
So
two
kernels
end
kernels,
whatever
things
get
kind
of
weird,
but
you
don't
have
to
share
kernels
if
that's
even
possible
in
certain
circumstances,
we
have
wrapped
that
up
inside
of
a
package
we
used
to
have
it
embedded
inside
of
jupiter
light.
D
We've
now
pulled
that
out,
it
doesn't
import
any
jupiter
light
stuff,
so
we're
just
going
to
do
a
release
of
it,
and
you
know
if
freaky
people
want
to
try
and
install
it
they'll
be
able
to
so.
It
is
a
further
adventure
into
the
webrtc
and
jupiter
rtc
infrastructure,
stuff
that
you
know
you
can
try
out
things
now,
because
it's
modular,
we
don't
have
to
wait
for
everything
to
land
in
core
for
things
to
be
different,
so
I
haven't
deployed
yet
but
looking
forward
to
it.
A
D
That's
fine!
It's
not
it's
not
about
ego!
It's
about
it's
about
damage,
control
and
what
we're
concerned
about
is
that,
like
it's
built
on
a
on
a
nest
of
evolving
web
standards
that
happened
to
work
today
right,
we
think
they're
going
to
keep
working
in
perpetuity,
but
we
don't.
We
don't
really
know-
and
you
know,
as
the
the
experience
with
angry
ass
people
that
come
in
from
try.jupiter.org
and
they're
like.
Why
did
you
break
my
beautiful
baby
like
man,
because
you
know
docker
containers
are
really
freaking,
expensive?
D
Okay,
you
know,
I'm
sorry
right
like
giving
away
free,
compute's,
really
expensive,
so
there's
levels
of
expectation
of
core
jupiter
products
that
we
do
not
really
feel
like
light
needs
to
wants
to
should
yet
fulfill.
That
is
all
so.
Nobody
is
claiming
ownership
on
it.
People
are
already
building
stuff
on
it.
We
just
don't
want
to
make
it
somebody
else's
problem.
Yet
I
guess
is.
That
is
the
issue.
A
But
hey
that's
totally
fair,
but
just
know
when
you're
ready
you'll
be
welcome,
how's,
that
okay
cool
gabriel,
you
are
up.
E
Hello,
so
this
is
just
real
quick.
I
have
been
working
on
pr
and
every
time
I've
tried
to
push
basically
on
this
pr.
E
I
end
up
with
running
into
this
step
this
issue
with
the
integrity,
script
and
the
repo-
and
I
don't
know
if
anybody
else
has
had
any
issues
with
this,
but
I
don't
want
to
turn
this
into
a
troubleshooting
session,
but
I
just
thought
I
would
put
it
out
there
and
see
if
anyone
wants
to
sidebar
with
me
or
something
or
or
I
guess
like
one
question
I
could
have
just
for
the
group
here
is
like,
since
I
keep
running
into
issues
I
nowadays,
I
just
kind
of
do:
get
push
no
verify
and
let
it
let
it
get
hub
handle
it
on
the
cpi.
E
If
that's
the
correct
thing
to
do,
I'm
happy
to
keep
doing
that,
but
anyway,
just
putting
that
out.
There.
C
F
I
run
into
issues
with
integrity
all
the
time
and
I've
just
found
com
like
I
use
condom
environments,
so
I
just
wipe
my
condom.
Environment
start
over
almost
always
fixes
it.
For
me,
that
is
a
bit
of
a
nuclear
option,
though,
depending
on
how
intrinsic
your
condo
environment
is.
E
A
So
yeah,
don't
don't
feel
bad
about
no
verify,
that's
solely
legit,
but
the
fact
that
this
is
annoying.
You
probably
indicates
it's
annoying,
others
who
haven't
said
anything,
so
I
hope
we
can
make
it
less
painful.
A
I'm
gonna
paste
into
the
chat,
a
script
that
relies
on
the
say,
command
on
mac
os,
but
you
could
remove
that
with
a
console
log.
But
this
is
my
nuke
jupiter
lab
script
from
inside
the
folder.
That
has
my
jupiter
lab
repo,
and
this
is
it
does
all
the
things
throws
away
all
the
old
things
and
it
throws
so
it
does
run
and
get
clean.
So
be
careful
about
that
because
it
does
get
clean
that
f.
A
D
Yeah
and
we
don't
even
run
things
with
real
compilers,
the
scipy
folks
do
crazy
stuff
and
they
have
50
different
scripts
and
they
are
trying
to
consolidate
all
those
down
into
one
unified,
developer,
workflow.
D
A
A
Is
there
perhaps
anyone
who
was
thinking
about
adding
an
agenda
item
or
we
can
jump
in
the
discussions
if
you
like,
but
we're
we're
running
ahead
of
schedule
for
change.
G
Jason,
did
you
have
this
first
yeah,
just
exactly
actually
both
of
the
things,
so
we
postponed
the
ipad
widgets
discussion
that
I
announced
last
week
to
this
coming
tuesday
april
26th,
all
the
information
is
there
I'm
glad
william
you're
happy.
I
think
pete's
also
able
to
be
there
then.
So
it
should
be
a
good
discussion
and
I'm
going
to
pycon
us
anybody
else
is
going.
I
think
a
few
people
responded
earlier
happy
to
meet
up
with
anybody.
A
G
G
A
Well,
if
you're,
if
you're
on
the
west
coast-
and
you
start
at
7
a.m,
maybe
you
want
that
half
hour
to
eat
something
so
okay,
oh,
I
have
lost
my
window
that
I
did
not
there.
It
is
okay,
cool.
A
G
Yeah
I
just
if,
if
you
want
to
meet
up
put
your
name
there
or
some
people
have
messaged
me
privately
happy
to
arrange
and
coordinate,
and
I
should
be
there
for
the
sprints.
So
that's
the
monday
and
tuesday
after
pycon
and
love
the
sprint
with
people
on
jupiter,
stuff,
cool,
great.
A
A
C
Just
bringing
the
chat:
okay,
that's
gonna,
be
messy,
so
the
the
guys
from
from
github
they
use
a
specific
command
mark,
github,
flavor,
markdown,
parser
and
and
they
are
using
a
test
shoot
that
is
display
like
as
this
text
file
and
basically
they
are
extracting.
C
They
are
extracting
examples
from
them
from
their
yeah,
so
the
the
the
file
can
be
rendered
directly,
but
it
contains
the
test.
So
that's
the
test
and
the
test
is
always
the
same.
You
get
the
markdown,
you
want
to
test
and
then
a
dot,
and
then
you
get
the
html
you
you
up
to
to
get
outside
of
it
and
they
provide
a
python
script
to
parse
that
to
be
able
to
extract
just
the
test.
So
that's
what
I
have
used
for
creating
the
the
test.
C
So
the
test
is
based
on
on
pi
tests,
so
so
what
I'm
doing
is
like
I'm
getting
that
github
repository
and
out
of
them,
I'm
extracting
all
every
task,
and
so
I
have
created
a
couple
of
test
files
for
now.
I've
created
one:
that's
testing
the
jupyter
app
renderer
against
the
that
reference
github.
So
the
test
is
what
what's
the
result
of
what
the
wrap
renderer
is
providing
versus
what
the
test
suite
has
as
a
reference.
C
Then
there
is
the
same
thing
about
nb
and
b
convert.
I
have
a
doubt
if
it's
the
right
function,
because
there
are
two
of
them,
there
is
another
one.
That's
called
markdown
to
html
pan
doc.
So
I'm
sure
it's
the
right
one,
but
that
can
be
changed
easily.
So
that's
the
same
comparison
and
the
third
test
is
comparing
jupiter
lab
versus
nb
convert.
C
So
that's
the
the
three
test
that
you
are
getting
everything
is
using
python,
although
for
jupiter
up
what's
happening,
is
that
I'm
using
playwright
so
priorities
that
it's
puppeteer,
but
like
the
next,
the
next
generation
of
it?
So
you
can
use
it
like
the
basic
libraries
in
typescript,
but
you
there
is
a
python
binding
and
so
that's
what
I'm
doing
and
basically
you
can
inject
javascript
to
evaluate
some
stuff
and
say
so:
that's
what
I'm
doing
for
testing
jupiter
app.
C
So
most
of
the
tests
are
broken.
That's
the
result
of
the
test,
that's
not
the
latest
test
because
I
probably
have
skipped
some
stuff.
Okay,
this
is
the
one.
C
So
out
of
like
2000
tests,
there
is
only
7
700,
passing
one
of
the
main
reasons
for
that.
It's
because
both
nb
convert
and
in
jupiter
lab
when
we
get
an
adding
we're
adding
an
id
and
an
anchor
what
the
the
reference
is
not
doing
so
there
are.
C
There
are
lots
of
corner
keys
and
stuff
like
that,
so
the
the
main
question
is
probably
like:
is
it
a
very
good
test
suit,
or
should
we
start
building
their
our
own,
and
even
for
those
things
like
nb
convert
is
not
building
the
same
sim
link,
then
jupyter
lab
so
dark
question.
So
what
what
should
like?
What
kind
of
comparison
is
valid
or
what
can
be
tolerable?
What
could
be
targeted
as
a
difference,
so
there.
G
My
question
is
de
facto
are:
we
are
we,
I
mean
since
you're
testing
against
the
github
flavor
markdown,
instead
of
just
plain
standard
con
common
mark
like
are
we
passing
the
github
flavored
markdown
tests
as
well?
No,
no!
We
are
not
just
gonna
work.
Okay,.
H
A
A
So
as
notebook
7
comes
out,
it'll
be
doing
the
same
with
markdown.
That
jupiter
lab
is,
and
I
think
it
presents
a
good
opportunity
for
us
to
also
make
sure
that
nv
convert
does
what
notebook
and
lab
do
with
markdown
I.e.
We
have
one
jupiter
set
of
markdown
features
that
we
support,
whether
that's
defined
in
a
spec,
whether
that's
defined
by
test
suite.
That
you
know
is
a
separate
question,
but
it
seems
fairly
straightforward
that
if
notebook
and
lab
are
doing
one
thing
and
we
convert
should
be
doing
that
same
thing.
A
I
know
this
is
easier
to
say
than
do,
though,
because
mb
convert
doesn't
apparently
render
mark
down
in
javascript.
But
yeah
have
you
thought
about
this
issue?
Do
you
have
any
insight
on
that
aspect
of
it,
because,
if
you're
going
to
go
through
the
trouble
of
creating
what
you're
working
on
right
now,
it
would
be
really
good
if
it
applies
to
multiple
jupiter
treatments
of
markdown
and
not
just
the
lab
version.
C
So
for
now
I
have
used
the
the
python
version
to
be
able
to
use
nb
convert
and
have
the
same
infrastructure
for
jupyter
lab,
but
as
I'm
using
playwright,
basically
as
soon
as
you
can
get
any
renderer
that
are
javascript
based
inside
the
web
page,
you
could
use,
you
could
use
the
same
same
code
or
something
similar
to
test
another
one
like
if
we
want
to
test
marked
on
it
or
stuff,
like
that,
shouldn't
be
too
complex
to
to
add
to
the
list.
A
What
what
do
you
and
by
you
I
mean
all
of
you,
not
just
friend?
What
do
you
think?
How
do
we
get
to
a
point
where
we
decide.
A
A
D
D
We
figure
out
that
they're
whatever
marked
down
right,
but
if
we,
if
we
actually
are
going
to
say
something,
we
would
want
to
go,
get
a
mime
type
for
that
right
and
it
would
be
a
more
limited
subset
than
missed,
because
missed
is
by
design
extensible
right,
you
can
go
download,
50
things,
so
you
would
basically,
I
think,
to
do
this
properly.
We
would
need
some
request.
D
D
D
I
that's
the
only
way
we
can
make
everybody
happy
right
and
I
would
I
would
even
consider
moving
math
out
of
that
baseline
and
making
that
something
that
you
have
to
require.
It's
been
it's
very
hard
right
because
math
has
been
the
the
inline
math
markup
has
been
part
of
the
contract
forever.
As
long
as
it's
been
marked
down,
but
it's
it's
so
hard
for
us
to
transition
anything
as
long
as
we
don't
give
a
place
for
people
to
declare
stuff
so
yeah
we
got
a,
they
got
a
link
on
that
is
not.
D
That
is
definitely
not
it.
We
talk
a
little
bit
about
this
on
one
of
the
issues
and
it
does
devolves
into
on
on
jupiter
lab
markup.
Where
we've
done
a
bunch
of
these
things,
we
it
devolves
into.
You
can't
write
a
parser
for
markdown
and
nobody.
Nobody
can
really.
You
can't
argue
that,
because
you
can't
write
a
parser
for
a
language
that
the
intent
is
that
you
can
never
break
it
right.
It's
always
going
to
show
you
something
it's
never
going
to
fail.
Parsing!
D
So
if
your
notebook
documented,
what
is
the
source
of
my
markdown
cells
and
that
would
be
no
longer
accurate,
it
would
not
be
a
markdown
cell.
It
would
be
a
markup
cell
that
that
would
give
people
that
way
that
if
you
really
care
what
your
thing
looks
like
at
the
end
of
the
day,
the
only
thing
you
can
do
is
send
that
back
to
a
server
and
have
it
you
know
laid
out
like
that.
You
can't
rely
on
the
browsers
to
do
this
stuff
for
us
right.
D
You
have
to
make
stupid
dead,
pixel
pictures,
that's
not
the
intent
of
many
notebooks
they're,
not
for
publication
they're,
not
for
preprint,
but
some
notebooks
are
so.
I
feel
like
trying
to
out
engineer
and
outspecify
it.
The
entropy
in
the
universe
is
not
gonna
win,
I'm
done.
A
A
It
seems
like
that's
just
completely
orthogonal
to
how
do
we
solve
the
like?
How
do
we
actually
a
make
sure
the
jupiter
front
ends
all
do
the
same
thing
b?
Other
people
can
reason
about
what
a
jupiter
notebook's
doing
so,
when
they're
implementing
their
front
ends.
They
also
do
the
same
thing.
H
And
I
think
my
comment's
just
the
same
as
last
time,
which
is
that
I
try
as
much
as
possible,
I
think
from
the
user's
point
of
view,
and
that
means
they
have
documents
and
they
want
them
to
look
the
same
in
a
lot
of
different
places
so
that
every
so
that
the
people
who
they
give
their
documents
to
are
happy.
H
So
as
an
example,
github
favorite
markdown
is
a
really
cool
thing.
Called
task
lists.
It's
kind
of
like
an
enumerated
list
with
little
check
boxes
and
I
think,
would
be
a
great
thing
to
have
in
jupiter
code
cells
as
well.
So
my
opinion
is
that
there
are
certain
extensions
that
I
think
would
be
very
likely
for
users
to
definitely
want
to
have
makes
sense.
H
You
you
know,
like
you,
might
want
to
put
a
to-do
list
in
a
homework
assignment
or
some
work,
you're
doing
and
then
github
is
pushed
there's
other
extensions
that
we
push
really
hard
like
math
formatting,
which
makes
a
lot
of
sense.
For
us.
There
is
a
cool
extension
that
nick
mentioned
last
week,
which
is
mermaid.js,
which
is
something
that
clearly
makes
a
huge
amount
of
sense
for
github
to
have,
because
it's
really
useful
for
technical
documentation.
H
But
I
don't
think
that
it
makes
a
lot
of
sense
to
invest
a
lot
of
energy
in
putting
that
in
jupiter.
So
I
think
I
think
that
it
would
be
really
nice.
If
you
know
there
was
some
discussion
and
some
you
know
you
know,
balance
based
on
what
how
jupiter
notebooks
are
different
than
say,
github
issues
versus
people
writing
books
in
markdown,
and
you
can
make
choices
about
which
extensions
should
really
be
prioritized
and
and
encouraged
for
all
jupiter
clients
to
have
that's
my
opinion,
at
least
what
it's
worth.
H
C
H
Yeah,
I'm
a
little
scared
of
the
test
suite
that
projects
proposing,
because
you
know,
if
you
put
a
huge
amount
of
effort
into
making
sure
all
5000
tests
pass,
but
then
there's
a
really
compelling
reason
to
switch
to
markdown
it
instead
of
marked
or
something-
and
it's
just
like
all,
the
output
looks
different,
but
I
mean
it
looks
the
same,
but
it's
different
html
that
produces
it.
That
might
be
a
strong
disincentive
for
somebody
to
make
that
change
to
a
different
markdown
parser.
H
G
If
we
were
a
new
project,
this
would
be
an
entirely
different
conversation,
but
we've
got
millions
and
millions
of
notebooks
out
there
that
people
assume
work
or,
and
maybe
at
some
level
they
realize
they
don't
work
the
same
across
different
renderers,
but
I
think
there's
a
broad
assumption
that
that
things
work,
but
you
know
nobody
knows
sort
of
where
we
are.
G
Intentional,
I
think,
is
the
first
step
and
then
figuring
out.
Okay.
What
do
we
want
to
change
from
here?
You
know:
do
we
want
to
adopt
get
help
flavor
mark
down?
Maybe
there's
an
assumption
that
we've
already
adopted
github
flavored
mark
down
in
some
ways
like
we
support
tables
and
and
whatnot.
Let's
just
make
it
intentional.
What
we've
already
done.
A
So
if
you
started
from
the
other
side,
the
what
if
we
were
just
designing
this,
it
sort
of
seems
like
what
we
want
is
github
flavored
markdown,
but
with
the
ability
to
add
things
like
ids,
because
we
use
that
in
the
application
for
say,
commands
and
also
with
latex
support
like
if
you
told
someone
that's
what
jupiter
offers,
they
might
already
think.
That's
what
we
offer
today
I
mean
we.
A
A
A
Yes,
that
that's
what
william
just
said
in
the
chat
is
accurate.
I
believe
yeah.
C
D
That's
true
and
that's
that
again
gets
to
the
point
like
you
know
why
even
push
mark
down
as
the
last
thing,
because
it's
this
lingua
franca
that
gets
implemented
in
a
bunch
of
places,
you
know
they're,
like
none,
do
the
social,
the
social
sites.
Don't
really
I
don't
care
about
the
social
stuff.
You
know
forget
about
them.
Okay,
the
point
is,
for
you
know,
semi-technical
type
setting
you
need
something
that
is
not
quite
html
right.
D
I
mean,
I
think
that
maybe
maybe
the
thing
that
we
would
have
is
not
rather
worry
so
much
about
the
input
but
have
a
formatter
right.
So
if
we
had
a
a
formatter,
a
formatter,
slash
linter
that
we
could
run
on
the
front
end
and
the
back
end
right
and
again,
we're
not
like
this
is
not
a
parser
for
the
thing,
but
if
we
could
make
some
comments
about
the
the
well-formedness
of
the
input
right
because
markdown
does
not
markdown
makes
no
claims
about.
You
know
what
how
what
you
think
goes
into
it.
D
D
I
don't.
I
don't
know,
I
don't
even
know
how
to
I
don't.
I
don't
know
how
to
effectively
talk
about.
I
think
we
should
support
as
much
as
markdown
as
we
can,
because
the
more
things
that
we
do,
that
move
away
from
that
reduce
our
ability
to
use
our
own
tools
to
help
build
jupiter
tools
so
from
from
my
perspective
like
if,
if
we
can
slam
out
something
in
a
notebook
and
then
paste
it
into
the
readme
on
github
and
that's
the
documentation
that
people
land
on,
I
want
that.
D
You
know
I
don't
want
us
to
have
to
relearn
another
diagram
syntax
in
order
to
document
what
jupiter
is
doing
and
you
know
or
or
adopt
some
big
old,
desktop
application
when
a
quick
mermaid
would
do
the
job.
So
there's
no
such
thing
as
invalid
markdown.
That's
right!
It
can't
be
wrong.
It
is
by
definition,
correct
because
when
it
falls
back
it
just
it
just
falls
back
to
plain
text.
D
You
know,
theoretically,
but
that's
tell
that
to
somebody
that
has
spent
hours
working
around
our
rendering
bugs
making
something
look
a
particular
way
inside
of
notebook
classic,
and
then
they
get
angry
when
it
doesn't
work
exactly
that
way
with
their
custom
css
that
they
patch
you
know
with
some
powershell
script,
or
you
know
like
the
insanity
of
making
a
claim
about
the
dom
architecture
that
comes
out
like
dom.
We
could
do.
We
could
say
this
is
jupiter
dom.
D
D
Right,
you
know,
is
all
the
stuff
that's
going
into
it,
generating
good
stuff,
but
we
already
know,
for
example,
that
markdown
cells
do
not
naturally
create
document
sections,
which
is
what
you
would
expect
an
accessible
document
to
give
you.
D
So
if
you
go
to,
you
know
the
the
table
of
contents
in
a
generated
pdf
that
you
download
from
a
government
website.
Those
sections
are
actually
like
marked
inside
of
there,
so
that
your
screen
reader
can
actually
go
in
and
tell
you
this
header
belongs
to
that
section,
and
you
cannot
do
that
markdown.
D
C
The
the
thing
also
is
like
the
test
suit,
like
that
I've
used
is
really
it's
a
lot
of
tests
and
they
are
really
tricky
one.
So
one
question
that
we
may
have
is
like:
are
our
user
like
do
our
user
use,
that
kind
of
very
tricky
markdown
or
or
do
we
want
to
just
have
a
test
suit?
That's
fulfilling
simple
stuff
like
because
the
test
shoot
like
most
of
the
errors
you
you
will
see
is
like
when
you
use
tabulation
tabulation,
maybe
con
transform
in
space
or
not
in
space
or
stuff.
C
Like
that,
that's
the
kind
of
thing
the
the
test
suite
is
testing
and
it's
maybe
something
we
don't
care
so
much
as
to
say.
Okay,
those
tests
are
tests
that
we
want
to
to
render
in
that
way,
and
that's
fine
if
they're,
not
exactly
that
like
because
you
have
few
space
instead
of
tabs,
so
maybe
like
the
first
step
would
be
to
to
really
define
what
the
test
suit
we
want
to
to
fit,
and
maybe
it's
not
like
that
very
long
list
of
tests
for
common
mark.
G
But
I
think
we
have
so
many
people.
I
guarantee
that
ev
somebody's
using
every
corner
case
out
there.
Well,
okay,
the
assumption
is
that
many
people
many
times
you'll,
find
somebody
using
a
corner
case.
And
so
then
the
question
is:
what
happens
when
we
break
the
space
bar
heating?
You
know,
is
it
on
them,
or
is
it
on
us
to
fix
that
and
if
there's
no
defined,
it's
not
a
clear
responsibility
for
us
in
api
compatibility
and
expectations
around
releases
etc
versus?
G
If
we
have
a
standard
that
we
can
say
like
this
is
what
we
support.
Then
it
becomes
much
clearer.
G
C
G
H
Just
because
they
have
iterated
so
much
with
real
users,
they're,
like
very
user
focused
as
a
company,
so
I
tend
to
think
they
might
be
a
better
model
than
common
mark
because
they're
just
a
huge.
You
know
millions
of
people
using
it
and
complaining,
and
then
it
gets
better
yeah,
okay,
sure
at.
A
G
It
is
the
the
ietf
draft
that
I
posted
said
it
was
based
on
the
original
markdown,
not
on
common
mark.
That's
my
understanding
or
or
is
that
draft
wrong
or
old
or
whatever?
Is
it
explicitly
based
on
common
work.
C
G
H
H
G
I
think
a
good
next
step
would
be
look
at
the
test.
Failures.
Frederick
thinks
we're
doing
that
work
and
try
to
classify
those
failures
as
unintentional
I.e.
We
should
find
an
implementation
that
fixes
those
or
acknowledge
those
as
bugs
intentional,
where
we
can
have
a
debate
about.
Do
we
want
to
keep
this
as
part
of
the
standard
and
obviously
passing
you
know:
do
we
want
to
keep
those
as
pas?
The
passing
test
is
passive.
G
A
A
Do
you
think
this
can
end
up
being
part
of
the
jupiter
stand
like
a
thing,
a
document
or
repo,
something
that
we
can
point
people
to
and
say
here
we
go.
We
thought
it
through.
This
isn't
a
spec,
but
it's
a
functional
definition
or
something
yeah.
I.