►
Description
Enrique, Michael, and Eric discuss how we might handle situations where the user switches between content formats.
https://gitlab.com/gitlab-org/gitlab/-/issues/325203
A
A
So
there's
a
lot
of
questions
inside
the
issue,
and
the
purpose
of
this
call
is
probably
to
get
alignment
on
where
we
want
to
go
for
us
because
initially
we're
talking
about
switching
content,
but
it
feels
like,
in
the
last
20
hours,
we've
kind
of
come
down
to
a
scenario
of.
Let
me
show
my
screen:
it's
probably
better.
A
We
this
was
one
of
the
latest
proposals
about
like
saving
the
formats
for
changing,
but
then
someone
said
a
friend
suggested
that
we
can't
really
block
people
changing
stuff,
because
you
can
just
change
it
in
the
in
the
git
file
in
the
file
system
itself,
and
you
can
change
the
type
and
then
we're
back
to
the
same
scenario
so
rather
than
creating
think
of
it
as
a
new
format.
Now
we're
thinking
the
content.
A
A
B
A
B
Format
to
specify,
if
you
want
to
use
a
content,
editor
or
not,
that's
very
important,
because
we
are
not
like
changing
the
file
system
used
by
the
wiki
to
specify
which
editor
you
want
to
use.
Instead,
just
we
use
the
same
markdown
format,
and
then
we
switch
between
two
editors
for
that
for
that
format,.
A
C
One
of
our
major
concerns
was
the
potential
for
incompatibility
in
the
file
formats,
and
so
we
we
discuss
rather
than
create
a
proprietary
format.
We
add
a
new
extension-
that's
really
marked
down
under
the
hood,
but
it
signals
to
the
wiki
that
this
is
a
different
type
of
file
that
can
be
edited
in
the
content
editor.
C
And
so
then
we
went
down
this
path
of
like
how
do
we
switch
between
formats,
because
you
can
do
that
now,
even
though
it's
not
great
in
the
it's
not
great
in
the
sense
that,
like
they're
not
fully
compatible
we're
not
doing
translations
like
if
you
write
a
link
and
mark
down
and
switch
to
rdoc,
it
doesn't
make
the
link
in
our
doc.
It
just
ends
up
with
text.
So
I
think
the
reason
I
personally
would
favor
this
one.
C
That's
up
on
the
screen
now,
which
is
it,
which
is
not
using
the
format
selector
to
determine
which
editor
to
use.
The
reason
I
like
this
is
because
it
telegraphs
our
intention
better,
which
is
that
this
is
a
markdown
editing
experience
or
an
editor
that
is
currently
focused
on
editing,
markdown
files.
It's
not
it's
not
a
markdown
editor,
but
I
think
going.
The
other
path
will
make.
C
It
seem
like
we're
trying
to
build
a
proprietary
format
and
even
though
we're
not
so
yes,
there's
still
a
risk
like
if
I
opt
in
so
I'm
just
left
to
right.
If
I'm,
if
I'm
on
a
wiki
page,
I'm
creating
a
new
page-
and
I
say:
oh,
I
I
like
new
things,
I'm
going
to
try
this
new
editor
out,
and
I
click
that
and
now
I
have
somewhat
less
functionality
because
we're
still
working
on
rounding
out
all
the
different
node
types
for
gitlab
flavored
markdown.
C
Then
I
have
a
path
to
get
back
to
markdown.
But
I
think
what
we
want
to
avoid
is
a
path
too
then
switch
to
rdoc
or
something
like
that,
and
then
vice
versa,
like
I
think,
one
of
the
concerns
was
like
in
any
edit
mode.
This
format,
switcher,
maybe
doesn't
make
sense,
and
it
only
really
should
be
used
when
you're
creating
the
new
file,
but
since
it
exists
now,
how
can
we
work
around
that?
B
C
I
think
right
now
all
it
would
be
nothing
to
the
user.
I
think
this
would
be
for
us
to
key
off
of
and
whether
we
should
display
warnings
or
not,
and
if
we
don't
need,
if
we
can
work
around
that
and
not
need
any
front
matter,
that's
even
better.
I
think
the
the
discussion
that
my
understanding
of
it
was
like.
C
C
B
Actually,
like,
I
think
that,
like
what
the,
what
what
what
I
tried
to
convey,
the
in
the
alternative
here
in
the
one
that
is
just
like
allowing
the
user
to
choose
an
animator,
was
to
to
avoid
the
idea
that
you
have
to
switch
between
the
content,
editor
and
and
a
different
format
like
if
we
can
avoid
the
idea
that
the
content
editor
is
like
an
entirely
new
format
and
we
can
focus
on
saying
hey.
This
is
only
this
is
only
available
for
markdown.
B
And
then,
if
you
are
like
switching
to
a
different
format,
then
you
immediately
are
like
choosing
also
like
to
to
opt
out
of
the
of
the
content.
Editor
like
in
some
ways
like
trying
to
find
trying
to
find
a
way
of
like
removing
completely
removing
the
complexity
of
making
the
content
later
interact
with
other
formats.
C
C
C
I
think
the
root
of
this
discussion
is
just
how
should
we
handle
incompatibilities
in
this
weird
transition
time
when
we
don't
have
full
support
for
editing
everything,
and
if
we
can
do
that
using
error
messages,
if
we
can
gracefully
not
overwrite
data,
which
I
know
is
not
necessarily
the
case,
but
if
we
can
find
other
ways
to
warn
people
as
they're
opting
in
that
like
hey,
these
are
the
things
that
are
supported.
These
aren't.
These
are
the
things
that
are
not,
and
we
can't
really
do
anything
about
it.
C
A
B
It
like
let's
say
that
it
has
some
mermaid
diagrams
and
the
content
data
just
can't
display
it
or
rate
it
or
recognize
it
in
any
ways
when
the
user
tries
to
save
the
content
after
the
content
later
opened
that
that
page
and
unloaded
it,
the
container
should
transform
that,
like
a
editable
version
of
the
content
of
the
page
back
to
markdown,
to
persist
it
in
the.
In
the
background,
it's.
A
B
But
if,
if
we
are,
if
the
contentator
doesn't
recognize
an
unsupported
content
type,
then
it's
it's
just
going
to
to
meet
it.
It's
going
to
skip
it
and
that
market
that
we
generate
again
won't
have
that
that
content
will
be
lost.
So
the
the
the
risk
of
data
loss
of
losing
data
happens
when
the
users
save
the
changes.
A
Okay
to
when
saving
okay
is
this
a
correct
line?
So
if
I'm
using
the
content
editor
and
for
whatever
reason
it
doesn't
recognize
the
content
whatever
that
may
be,
then
it
will
be
omitted
when
converting
to
markdown
when
saving
that,
and
that
generally
happens
when
you
open
the
existing
markdown
file
in
the
content,
editor
say
the
mermaid
diagram.
A
C
C
So
if
you're
opening
a
new
document
in
the
content,
editor
and
typing
into
it,
and
then
you
want
to
convert
to
markdown,
it
should
be
fine,
because
the
output
of
the
content,
editor
is
markdown,
but
if
you
took
an
existing
markdown
file
that
had
say
a
bunch
of
issue
references
or
something
like
that
where
we
have
created
links.
Well,
maybe
those
are
bad
examples,
because
I
am
assuming
in
the
markdown
file
they're
stored
as
links
but
mermaid
diagram,
we'll
stick
with
that.
It's
a
special
block
of
code.
B
That's
right
like
there
are
some
nuances
in
there,
but
they're
like
the
core
idea
is
that
they
wait
like
that.
Note
type
won't
be
like
correctly
interpreted
by
the
content
data
and
when
it
generates
markdown
back,
it
won't
be
an
issue
reference
anymore.
It
could
be
a
link,
it
could
not
be
there
at
all,
but
you
know
something
will
happen
that
it
will
like
destroy
that
content.
C
I
imagine,
and
it'll
just
be
represented
by
a
code
block
which
is
not
helpful
to
anybody.
So
that's
the
destructive
aspect
of
this,
and,
if
I'm
at
the
risk
of
under
selling
the
effort
to
get
there,
we're
probably
talking
about
a
handful
of
releases,
I
won't
even
put
a
number
but
a
handful
of
releases
before
we
have
full
support
for
for
gitlab
flavored
markdown.
C
In
the
meantime,
I
kind
of
feel
right
now
that
that
is
the
only
scenario
that's
risky
and
we
can
probably
bypass
over
engineering
the
solution
with
really
clear
warnings
when
you
open
up
documents
in
the
content
editor
about
what
is
supported.
What
is
not,
you
know
you
can
make
it
persist
until
the
user
dismisses
it
or
something
like
that
link
to
the
docs
and
make
it
just
very
clear
that,
like
there,
this
is
a
beta
and
it
doesn't
support
everything.
And
if
you
lost
something
just
go
back
in
your
git
history
and
cover
recover,
it.
C
It's
interesting
so
I'm
just
trying
to
think
through
the
so
I
open
up
the
wiki
click
edit,
I'm
in
the
content.
Sorry,
I'm
in
markdown
mode-
and
I
say:
oh
it's,
this
new
editor
and
I
click
edit
in
content
editor
and
I
start
making
changes
because
it's
visual.
I
should
know
right
away
that.
There's
content,
that's
messed
up,
so
I
could.
C
I
could
at
that
point
revert
my
changes,
switch
back
to
the
old
editor
and
say
you
know
just
give
me
the
last
saved
state.
But
if
I
didn't
notice
and
clicked
commit,
that's
the
point
where
I
would
need
to
revert
yeah.
Okay
again,
I
think
messaging
here
could
solve
90
of
this
and
the
other
10
could
be
solved
by
clear
documentation
about
how
to
revert
commits
in
the
wiki.
B
Something
that
idea
that
fran
pointed
out
in
the
in
the
discretionary
in
the
asia
is
that
at
some
point
we
should
be
able
to
catch
when
transmitter,
doesn't
understand
or
doesn't
support
that
type
of
load
like
in
that
case,
that
that
would
like
completely
stop
the
user
flow
of
opening
the
document
in
data,
and
that
would
solve
the
problem.
But
that's
not
something
that
we
can.
B
I
don't
know
if
that's
something
that
we
can
do
right
now,
like
it's
not
easy,
easily
doable
because
transmitter
just
let's
say
that
it
doesn't
fail
when
it
cannot
parse
a
type
of
content.
So
I'm
gonna
open
a
discussion
in
the
pros,
mirror
forums
and
see
how
we
can
detect
that
that
would
be
like
like
the
easier
solution
for
the
user.
I
guess
because
we
are
just
stopping
them
from
opening
something
that
the
commentator
can
cannot
take
in
the
first
place.
C
I
think
that
kind
of
knowledge
about
the
node
types
and
what
is
supported
would
be
really
helpful,
even
if
we
don't
completely
stop
it
from
opening,
but
that
just
it
that
sounds
like
a
much
more
clear
path
to
being
able
to
identify
parts
of
the
document
that
we
need
to
sort
of,
isolate
or
otherwise
protect,
and
that's
something
we've
discussed
for
a
long
time.
We
should
certainly
start
the
discussion
with
frozen
error,
but
I
don't
it
doesn't
sound,
easy
or
or
something
that's
achievable
in
the
next
couple.
B
A
There'll
be
some
button
that,
like
opens
the
page
in
a
new
editor
and
then
kind
of
like
the
next
actions,
is
to
start
looking
at
different
messaging
and
things
like
that
that
could
pop
up.
So
perhaps
what
we
we
could
start
working
on
is
like
the
different
states
that
could
open
it
up
like
everything's,
fine,
everything's,
fine,
but
you
don't
have
your
content
here,
or
maybe
a
combination
of
all
those
buttons
there.
A
So
here's
one
of
return
to
old
editor,
but
the
other
scenario
that
was
mentioned
was
oh,
that
mermaid
diagram
that
I
expected
is
like
no
longer
here
or
you
know
that
pulling
of
that
data
file
to
generate
the
table
is
like
totally
gone
so,
like
this
page
looks
kind
of
different,
so
those
are
scenarios
where
rollbacks
might
be
needed
or
like
go
again
to
return
to
old
editor.
It
might
be
something
that's
useful
here
so
or
some
kind
of.
C
A
C
Yeah,
let's
I'll
I'll,
create
an
issue
right
after
this,
so
we
can
discuss
and
bring
in
amy
for
for
technical
writing
help.
I
think
I
think
we
can
distill
this
down
into
a
concise
explanation
with
multiple
with
maybe
two
calls
to
action.
One
is
so
the
the
explanation
is
we're
in
beta
here's,
what
we
support,
link
to
the
documentation
and
then,
if
things
aren't
looking
right,
revert,
that's
your
opt-out
and.