►
From YouTube: GitLab 14.5 Kickoff - Create:Editor
Description
Overview of what's planned for the Create:Editor group in 14.5
Planning issue: https://gitlab.com/gitlab-com/create-stage/editor/-/issues/30
A
A
This
will
hopefully
leave
us
with
a
much
more
maintainable
and
predictable
code
base,
but
also
see
some
reliability
and
performance
improvements
with
regards
to
how
the
web
id
interacts
with
the
file
system
itself.
So
we're
looking
to
wrap
that
work
up
in
14.5
and
hopefully,
hopefully
realize
some
of
those
improvements.
A
Next
shifting
gears
to
the
wiki
and
the
content
editor
that
we've
implemented
the
the
rich
text,
markdown
editor
that
we
introduced
in
14.0
over
the
past
quarter,
we've
been
working
on
rounding
out
support
for
all
types
of
gitlab,
flavored
markdown
that
could
possibly
be
in
a
wiki
document
and
rendering
those
appropriately
in
the
content
editor.
We
have,
I
think,
one
or
two
last
issues
related
to
rendering
content,
including
this
one
about
markdown
or
html
comments
that
are
in
line
with
the
document.
A
So
we're
going
to
try
and
surface
these
comments,
which
are
really
helpful
for
things
like
page
templates
or
for
leaving
context
through
the
document
that
you
don't
want
rendered
in
the
final
page
output.
So
we'll
have
we'll
bring
that
into
the
content,
editor
and,
I
think,
we'll
end
up
after
14.5
having
full
support
for
just
about
any
type
of
content
that
could
exist
inside
a
wiki
page,
a
markdown
wiki
page.
A
So,
with
the
content
editor
right
now,
there's
a
an
issue
where
you
can
have
a
whole
bunch
of
markdown,
as
even
as
simple
as
just
like
a
few
different
mixed
types
of
markdowns,
a
heading,
a
paragraph,
a
list-
maybe
a
block
quote
and
copy
that
to
the
clipboard.
When
you
paste
that
into
the
content
editor,
it
doesn't
get
parsed
as
individual
blocks,
it'll
just
bring
it
in
as
one
big
paragraph.
So
that's
not
ideal.
A
What
we
want
is
the
ability
to
be
able
to
take
your
content
from
somewhere
else
drop
it
in
the
wiki,
as
is
in
the
content,
editor,
and
it
renders
out
appropriately
so
in
145,
we'll
be
tackling
the
ability
to
to
parse
larger
amounts
of
markdown.
That's
pasted
from
the
clipboard
in
the
content.
Editor.
A
As
I
mentioned,
we
are
supporting,
we
are
now
supporting
a
whole
bunch
of
different
content
types
in
gitlab,
flavor
markdown
and,
as
we
look
towards
the
near
future,
we'll
be
introducing
ui
to
help
you
implement
some
of
these
formatting
options
or
block
types
things
like
superscript,
fonts
or
footnotes
or
inline,
diff
formatting
things
like
that.
The
problem
is,
we
are
running
out
of
horizontal
room
in
the
toolbar,
so
we
add,
you
know
six
or
eight
more
icons
here
and
now.
A
All
of
a
sudden,
your
page
is
overflowing
with
ui
options,
so
we'll
be
introducing
a
little
bit
of
hierarchy
here
in
the
content,
editor,
adding
an
overflow
menu
for
less
frequently
accessed
ui
elements,
and
that
will
help
clean
up
the
toolbar
and
allow
us
to
scale
a
little
more
rapidly,
without
necessarily
redesigning
the
whole
editor
itself.
A
Last.
We
want
to
enable
the
ability
to
switch
on
the
fly
between
editing
and
content
editor
and
the
raw
markdown.
This
is
probably
one
of
the
most
important
directional
items
that
we've
had
in
our
backlog
for
the
content
editor
in
a
while
when
we
receive
feedback.
This
is
probably
the
number
one
bit
of
feedback
we,
we
understand
the
the
value
of
having
a
wysiwyg
rich
text
editor,
but
for
certain
occasions
and
for
certain
people
you
just
want
to
have
access
to
the
raw
markdown
editor
as
well,
and
that's
perfectly
fine.
A
The
issue
is
right
now,
because
our
content
editor
was
sort
of
in
a
beta
state.
We
were
testing
it
out.
We
weren't
sure
that
we
were
going
to
be
able
to
persist,
content
back
and
forth
in
a
way
that
was
safe
and
and
that
didn't
corrupt
the
data.
A
So
we
had
created
this
sort
of
opt-in
and
opt-out
flow
for
the
content,
editor
that
allows
you
to
switch
between
raw
and
raw
markdown
and
the
content
editor,
but
it
would
throw
away
any
unsaved
changes
as
you
toggle
back
and
forth,
so
we'll
be
removing
that
barrier
so
that
you
can
toggle
from
using
the
classic
markdown
source,
editing
experience
that
you're
used
to
and
toggle
into
the
the
content
editor
in
the
rich
text:
editing,
environment
back
and
forth,
without
losing
your
data
or
without
having
to
save
and
commit
in
between
each
time.