►
Description
Enrique takes the team through his assessment of the candidates for the new WYSIWYG architecture and we discuss the next steps.
A
A
Great
so
hello,
this
is
a
statistic
or
issue
requirement
session
and
we
are
gonna,
be
talking
about
the
research
that
we
did
on
which
content
relators
alternative
that
we
are
evaluating
to
replace,
replace
our
korean
option.
That
is
those
ui,
I'm
gonna.
Besides
that
and
discussing
the
the
result
of
this
of
this
research,
we
are
choose
which
are
the
editor
alternatives
that
will
be
candidates
to
implement
the
concepts
where
we
are
gonna.
A
A
So
we
focus
on
on
three
on
three
acres:
each
of
the
operators
have
are
have
a
markdown
parser
as
well,
usually
these
eighth
or
recommend
a
specific,
modern
parser,
because
they
have
an
other
transformer
that
allows
to
convert
the
rich
content
that
is
produced
by
data
into
markdown
in
the
case
of
of
tiptap.
That
is
just
a
grubber
around
prosmeter.
A
A
A
In
the
in
the
previous
issue
performance
session,
we
talked
a
lot
a
lot
about
prosmeter
and,
and
so
here's
a
first,
the
well
the
the
alternatives
I
recommend
recommend
to
choose
for
for
us.
Moving
forward
with
the
proof
of
concept
are
cross
meter
and
creator
and
here's.
Why
so
tiptop
is
a
is
a
great
alternative
from
the
point
of
view
that
it
provides
a
lot
of
out
of
the
box
features
implemented
features.
A
B
A
A
I
don't
see
a
lot
of
sponsorship
from
our
usage
from
from
big
organizations
and
that's
usually
a
good
sign,
because
it
means
that
if
the
freak
has
that
that
kind
of
relationship,
usually
it
is
a
sponsor
and
it
has
a
long-term
maintenance
contract
with
those
with
those
companies.
In
the
case
of
tiptap
at
least,
I
couldn't
find
that
information
or
information
from
a
third
party
and
the
sponsorship
that
that
it
has
in
indeed
in
the
github
sponsorship
feature,
is
very
poor.
A
In
the
case
of
the
of
the
test
suite,
the
the
test
coverage
is
pretty
much.
No,
it
doesn't
have
a
test
coverage
for
most
extensions
and
here's
something
that
is.
That
is
very
interesting.
So
the
way
that
they've
been
handling
community
extensions
is
that
a
community
member
submits
an
extension
via
pull
request.
But
then
this
pull
request
doesn't
contain
tests
for
the
extension,
and
it
doesn't
have
like
this.
A
You
know
these
requirements
and
then
that
extension
ends
up
in
the
in
the
core
package
that
they,
you
know
they
the
product
owner,
has
to
maintain
and-
and
it's
not
maintained
as
an
independent
entity.
So
that
usually
put
like
more
pressure
on
maintaining
that
that
extendation
in
in
the
periodic
outer.
But
then
those
essentially
the
same
gain,
has
test
coverage
and
that's
the
case
for
more
most
of
the
of
the
of
the
repository
and
the
and
the
extensions
direction.
A
It
doesn't
have
a
release
changelog,
not
in
the
same
way
that
trust,
meter
and
circulator
provide
a
a
very
organized
and-
and
you
know
and
change,
look
with
description
of
every
of
what
every
version
has
in
this
case
of
transmitter.
It
has
a
change
logs
for
every
every
core
package
and
in
the
case
of
the
sdk
or
it's
even,
I
could
say
that
it's
even
better
because
they
have
a
an
engineer,
an
engineering
blog
as
well,
where
they
explain.
A
B
A
Well,
in
the
in
the
case
of
the
three
options-
that's
not
the
case,
although
I
maybe
I
don't
have
enough
information
to
to
give
a
accurate
statement
about
that.
But
what
I
noticed
is
that,
even
though,
in
the
case
of
ck83
that
has
a
lot
of
out-of-democratic
focus
of
features,
they
also
have
architecture
that
is
extremely
flexible.
A
It
is
very,
very
similar
to
brush
meter,
they
have
these
lightweight
core
and
they
implement
everything
that
is
related
to
the
documented
state.
For
example,
you
know
that
that
in
the
case
of
transmitter,
they
have
a
document
schema
where
they
define
what
type
of
nodes
within
the
documentary
are
valid.
Creator
is
using
the
same
architecture,
the
same
document
schema
and
each
part
of
the
schema
is
not
implemented
within
the
core.
A
So
what
I
noticed
about,
and
in
the
case
of
tita,
it
is
implemented
in
in
the
same
way,
it
has
a
lot
of
out-of-the-box
pictures,
but
since
it
is
based
on
cross
meter,
they
follow
the
same
architecture,
a
lot
of
the
ways.
All
of
the
features
that
extend
the
schema
are
implemented
as
independent
extensions.
A
Okay,
so
community
they
the
biggest
difference
that
that
I
noticed
well
in
the
case
of
the
usually
the
three
projects
have
a
high
a
high
rate
of
response.
In
the
case
of
the
issues,
I
noticed
that
the
the
project
maintainers
are
very
active
in
answering
and
replying
to
all
of
the
issues
created
by
the
community
in
the
case
of
the
of
the
pull
requests
as
well.
Something
that
I
noticed
about
ck83
is
that
they
are
not
receiving
many
pull
requests
from
the
from
the
community.
They
have
their
input.
A
Their
first
signature
is
a
private
company,
besides
being
an
open
source
project
just
like
gitlab,
so
they
developed
the
project
in
github.
Most
of
the
people
of
the
requests
that
are
open
in
the
repository
are
coming
from
employees
of
of
the
ck8
or
company.
So
that's
that's
a
reason
that
I,
you
know
marked
this
one
as
a
partially
fulfilled
evaluation
criteria.
A
I
saw
some
requests
from
the
weather
community
and
the
response
was
quite
quick
as
well,
but
I
think
that
is
something
that
is
worth.
That
is
worth
mentioning,
because
that's
one
of
the
problems
that
I
saw
with
toast
ui
that
they
were,
they
were
having
this
private
development
process
and
then
they
were
releasing
a
new
version.
But
I
wasn't
seeing
a
lot
of
contributions
from
the
weather
community.
A
D
D
D
A
Definitely
so
I
I
did
a
bit
more
into
tiptop
and
to
understand
what
what
exactly
ticktack
is,
and
I
think
that
provides
three
three
con
three
components
are
very
valuable.
Well,
two.
Actually,
the
first
one
is
the
the
menus.
So
let
me
go
and
open
the
demo
page
of
tip
tab,
so
they
provide
these
menus
that
I
think
that
it
will
take
time
to
implement
that
it
will
take
investment
resources.
A
A
D
A
B
D
Recognize
yeah
some
of
the
limitations
and
stuff.
It's
a
pity.
They
don't
have
have
it
in
a
branch
available
or
eve
to
be
reviewed
and
and
stuff,
so
that
one
can
see
kind
of
like
how
it
looks
and
how
much
different
is
it?
And
I
mean
because
in
the
same
in
the
same
breath
you
know
like
I've
got
concerns
about
ck
editor
and
you
know
like
it's
a
did.
D
You
know
that
the
fact
that
they're,
you
know
for-profit
company
and
you
know,
means
that
there's
continuous
development,
but
it
makes
them
also
much
less
open
to
to
change
and
input
and
and
stuff.
But
on
the
other
hand,
you
don't
have
the
same
issues
you
have
of
tip
tap.
We
think
you
know
the
maintainers
or
you
know
I
don't
know
how
many
maintenance
they
are,
but
they
could
lose
interest
move
on
to
a
new
project.
D
You
know
it's,
I
think,
from
from
from
the
assessment,
it's
clear,
there's
no
obvious
winner,
there's
no
obvious
hey!
This
is
clear
as
they
the
best
solution
for
us
all
of
them
have
drawbacks.
I
think
from
a
pure
technical
point
of
view,
pros,
mirror
and
markdown.
It
is
probably
the
best
options,
but
it
comes
with
with
the
overhead
of
us
having
to
implement
a
lot
of
our
own
stuff.
A
C
C
Theoretically,
you
know
we
would
then
be
able
to
hopefully
be
able
to
get
an
estimate
of
what
type
of
how
much
time
would
it
take
to
do
the
amount
of
ui
layer
that
we
actually
would
need
right
with
test
coverage
and
with
yeah.
So
I
don't
know
I'll,
let
you
continue,
but
that's
the
that
definitely
jumps
out.
A
C
A
That
that's
a
a
really
good
point,
because
we
don't
have
all
of
the
information
the
necessary
information
to
to
understand
how
difficult
it
is
to
implement
that
interrupt
layer
with
you
by
yourself,
because
I
I
see
those
components
are
valuable,
but
I
don't
know
how
much
they
they
actually
are
are
valuable.
I
don't
know
if
it's
gonna
take
us
like
months.
Actually,
when
that
interrupt
layer
or
on
those
components
or
if
it
is
something
that
we
actually
can
implement
relatively
quickly
in-house.
B
C
C
Your
position
would
basically
be
we
might
as
well
use
tip
tap
because
we
at
least
have
a
starting
point,
and
we
just
have
to
be
very
careful
during
with
that
implementation
such
that
we
don't
keep
things
to
keep
things
essentially
loose
enough,
that
we
don't
get
too
tied
into
that,
because
otherwise
we're
starting
at
five,
which
is
pros,
mirror
and
markdown
anyway,
so
we
might
as
well
leverage
the
work
that's
been
done
in
tiptop
is
what
it
sounds
like.
Is
that
accurate
or.
B
A
Yes,
what
what
I
found
like
what
I
don't
know
yet,
because
actually
I
don't
know,
is
how
much
we
are
if
we
adopted
how
much
we
are
coupled
by
by
the
way
that
they
structure
the
their
projects.
I
mean
how
difficult
it
is
to
actually
discard
the
tip-top
layer
and
go
back
to
prosmeter
in
a
future
point.
B
Yeah,
it
seems
like
if
it's
since
it's
mit
license
and
it's
on
top
of
pros
mirror
unless
they're
actually
modifying
prosperity
itself
for
having
a
forked
version.
It
seems
like
it's
always
possible
to
to
fork
tip
tap
and
take
it
in
the
direction
we
want.
If,
in
the
future,
we
get
to
a
point
where
they're
just
doing
things,
we
can't
live
with.
C
C
A
Cool,
so
one
one
aspect
that
I
found
very
interesting
is
about
the
the
mobile
support,
so
none
of
the
the
alternatives
are
broken
on
moment,
so
they
all
work
on
mobile,
while
at
least
in
the
in
the
web,
browsers
that
I
did
tested.
What
I
really
appreciate
about
ck83
is
that
it
has
some
first-class
mobile
features.
A
For
example,
if
you
are
selecting
a
a
text
segment,
usually
the
classic
signature
does
something
of
like
zooming
into
that
segment
of
the
ui
and
to
display
the
the
the
well
the
the
context
menu.
That
is,
like
you
know,
related
to
that
tech
segment.
So
that's
something
that
I
that
I
really
liked-
and
I
think
that
is
like
it
made
me-
realize
that
there
is
a
difference
between
it
is
not
broken
on
mobile
and
it
actually
has
like
features
that
are
implemented
that
are
targeting
mobile.
A
D
It
it's
easy
to
put
like
our
concerns.
You
know
on
paper
your
paper,
but
I
think
we
feel
we
should
probably
test
out
a
lot
of
these
yeah
and-
and
I
and
and
that's
obviously
the
next
obvious
logical
step
in
our
process.
Is
we
want
to
create
proof
of
concepts?
You
know
we
can
we
can
test.
Our
openck
editor
is
to
accepting
a
community
contribution
and
stuff
like
that.
You
know
like
a
lot
of
these
things.
Might
you
know
their
first
class
mobile
support?
D
A
Yeah
and
again,
as
as
jan
is
saying,
you
know,
I
completely
agree.
I
think
that
this
is.
This
is
great
december.
63
criteria
is
great,
but
I
think
that
implementing
the
proof
of
concept
will
add
another
layer
of
insight
that
will
strengthen
you
know
our
our
confidence
to
make
this
decision.
I
think
I
I've
been
doing
this.
A
I've
been
feeling
this
evaluation
criteria,
and
I
don't
I
I
don't
feel
like
you
know
not
me-
are
100
confidence
of
making
that
decision,
but
I
I
really
like
you
know
finding
these
kind
of
things
like
it
looks
great
on
mobile
and
it
actually
has
some
they
care
about
implementing
a
good
user
experience
in
that
form.
Factor
in
the
case
of
pin
mobility
either
either
tiptap
or
prosmeter
have
provide
a
user
interface.
So
we
don't
need
to
implement
a
theme.
A
In
recent
responsibility,
the
three-
the
three
alternatives
are
very
similar
tiptop
because
it
is
basically
cross
meter,
but
also
providing
within
the
layers
that
they
built
on
top
of
cross
meter.
They
structured
to
be
very-
and
we
probably
won't-
have
any
kind
of
problem
with
that
and
tiptap
provides
us
a
very
good
laser
that
allows
us
to
to
access
today
to
approach
mirror
state
whenever
we
need
it.
A
The
only
concern
that
I
have
with
with
tiptap
is
that
the
documentation
is
not
good
they.
It
is
not
very
well
documented
and
in
the
case
of
the
text,
selection
and
cursor
manipulation
api.
I
need
to
dig
a
little
bit
more
into
that
because
they
don't
provide
the
api
to
do
it,
but
approach
meter
those.
So
we
need
to
figure
out.
How
do
we
access
the
transmitter
to
handle
the
text,
collection
and
cursor
manipulation.
A
In
the
case
of
ck8,
or
they
don't
have
uploading
ecosystem
really,
I
think
that
we
will
be.
It
will
be
this
kind
of
development
model
where
we
are
relying
fully
relying
on
on
a
single
entry
to
implement
what
we
need
and
that's
also
very
risky.
That's
unlike
cross
meter
that
transmitter
has
a
really
you
know,
a
really
good
community.
We
have
like
tiptop
implementing
a
layer
on
top
of
frostmeter
that
that
is
great.
We
have
also
a
react
community
that
is
implementing.
A
C
A
B
B
D
Wanna
action
I
wanna
just
throw
in
something
to
consider
as
well
there's
a
big
consideration
of
using
our
our
editor
for
more
than
just
a
static
site
editor,
so
that
would
be,
for
instance,
issue
descriptions.
Comments,
merge,
request,
descriptions,
you
know
so
everywhere,
where
you
can
write
marked
around
currently
by
you
know,
allowing
a
rich
text.
D
D
D
You
know
into
our
page
bundles
just
for
the
sake
of
it
so
yeah.
I
think
that's,
probably
a
data
point
that
we
didn't
clearly
enough
to
find
necessarily
initially,
but
with
the
overall
performance
we're
going
on,
we
should
probably
consider
the
performance
impact
that
each
editor
might
have
as
another.
You
know
data
point.
C
Yeah,
something
else
may
be
worth
considering
on
that
note:
enrique
is
like
the
instancing,
so
in
the
context
of
you
know
like
a
block
editor
or,
for
example,
if
if
this
manifests
in
the
you
know
in
the
comments
or
something
like
how
many
instances
could
you
have
open,
does
that
now
start
really
being
a
problematic
thing
unlikely,
but
something
to
think
about?
Maybe
that's
a
really.
B
A
D
A
A
A
And
not
editors
provide
that
they
provide
some
pictures
like
flooring
menus
and
that
can
help
us
speed
up
the
development
process
in
the
case
of
tiptap
and
creator.
So
you
know
that's
worth
mentioning
in
the
case
of
markdown.
Shortcuts
tiptop
already
provides
this
picture.
I
think
that
this
is
where
tiptop
shows
it's
strange,
because
it
provides
many
of
the
features
that
we
desire.
A
It
supports
in
the
case
of
toxicate
or
they
provide
an
ap
guide,
will
allow
us
to
implement
it
quickly,
but
it
doesn't
fully
provide
a
merge,
the
markdown
shortcuts
picture,
and
then
there
are
other
security
eric
that
has
been.
The
creator
needs
to
go
that
correlates
everything
that
we
wanted
to
fix
in
toast
ui,
for
example,
editing
18
existing
links,
that's
something
that
ticktap
already
provides.
That's
also
something
that
cigarette
provides.
A
It's
going
to
be
easy
to
implement
in
cross
meter
pasting
tables,
that's
something
that
the
three
options
from
sorry
pacing
tables
from
google
docs.
That's
something
that
all
the
alternatives
already
support
and-
and
you
know
much
much
of
the
of
the
box
that
we
found
in
those
ui-
they
do
not
exist
in
either.
A
C
I've
I've
two
comments,
one
with
respect,
and
again
this
is,
you
know,
probably
saying
it's
easier
said
than
said
than
done,
but
with
respect
to
none
of
the
editors
having
block
content
support
in
theory,
this
really
maps
well
to
my
question
previously
about
instances.
If
there's
no
issue
with
the
instances,
all
it
is
in
right,
like
conceptually,
is
just
an
array
of
those
instances
where
each
of
those
blocks
is
some
small,
partial
subset
of
markdown.
C
You
can
rearrange
them
and
then,
at
the
end,
you
iterate
all
through
all
those
and
glue
them
back
together
into
a
file
of
content
like
again
conceptually.
That's
how
I
see
that
working,
because
I
don't,
I
think,
that's
something
we
can
solve
when
we
want
to
get
when
we
want
to
actually
have
a
block
editor.
The
main
thing
I
want
to
say
is,
and
again
I
don't
know
if
this
is
the
right
answer,
my
gut
kind
of
says
again,
we
have
there's
trade-offs
with
all
of
them.
C
Ck
editor
5
seems
to
be
the
most
strong
and
robust
and
I
think
that's
a
result
of
having
a
dedicated.
You
know
team,
that's
working
on
it.
Obviously,
there
are
trade-offs
there
with
the
with
kind
of
community
flexibility
there
right.
So
what
I'm
curious
about
is
regardless,
if
it's
that
one
or
however,
we
end
up
doing
this,
I'm
kind
of
curious.
What
if
we
focus
on
just
one
solution
and
try
to
prove
why
it
won't
work
or
something
like
so
right
now,
my
gut
is
like
ck5
editor.
C
We
go
say
we
go
with
that
one,
and
we
say
why
won't
it
work
for
the
things
we
want
to
to
solve,
assuming
it's
like
the
assuming
it's
the
strongest
one.
We
think
the
next
step
would
be
prove
why
it
doesn't
work
as
opposed
to
splitting
our
efforts
on
all
of
them.
We
at
least
start
with
what
we
think
is
the
best
and
find
what
are
the
shortcomings
still
and
then
we
can
maybe
look
at
another
solution
and
say
how
might
it
fill
the
gaps?
C
B
D
D
B
B
I'm
sort
of
feeling
like
because
of
the
maturity
and
the
fact
that
it's
a
commercial
product,
the
mobile
support,
ck
editor,
seems
like
a
strong
choice.
It
doesn't
seem
like
it's
going
away
and
I
think
the
the
payload
size
and
the
approach
to
instancing,
I
think,
are
two
of
the
big
questions
that
might
put
it
off
of
the
table.
But
as
far
as
a
like,
you
said,
without
not
having
a
plug-in
ecosystem,
it's
a
commercial
product
and
they
have
a
lot
of
their
own
extensions.
D
I
I
think
the
work
needed
to
create
all
of
these
utility
on
top
of
pros
mirror
it's
just
too
much
for
us
to
go
and
create
ourselves.
I
think
I,
like
derek's
approach
of
you,
know
looking
at
each
of
the
viable
options
and
if,
in
this
case
it
would
be
row
four
and
six,
you
know
let's
identify
weaknesses
and
let's,
let's
go
and
all
our
concerns
and
let's
try
and
prove
our
concerns
wrong.
D
D
D
Maybe
that
helps
us
ease
a
lot
of
the
the
pain
or
the
perceived
kind
of
like
concerns.
We
have
with
it
the
same
with
ck
editor.
You
know
like
I
remember
it
being
heavy
and
and
bulky,
but
you
know
like
that's
just
an
assumption
that
we
need
to
go
and
check,
and-
and
I
think
you
know
this-
the
multi
like
the
context-
we
need
to
remember
that
that
you
know
we
didn't
specify
initially,
is
that
we
want
to
be
able
to
use
this
beyond.
Just
as
that
excited
editor.
D
Now,
if
that
means,
we
can
have
a
page,
editor,
lite
or
rich
editor.
Lite
great,
you
know
it
doesn't
have
to
enable
all
the
features,
because
when
you
think
of
a
comment
box,
it
doesn't
have
to
enable
everything
that
the
full
static
site
editor
might
need
so
yeah.
I
I
but
I
would.
I
would
already
move
to
eliminate
pros,
mirror
pure
pros
mirror
and
having
to
write
our
own
layer
on
top
of
that,
and
I
think
we
need
to
we
can
probably
before
we
actually
build
a
proof
of
concept.
A
A
C
I
think
that
I
think
the
decision
to
drop
five
makes
sense
and
maps
back
to
chad's
earlier
comment,
which
is
kind
of
like
a
no-brainer
which
is
like
looking
back
was
an
awesome
comment
is
tiptap
is
already
building
on
top,
and
if
we
have
to
do
that,
we
might
as
well
start
there.
So
I
think
that
makes
total
sense
to
to
knock
out
the
pros
mirror
mark
donut
without
the
layer
on
top.
For
now
that
I
think
that
makes
total
sense.
B
B
Is
it
gonna
break
going
forward
like
which
is
a
risk
for
tip
tap,
but
ck
editor
seems
to
check
all
of
the
boxes
and
then
the
the
other
main
thing,
I
think,
is
like
the
mobile
support
and
the
payload
size.
Both
of
those
are
things
that
just
could
be
deal
breakers,
whereas
the
others
are
you
know,
maybe
we
would
have
to
work
around,
but
it
wouldn't
necessarily
be
the
end
of
the
world
as
long
as
it
still
does.
What
we
want.
C
Yeah
I
see
the
in
terms
of
one
exercise
is
basically
say
we
pick
these
two
or
we
just
focus
on
one.
Whichever
way
we
end
up
doing
it.
Just
for
the
the
immediate,
like
experimentation
is
mapping
that
very
granularly
against
our
issue
of
like
what
was
wrong
with
toast,
ui
and
like
how
how
like
does
it?
Maybe
both
of
them
solve
all
the
problems,
and
then
we
have
to
obviously
still
go
back
to
now.
C
Maybe
the
mobile
issue
or
like
compare
the
other
things
but
again
like
ck
editor,
could
again
have
the
lack
of
plugins,
but
then,
when
we
actually
compare
them
to
what
our
shortcomings
were
with
toast
ui,
if
they're
already
fulfilled,
that's
awesome
right
like
so
that's.
I
think
we
need
to
get
pretty
granular
here
in
short
order.
Basically,.
A
So
what
other
requirements
do
you
think
that
we
have
to
include
in
there?
In
the
group
of
concert,
I
moved,
I
created
a
new
session
with
concept
requirements,
because
I
I
want
to
evaluate
the
payload
size
and
the
multiple
instances
concerned
within
that
in
that
work.
So
what
what?
What
else
do
we
want?
What
is
the
best
way
of
knowing
if
those
haters
are
not
the
best
option
for
us?
How
can
we
discover
that,
through
the
improvement
concept,.
B
It
seems
like
your
ux
section
already,
does
a
pretty
good
job
of
comparing
it
to
toast
ui
right
so
other
than
the
two.
You
said,
the
the
payload
size
and
the
instancing
I'd
like
to
see
like
more
details
on
what
is
substandard
about
the
mobile
experience
with
the
tip
tap
compared
to
ck
editor,
and
is
that
something
that
we
expect
mattering
to
our
users
or
not.
C
And
I
kind
of
just
mentioned
this
a
little
bit,
but
I
think,
looking
at
the
actual
issue
that
I
believe
eric
created,
where
we
listed
the
specific
things
that
toast
ui,
which
has
a
shortcoming
on
one
you've,
actually
already
covered,
at
least,
if
not
more,
with
respect
to
cursor
support
right
being
able
to
put
the
cursor
wherever
you
want
dynamically
and
and
have
that
be
understood,
transferring
from
wysiwyg
to
markdown
mode.
That's
one
specific
example:
whatever
the
other
items
are
that's
what
I'm
most
curious
about
is
like.
C
C
So
that's
really
what
it
comes
down
to
is
like
a
lot
of
the
ux
subtle
details
is
where
it
that's,
basically,
where
toast
ui
fell
down
and
then
also
being
able
to
kind
of
do
the
custom
things
we
want,
which
again
concerns
me
a
little
bit
still
with
ck
editor
and
that's
where
we
have
to
dig
in.
Does
it
have
all
the
things
that
solve
because
inevitable
you
want
to
have
to
do
something
custom
right,
so
that's
kind
of
that
still
scares
me.
C
A
Something
that
we
could
do
is
do
something
that
I
did
with
the
quill,
and
I
remarked
a
remark
demo
that
was
implementing
a
an
erv
visualizer,
a
template
and
template
visualizer.
That
will
demonstrate
that
we
can
easily
implement
a
custom
ui
component
to
to
display
template
syntax
and
recognize
it
in
within
the
markdown
parser.