►
From YouTube: JupyterLab Team Meeting - April 13, 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/community/content-community.html#jupyter-community-meetings
Notes for upcoming meetings can be found on HackMD: 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,
everyone
welcome
to
the
april
13th
jupiter
lab
weekly
call.
Today
we
have
15
people
on
the
call.
Hopefully
more
will
come
as
we
progress,
but
for
now
why
don't
we
get
started?
B
Hey
guys,
so
there
are
lots
of
bullet
points,
but
mainly
announcements,
so
the
czi
call
for
the
fifth
front
of
open
source
support
is
due
in
a
week,
so
I
plan
to
submit
the
letter
of
intent
for
the
notebook,
tryptophan
maintenance
and
documentation
by
friday.
So
there
is
the
link
for
that
letter
of
intent.
If
you
want
to
bring
some
additional
comment
or
whatever
like
there
is
still
a
couple
of
days
left
so
feel
free
to
do
so.
B
B
So
currently,
on
the
tree,
dot
x,
jupiter
lab.
If
you
have,
I
think,
it's
more
than
50
cells
in
a
notebook.
The
additional
cells
are
not
rendered
directly
they're
rendering
his
debate.
That
does
bring
a
lot
a
couple
of
issues,
let's
say
so.
The
pr
that
eric
has
done
is
removing
that
features
by
default
and
moving
it
behind
configuration,
and
so
the
question
of
eric
was:
should
it
be
backported
to
3.3.x,
or
should
it
be
part
of
3.4?
B
I
think,
as
it
will
change
the
way
the
notebook
is
rendered
for
a
user
that
that
have
big
notebooks.
It
will
be
probably
better
to
to
make
it
part
of
3.4
rather
than
a
batch
release
of
3.3.
B
B
Then
next
it's
a
couple
of
pr's
that
I
have
that
will
be.
It
would
be
nice
if
somebody
can
have
a
look
and
review
them,
especially
the
first
one,
because
it's
like
a
month
old
waiting
for
review.
So
I
would
appreciate.
B
And
then
I
just
I
will
skip
to
the
last
element,
so
I
will
do
the
3.3.x
release
tomorrow.
I
it
will
depend
on
the
answer
of
the
backboard
for
eric
pr
and
then
in
just
after
it.
I
will
create
the
3.4.x
branch
and
I
will
release
the
first
version
of
3.4.0
as
a
reminder:
the
eta.
It's
a
to
do
a
release
by
by
the
end
of
the
month
of
3.4.0,.
B
C
B
C
I
can
look,
I
have
to
look.
I
have
to
move
community
calls,
I
think
so.
I
can
put
that
on
my
calendar
list
and
I
can
just
choose
something
and
let
you
know,
and
then
we
can
move
it
does
that
work.
A
I
was
going
to
ask
you
guys
if
anyone
wants
to
do
a
review
matching
donation.
If
you
volunteer
to
review
one
of
these
three
pr's,
I
will
volunteer
to
review
one
of
the
remaining
two.
A
Okay,
awesome,
since
you
took
one
of
the
big
ones,
I'll
take
the
other
big
one.
I
will
review
the
search
one
awesome.
Thank
you
all
right.
If
anyone
wants
to
review
the
middle
one,
it
is
the
small
one,
so
pretty
good
bang
for
the
buck.
But
let's
move
on
for
now:
okay,
jason
w!
You
are
up
next.
D
Hey
so
I
want
to
give
a
great
shout
out
to
frederick
for
helping
out
with
the
cell
toolbar
that
has
now
merged
into
master.
I
believe
it's
going
to
get
pulled
into
3.4.x
is.
Is
the
me
seek
spot
gonna?
Do
that
or
should
I
do
that
manually.
B
D
Do
it
tomorrow,
I
don't
know:
okay,
don't
worry,
I
will
see
I'll
keep
an
eye
on
my
email.
That's
like
the
highlight
of
every
morning
is
seeing
like
overnight
feedback
from
our
friends
in
europe.
Okay,
so
thank
you
very
much
for
everyone's
help
and
contributions
on
that.
There
is
also
a
cell
toolbar
tag,
a
package
cell
toolbar
tag.
So
if
you
file
bugs
and
enhancements,
please
tag
them
with
cell
toolbar.
D
So
that
way
we
can
kind
of
track.
Those
there's
already
a
couple
that
are
tagged.
That
way.
Two
other
questions
that
came
up
based
on
conversations
I've
had
internally
one
is
I
had
heard
from
somewhere
and
unfortunately,
brian
is,
is
out
at
an
off-site
meeting
today.
What
is
the
status
of
like
versioning
within
jupiter
lab?
There
is
a
jupiter
lab,
git
extension,
but
I
had
heard
somewhere
that,
like
versioning
metadata
is
already
part
of
the
jupiter
lab
data
model.
We
just
don't
have
a
ui
for
it.
B
There
is
on
the
server
side
the
checkpoint
features,
but
I
think
the
default
implementation
is
only
to
have
one
backup
version.
I
don't
think
he's
creating
versioning.
It's
probably
like
a
custom
content
manager
can
change
the
behavior.
If
I
remember
correctly,
but
by
default,
I
think,
is
only
creating
one
checkpoint.
D
Okay,
yeah,
I
mean
I
was
doing
a
little
research
on
this
earlier
in
the
week
and
found
a
bunch
of
articles
that
were
saying
like.
If
you
want
version
control
in
jupiter
lab,
you
should
be
using
git
or
jupytext
or
other
extensions
that
were
kind
of
built
for
that
and
that
there
wasn't
version
and
capability
built
in
or
built
into
the
ui.
E
I
I
think
I
mean
there
is
checkpoints.
The
checkpoint
mechanism
is
very
confusing
and
there's
a
long-standing
issue
that
says
the
jupiter
lab
only
provides
access
to
the
latest
checkpoint,
whereas
the
notebook
provides
access
to
any
checkpoint
and-
and
I
think,
there's
an
issue
and
maybe
even
a
pr
about
providing
access
to
multiple
checkpoints.
E
B
D
Okay,
yeah,
if
you
could
share
that
in
the
chat,
that's
kind
of
I
I
didn't
know,
the
word
checkpoint
was
used
for
this
purpose.
That
helps
me
a
lot
to
like
explain
this
and
find
stuff
in
the
document.
So
thank
you
so
much
about
that.
There's
one
other
question
about
an
internal
team.
That's
working
on
some
extension
updates.
We're
talking
about
pre-built
extensions
that
share
libraries
when,
when
installing
different
extensions
as
pre-built
extensions
that
share
libraries,
do
those
libraries
duplicate
in
the
code
or
vend
it
to
the
browser.
D
F
It
has
a
shared
library
of
whatever
majig,
it's
bundled
and
and
it's
shared
and
then
whatever
majig
you
know,
commands
or
whatever
majig
extra
home
button
would
rely
on
that.
You
can
do
it
with
all
of
them
have
a
copy
of
it.
If
they
really
are
independent,
you
don't
need
them
together.
B
E
It's
it's
a
bit
subtle
in
that
what
nick's
right,
webpack
bundles
it!
We
override
that
when
we
build
extensions
so
that
core
libraries
are
always
shared
so
there's
so
the
default
depends
on
if
it's
a
core
library
or
one
of
our
special
extensions
that
we're
overriding
when
you
build
a
web,
build
an
extension
or
if
it's
not
so,
if
it's
not
a
core
library
by
default,
it's
bundled
in
the
webpack
bundle
and
not
shared
with
other
things.
E
And
then
you
have
to
explicitly
note
in
your
in
your
configuration
that
you
want
this
particular
dependency
shared.
A
E
Can
I
can
I
ask
jason
to
address
it,
jason?
Were
you
the
one
somebody
recently
opened
up
an
issue
about
security
versions?
Support
for
version,
old
versions
of
jupiter
lab
was
that
you
jason.
E
Maybe
we
can
add
it
to
the
additional
discussion,
but
I'd
love
some
quick
discussion
around
making
an
official
policy
about
what
versions
of
jupiter
lab
are
supported,
I.e
what
bug
fixes
you
know
how?
How
far
back
do
we
backport
bug
fixes
and
if
we
have
some
time
based
policy,
which
I
think
what
you
were
asking
for,
or
version
based
policy
etc.
D
I've
been
talking
about
it.
I
actually
just
opened
a
an
issue
about
this.
As
a
result
of
yesterday's
security
meeting,
I
can
drop
that
in
the
chat.
This
might
be
a
good
place
to
have
discussion
about
it,
because
I
included
some
links
to
examples,
including
the
node.js
one,
which
is
my
personal
favorite
about
like
how
to
communicate
this
information,
because
having
a
document
on
a
third-party
website
that
I
can
point
to
and
say
see.
You
can't
use
jupyter
lab
three
after
this
date,
because
you
won't
get
security
updates.
A
G
G
A
thing
we
discussed
that
I
know
we
discussed
that
exact
policy
in
detail
at
the
in-person
dev
meeting.
We
had
a
couple
years
back,
and
that
was
what
we
decided,
but
that
was
just
those
of
us
that
were
there
physically
deciding
that,
I
don't
think
we
like
made
it
an
official
policy
or
put
it
anywhere.
I
think
it
was
just
us
deciding
it
because
we
needed
something.
A
E
And
there's
two
two
things
that
I
think
are
issues
with
that
one
as
jason
points
out.
I
think
in
that
issue
is
it
doesn't
give
people
concrete
timelines,
and
so
it's
hard
to
say
you
know
two
will
not
be
supported
or
three
will
not
be
supported
in
you
know,
x
months,
so
you
should
start
moving
off.
Instead,
we
say
when
we
release
the
next
version,
but
then
the
next
version
gets
delayed
and
then.
H
E
Second
issue
with
that
is,
we
have
seen
a
lot
of
enterprises,
amazon
being
one
but
others
as
well,
that
you
know
a
yearly.
Cadence
is
sort
of
too
fast,
and
so
they
jump
versions
from
one
to
three
instead
of
adopting
two,
and
so
I
guess
that
works
with
an
n
minus
one
strategy,
but
it's
a
little
bit.
You
know
if
there
was
a
little
bit
more
overlap.
G
D
To
be
blunt,
I've
talked
to
people
who
insist
they
need
support
for
node,
10
and
node
8,
which
left
even
long-term
support
years
ago,
and
I
I
tell
them,
look
those
there
are
no
more
security
vulnerabilities.
So
if
anything
comes
out
that
targets
node
10,
that's
on
you,
that's
not
on
the
node
developers
anymore
and
to
to
me
that's
a
more
powerful.
D
The
fact
that
I
can
point
to
that
gantt
style
chart
on
their
website
is
a
powerful
motivator
and,
and
so
if
we
could
have
a
similar
chart
that
says
like
if
you're
still
using
jupiter
lab
2
after
x
date,
we
will
no
longer
provide
our
own
security
patches
for
it.
That's
that's
lighting,
a
fire
under
people
to
say
if
you're
still
using
jl2
time
to
start
talking
about
upgrading.
A
Well,
we
can't
we
can
try
to
meet
our
yearly
major
version
goal,
but
we
simply
can't
release
something
if
it's
not
releasable.
What
we
can
do
is
try
to
soften
that
by
saying
we
target
a
major
release
a
year.
We
support
we're
using
the
n
minus
one
strategy,
but
we
also
give
you
I
don't
know
some
sort
of
like
90
day
buffer,
where
n
minus
two.
We
give
you
the
90-day
countdown
for
it
or
something
like
that.
A
Oh,
what
what
nick
just
wrote
in
the
chat
totally
caught
me
off
guard,
because
I
wasn't
expecting
to
see
the
word
mermaid
in
there.
So
yeah
I
mean
is
this:
maybe
maybe
everyone
who
has
thought
about
this
or
has
a
position
they
want
to
advocate,
should
comment
in
that
issue.
A
This
seems
like
the
kind
of
thing
where
we
could
vote
on
it,
but
I
imagine
we
could
probably
arrive
at
a
consensus,
because
I
don't
I'm
not
hearing
that
much
dissent
here,
so
I
would
suggest
leaving
this
issue
for
a
week,
getting
some
commentary
and
then
trying
to
close
it
next
week
with
here's,
a
pr
to
the
team
compass
repo
or
to
read
me
on
the
main
repo.
That
basically
says
this
is
our
our
supported
version
policy.
F
A
Yeah,
but
node
is
one
thing:
jupiter
is
a
lot
of
things
and
it's
a
lot
of
things
that
end
up
at
different
points
in
the
stack
jupiter
lab
is
a
client
application.
Jupyter
server
doesn't
have
the
same
constraints
that
jupiter
lab
has.
So
I
don't
imagine
one
policy
jupiter
wide
is
appropriate,
but
I
do
think
getting
that
information.
A
D
Notably
I'm
looking
at
the
top
nav
on
jupiter.org
and
there
is
no
support
thing.
There
is
no
support
link
now.
I
know
that
the
idea
of
putting
a
support
link
on
an
open
source
project
is
is
begging
for
problems
because,
of
course
we
are
not
providing
technical
support,
but
you
know
wordsmith
if
we
need
to,
but
I
I
would
love
to
have
a
gantt
chart.
D
You
know
or
some
some
such
where
I
can
just
point
to
it
and
say
this
is
what
we've
agreed
upon,
and
so,
if
you
want,
if
you
want
an
extension
on
this,
come
to
the
page
but
like
biased
by
the
company,
I
work
for
and
I'm
sure
that
some
of
you
folks
have
worked
at
companies
that
are
similar,
which
is
that
when
an
old
version
is
no
longer
supported,
the
inertia
has
people
say
like
well.
D
The
sprint
board
says:
I'm
not
allowed
to
upgrade
because
that's
going
to
add
all
this
complexity,
so
I
have
to
keep
using
this
ancient
version
forever
and
it's
it's
not
going
to
convince
any
of
us,
but
it's
going
to
drive
people
to
like
use
an
older
version
well
past
time
when
they
otherwise
would
migrate
off
of
it.
If
we
don't
provide
guidance
that
says
you
have
to
get
off
of
it.
A
D
Yeah
I
mean
we
can
again
like
under
on
the
node
site.
It's
under
the
about
section
which
I'm
also
okay
with
like
the
about
section,
is
a
whole
section
of
node.js.
It's
not
a
single
page
like
jupiter.org
about
pages,
so
we
could
say,
like
you
know
about
you,
know
about
the
people
about
the
software
about
the
projects
under
it
like
we
could
do
a
little
bit
of
reorganization,
but
I
I
like
the
idea
of
adding
it
to
the
website
somewhere
easily
prominent.
E
We
could
also
disconnect
the
ideas
of
you
know
when
end
of
life
is
and
when
other
versions
come.
So
you
can
have
essentially
an
n
minus
one
strategy
but
capped
at
a
time
based
support
window
for
a
release.
E
So,
for
example,
for
2.0,
we
could
say
we'll
support
this
for
at
least
two
years
and
maybe
at
most
two
years
so
plan
on
it
for
two
years,
we'll
plan
to
have
4.0
out
by
the
end
of
the
two
years,
but
if
4.0
actually
ends
up
taking
two
years
to
release
instead
of
one
year,
I
think
it's
okay
to
tell
people
2.0
is
still
phased
out.
Two
years
after
it
was
released
and
please
move
to
3.0,
which
was
our
current
release
and
we're
still
working
on
4.0.
E
So
that
addresses
when
the
end
of
life
of
for
2.0
is,
which
is
something
important
for
us
to
not
maintain
not
like
it's
a
it's
a
it's
a
burden
to
keep
maintaining
the
old
software,
but
it
also
addresses
the
timeline
that
you're
asking
for,
but
it
it
doesn't
completely
commit
us
to
releasing
4.0
on
a
yearly.
You
know
cadence.
D
A
skeptical
cynical
engineer
might
say,
but
wouldn't
that
mean
that
there
is
potentially
a
point
where
all
versions
of
jupiter
lab
become
unsupported.
If
we
don't
release
often
enough
and
that's
all
the
more
reason
for
us
to
actually
do
the
thing.
A
A
A
D
D
For
leaving
the
comment
on
that
issue,
I
encourage
everyone
else
with
an
opinion
on
this
to
add
comments
on
this
and
maybe
at
the
meeting
on
the
20th
a
week
from
today,
we
can
have
like
a
more
action-oriented
discussion
about
this.
A
Cool
thanks,
jason
alex
you
are
up
next.
G
Yeah,
just
quick
updates
for
me
for
those
that
joined
late.
I
archived
some
of
our
older
meeting
notes
in
this
hackmd,
so
it
behaves
faster
like
we
do
every
quarter
and
I
opened
up
the
pr
for
my
code.
Viewer
widget
that
I
demoed
last
week.
So
that's
ready
for
people's
feedback.
I
am
working
on
adding
the
ability
to
restore
on
page
refresh
because
it
seemed
from
the
comments
that
that
would
be
a
blocker
for
getting
it
in
so
yeah.
So
could
review
and
further
feedback
if
possible.
G
I
think
it
would
be
a
good
task
to
iterate
on
so
getting
the
functioning
code
in
and
then
adding
more
functionality
in
follow-ups,
rather
than
blocking
the
merging
of
it
on
getting
all
these
cool
new
features
everybody's
like
oh.
We
could
also
use
it
for
this,
because
there
was
a
lot
of
that
which
I'm
really
excited
about
so
yeah,
just
short
update
for
me.
A
A
It
looks
as
though
we
are
at
the
additional
discussion
section,
but
was
there
or
is
there
anyone
on
the
call
who
would
like
to
do
an
update
that
has
not
added
their
name
to
the
agenda?
I'll
give
you
a
second
to
think
about
that.
F
F
So
I
don't
know
if
there's
a
path
to
doing
that
with
marked
or
if
that
would
trigger
hey
it's
time
to
consider
the
markdown
it
as
as
an
alternative
to
mark.
I
know
we
already
moved
that
out
into
a
plug-in,
but
you
know
that's
a
thought.
A
Do
you
offhand
know
if
we'd
be
doing
any
sort
of
aside
from
the
the
visual
implications
and
maybe
slight
discrepancies?
Are
there
any
api
breakages
or
is
this
something
that
could
come
out
in
a
point
release
if
it
turns
out
that
it
has
the
features
we
want
without
clobbering
public
apis?
A
F
Yeah
I
mean
marked
as
it
exists
today
is
not
extensible.
So
to
my
knowledge
I
mean
we
we
do.
We
have
to
do
ugly
stuff
to
make
the
latex
work
right
and
it
is
not.
It
is
not
pretty
so
yeah
I
mean
I
don't
think
anybody's
relying
on,
because
there's
nothing
to
rely
on
the
baseline
renderer
is
just
kind
of
what
it
is.
F
I
I
mean
no,
I
don't
think
it
would
block
anything,
and
if
you
really
want
it,
you
can
go,
get
a
plug-in
and
that's
maybe
the
way
it
should
be,
but
yeah
jfm
right
for
real,
but
I
don't
know,
I
think
it
is
a.
It
is
a
good
point.
F
Well
defined
yeah
I
wish
markdown
was
more
well-defined.
I
mean
it's
great
it
like
just
works
great
and,
and
we've
already
got
a
reference.
You
know
stealable
implementation,
I'm
sure
our
buddy
angus
wouldn't
care.
If
we,
you
know
lifted
it
up
into
there
and
missed
started
using
it
and
has
already
done
a
bunch
of
work
on
it.
So.
A
So
what
william
and
jason
are
talking
about
in
the
chat
here
is
really
interesting
to
me.
A
Is
it
time
to
define
the
markdown
that
jupiter
notebooks
support
and
make
it
easy
for
different
clients
to
support
the
same
set
of
markdown
features
that
we
support
and
to
make
notebooks
more
predictable
in
the
way
they're
going
to
render
or
is
that
is,
is
creating
one
new
thing,
a
problem
and
we
should
say
no.
Actually,
what
we're
doing
is
we're
one
hundred
percent
adopting
github
flavor
knockdown,
or
something
like
that
or
like
where,
where,
where?
Where
is
this
in
the
life
cycle
of
feature,
all
the
way
to
specification.
I
Just
that,
I
really
hope
that
that
happens,
because
I
would
like
to
you
know
know
how
notebooks
people
create
and
code
calc
might
fail
on
jupiter,
classic
or
jupiter
lab
and,
conversely,
and
build
a
document
that
right
now,
it's
just
very
kind
of
random,
read
the
source
code
of
jupiter
classic
kind
of
thing.
I
I
think
if
there's
a
random
javascript
file,
you
know
somewhere
in
the
notebook
that
defines
that,
for
you
guys
and
I've,
I
literally
copied
that
code
and
was
using
it
to
try
to
keep
compatibility
so
that
if
somebody
uses
math
in
a
you
know
in
a
jupiter
classic
notebook
it'll
get
interpreted
the
same
way
in
code
top.
I
But
that's
a
really
like
the
whole
approach
to
parsing
out
math
is
pretty
ugly,
it's
much
better
to
use
a
proper
plug-in
to
a
markdown
parser.
So
I
recently
found
a
really
good
plugin
for
math
for
mark
down
it,
which
is
much
more
well
written,
and
I
switched
to
using
that
and
then
I
added
a
bunch
of
regular
expressions
to
make
it
behave
much
more
like
what
people
expect.
Based
on
having
used
jupiter,
lab
or
jupiter
classic,
because
none
of
the
multiple
different
configuration
options
for
that
plugin
matched.
I
What
jupiter
does,
but,
incidentally,
because
there's.
I
I
Then
that
would
be
really
helpful
for
everybody
else.
So
that's
my
perspective
and
similar
remarks
go
for
a
lot
of
other
things
in
terms
of
park
down.
I'm
sure
pete
has
some
thoughts
too,
or
at
least
I'd
love
to
hear
if
he
has
any
about
the
same
question,
because
you
guys
must
power
smart
down
somehow.
H
Yeah
we've
done,
we
have
a
number
of
bugs.
It's
been,
it's
been
a
pain
we've
like
I,
I
think,
all
of
our
bugs
are
fixed,
but
like
the
number
of
edge
cases
and
everything
has
been
oriole
pain,
I'd
love
to
contribute
some
like
tests
or
or
something
like
that.
You
know
like
a
spec.
Spec
is
good.
If
we
can
get
some
like
standardized
testing
or
or
something
like
that,
like
that,
I
think
that'd
be
even
better.
H
There
are
marked
on
it,
I'm
a
little
scared
of
it
just
because
of
like
how
many
changes
and
like
random
stuff
that
we've
had
to
do
with
marked.
So
I'm
I'm
scared,
but
I'd
love
to
explore
it.
Yeah
mermaid
seems
cool.
A
So,
with
the
changing
architecture
of
jupiter
notebook,
at
least
the
thing
that
jason
grout
mentions
in
the
chat
goes
away
right,
where
there
won't
be
discrepancies
between
notebook
and
lab.
A
That
also
seems
like
a
good
opportunity
to
say
here's
how
jupiter
notebook
markdown
should
work,
because
at
the
very
least
we
are
arriving
at
a
point
where
jupiter
front
ends
are
going
to
be
coherent
and
doing
the
same
thing.
It
seems
like
a
good
time
to
document
that
for
everyone
else
yeah,
I
don't
know
about
that
pete,
I
don't
that
not
not
not!
I'm
not
saying
I
don't
know
in
a
flippant
way.
I
I
truly
just
don't
know
the
answer
to
that.
H
But
I'll
give
a
plus
one
to
tech
at
this
point,
but
the
I
haven't
looked
into
the
compatibility
in
in
quite
a
while.
We
we
had
compatibility
issues.
It
would
I
I
mean
the
the
math
jacks
and
contact
and
everything
that
the
surface
area
of
that
is
ginormous.
So
I'm
being
somewhat
fluent
when
I
mentioned
like
standardizing
that
inspecting
that.
I
Yeah
yeah
ktex
is
missing.
I
think
backslash
inbox,
which
is
it
yeah
jason,
also
points
it
out,
which
could
be
can
be
noticeable,
but
it's
pretty
good.
Otherwise,
I
use
it
as
much
as
possible
in
code
and
then,
if
something
will,
if
something's
missing,
it
falls
back
to
math
checks.
F
Yeah
and
and
one
of
the
other
things
that
we
you
know
had
looked
at
once,
making
allowing
it
to
be
extensible
is
awesome
yet
terrifying
right.
So
the
fact
that
you
were
not
doing
anything
special
to
get
math
rendering
it's
just
part
of
the
architecture
right
you're,
just
I'm
going
to
put
some
more.
You
know
tokens
in
there,
but
you
know
I've
seen
people
ask
for
the
ability
to
put
multiple
languages
inside
one
document
right
and
like
cool.
We
can
do
that.
I
can
make
plug-in.
Does
that
all
right?
F
But
now
everybody
has
to
know
that
that
plug-in
is
a
thing
and
so
yeah.
I
think
that
I
think
that
the
thing
that
we
would
need
is
not
a
spec,
because
that
is
markdown
has
been
resistant
to
that
thus
far,
I'm
not
sure
if
we
would
have
that,
but
a
conformance
suite.
You
know
that
that
is
a
set
of
notebooks
that
a
set
of
notebooks
a
set
of
markdown
files.
You
know
the
things
that
we
anticipate
would
be
rendered
descriptions
of
settings
inside
of
the
settings
schema.
F
I
don't
know
whatever
all
those
places
it's
unfortunate,
but
I
don't
see
really
how
you
would.
I
don't
see
how
we
get
around
that
as
to
the
the
math
thing.
One
thing
that
that
would
potentially
be
very
powerful
is
forget
about
this
stuff.
I'm
gonna
be
like
wikipedia
and
if
you
got
it
and
you've
got,
you
know
zlatec
or
something
back
on
your
server,
I'm
just
going
to
render
it
on
the
server
I'm
going
to
get
back
to
using
svg.
I
I
would
find,
but
the
first
thing
nick
said
to
be
super
useful,
which
would
be
even
one
single
notebook
that
has
kind
of
all
the
math
checks.
I
mean
sorry
all
the
markdown
functionality
you
can
think
of
that
jupiter
should
support
just
used.
Then
I
can
look
at
it
and
see
if
it
looks
right
and
compare
visually.
If
nothing
else,
I
mean
that
would
be
extremely
useful
to
have.
H
F
Yeah
go
over
the
jupiter
accessibility
meeting
we
had
somebody
say
like
I
just
read
the
latex
like
I
just
speak
native
la
tech,
because
whatever
you
do
is
not
going
to
be
great,
you
know.
So
as
long
as
you
hoist
that
source
all
the
way
through
which
wikipedia
does
do
you
can
go
grab
it
right
out
of
there.
That's
that
is,
you
know
for
all
its
warts.
It
is
a
lingua
franca.
A
F
Well,
I
mean
it
would
be
it
like
going
to
mathjax
three
would
be
better.
There
is
an
open
issue
for
that
on
jupiter
lab,
there's
an
open
issue
for
that
on
envy
convert
and
that
jupiter
or
envy
convert
pretty
much
has
to
get
off
mistune
right,
so
we're
already
gonna
have
a
risk
there
or
something
so
defining
these.
F
Defining
the
the
reference
documents
for
for
notebooks
and
how
they
should
appear
is
is
very
important
right
now
right,
because
I
think
something's
going
to
give
in
a
bunch
of
different
directions.
A
Jason
says
this
could
be
the
basis
of
a
jet,
I
think,
as
a
precursor
to
a
jet.
There
could
be
a
jupiter
lab
repo
that
has
a
bunch
of
notebooks
with
different
kinds
of
markdown
in,
and
the
benchmarking
suite
that
frederick
has
written
could
be
used
to
see
are
those
working
as
we
release
new
versions,
and
that
could
be
the
basis
of
proposing
it
as
a
gep.
E
Could
we
just
define
some
gallaudet
tests?
Does
the
benchmark
test?
Do
they
do
screenshots?
So
if
we
did
some
glotta
tests
that
were
just
notebook
rendering?
That
would
already
help
even
just
to
make
sure
we
don't
have
regressions
in
a
bunch
of
markdown
examples
and
what
they
should
look
like
when
they're
rendered.
E
B
E
A
All
right
do
we
have
an
issue,
at
least
so
we
can
say
post
some
markdown
in
in
this
issue.
That
seems
like
a
good
all
right.
A
Cool,
so
maybe
nick
since
you
brought
it
up,
please
could
you
open
an
issue
and
link
it
here
and
then
pete,
william
anyone
else
who
writes
funky
things
in
markdown
cells?
Could
you
post
some
examples
of
what's
either
an
edge
case
or
just
you
know,
base
case
and
anything
that
we
should
be
testing
and.
A
A
Okay,
let's
move
to
the
additional
discussion,
section
jason:
I
assume
you
wrote
the
first
one.
E
It's
just
a
fyi
announcement
that
we
have.
I
currently
set
up
a
presentation
by
don
j
amani
who
works
on
vs
code
and
jupiter
compatibility
and
vs
code
to
talk
about
widgets
in
vs
code
next
week,
at
next
tuesday,
at
our
widget
staff
meeting,
I've
had
at
least
one
request
that
we
might
move
that
so
just
pay
attention
to
the
ipay
widgets
get
our
channel.
If
you
are
planning
on
coming
and
we'll
announce,
if
there
is
a
change
to
that
I'll,
announce
it
there
and
we'll
record
it
too,.
A
Thanks
james
speaking
of
recording
calls,
I
am
still
in
the
process
of
trying
to
get
into
the
cloud
account
for
our
zoom
to
do
something.
With
these
recordings,
I
asked
everyone
in
jupiter
who
might
potentially
have
these
credentials
and
literally
nobody
said
I
have
them.
So
the
next
step
is
all
right
time
to
do
a
password
reset
for
the
account.
That
is
the
two
factor
off
that
zoom
is
using
before
it
will.
E
E
C
A
A
C
A
Well,
let's,
let's
talk
about
this
after
we
start,
okay,
all
right!
We
have
one
other
point
in
the
additional
discussions.
I
don't
know
who
added
it.
Is
it
rick.