►
From YouTube: Multi file editing with Source Editor
Description
Michael Le and Denys MIshunov discuss multi-file editing with Source Editor
B
But
since
it's
an
editing
experience,
we
were
going
to
take
it
on
now
that
it's
been.
What
I'm
trying
to
look
for
doing
now
is
diving
deeper
into
validating
this
from
a
user
perspective.
Like
you
know,
is
this
a
real
problem
that
we
need
to
solve
and
also,
if
we're
gonna
solve
it?
How
might
we
do
it
because
there's
some
potential
solutions
out
there
yeah-
and
I-
and
I
looked
you
in
on
this
dentist,
because
you
wanted
to
get
a
little
bit
more
user-facing
or
interaction
on
the
research
side.
C
B
A
A
So
that's
that's
one
thing
to
keep
in
mind,
however,
the
question
is
whether
users
pushing
so
many
files
would
prefer
doing
this
through
the
web
interface
of
of
the
product,
or
they
would
still
get
back
to
their
desktop
applications.
Because
most
of
the
look
like
technically
there
are
two
different
user
groups
right.
So
the
developers
engineers
will
most
probably
push
more
than
three
files
users
working
with
the
documents
with
them
with
the
www
resources
they
they
usually
don't
work
with
multi
multiple
files.
A
A
We
just
I
just
I
just
checked
git
log
and
I
checked
the
the
number
of
files
in
different
commits
and
that's
so.
It
was
nowhere
near
scientific
research
or
any
statistical
data.
It
was
just
like
looking
through
the
through
the
commits
through
the
recent
commits
and
seeing
how
many
files
we
have
in
different
commits.
B
To
to
like
add
more
clarity
to
this,
because
all
we're
looking
at
is
commits,
but
we
don't
know
if
those
commits
came
from
a
point
of
frustration
or
it
was
just
like
a
natural
starting
point
like
I'm
gonna
make
a
change
with
three
files.
I
know
better
than
to
start
here.
I
might
just
go
straight
to
my
local,
ide
or
they're
just
more
used
to
that,
because
we
know
that
the
usage
of
the
single
file
either
is
higher
than
the
web
ide.
A
A
Then
we
can
measure
how
many
off,
how
often
people
click
commit
button
on
the
single
file
editor.
So
then
we
will
have
this
difference
between
how
many
people
actually
got
to
the
edit
interface
and
how
many
people
actually
made
the
commits.
So
we
have
this
difference
of
people
who
were
either
going
to
like
three
possible
scenarios.
A
First,
one
people
just
change
their
mind.
They
don't
want
to
commit,
that's
it.
In
this
case,
we
might
want
to
measure
the
clicks
on
the
cancel
button
as
well
to
to
figure
out
at
least
some
correlation
there,
but
technically
the
three
scenarios:
people
just
change
their
mind.
They
don't
want
to
commit
anything.
Second
people
realize
they
need
more
context,
they
might
switch
to
web
id
and
edit
things
there.
A
A
Oh
well,
there
are
several
several
ways
to
get
back
to
the
repository
as
well.
So,
let's,
let's
assume
for
now
that
we
cannot
measure
how
many
people
actually
abandoned
single
file
later
to
continue
editing
in
web
ie,
and
the
same
is
true
for
people
who
abandon
a
single
file
later
in
order
to
do
the
changes
in
their
local
ap,
local
apps
right.
A
A
A
We
might
provide
some
sort
of
an
intermediary
solution
that
would
help
us
gather
the
statistics
so
by
introducing
the
like
the
some
button
to
go
to
web
id
from
the
edit
single
file
editor.
That
would
let
us
know
how
many
people
actually
lack
the
multifile
editing
experience
and
who
actually
go
to
web
id
from
single
file
editor.
But
that's
that's
a
bit
too
disturbing
ui.
I
guess
because
that
would
that
would
mean
we
redirect
people
we
have
to
preserve
the
changes
in
they
may
they
currently
made
in
the
single
file.
B
Yeah
speaking
of
disturbing
interactions,
when
you
were
talking
about
trying
to
get
a
sense
of
why
people
are
abandoning
the
single
this
single
file
editor,
I
was
like
this
is
just
a
idea
on
the
spot.
Here
is
like
it's
like
a
motor
that
pops
up
it's
like.
Why
are
you
leaving
instead
of
like
you
know
the
traditional
like
ratio?
You
want
to
leave,
but
it's
like.
Why
are
you
leaving?
Because
I.
A
A
A
We
can
measure,
I
guess-
and
also
actually
I
tried
right
now
when
I'm
in
the
edit
mode-
and
I
click
the
link
to
go
back
to
the
repository.
I
still
get
the
over
the
alert
asking
living
leave
site
changes
that
you
made
may
not
be
saved,
and
I
have
to
confirm
that
I'm
yes,
I
am
leaving
so
technically.
There
are
some
some
hooks
that
that
do
tell
us
that
users
do
abandon
single
file
editor.
B
B
Yes,
yes,
and
hence,
is
disturbing
and
annoying
at
the
same
time,
exactly
cool
yeah
and
my
other
ideas
is
if
they
were
going
to
start
a
commit.
Let's
say
you
click
edit
with
a
single
file
editor.
It
opens
up
a
page,
so
you
had
the
page
view
url
there
and
I
was
thinking
if
you
stay
abandoned
and
then
you
see
a
commit
later
with
the
same
url
within
a
15.
C
C
A
B
A
Makes
sense,
but
this
is
not
necessarily
correct,
like
sometimes
I
might
abandon
the
single
file
error
simply
because
I
actually
like
have
to
make
more
changes
in
exactly
the
same
one
file,
but
I
have
to
make
more
changes
or
I
need
to
research
things
and
add
this,
the
more
information
later
on.
So
that's
that's
why
I
might
abandon
this,
and
it's
just
like
it's.
It's
really
hard
to
to
measure
these
things
now,
but
the
thing
is
my.
A
A
On
the
other
hand,
once
we
implement
this
even
in
the
mvp
state,
we
would
be
able
to
gather
the
statistics
of
how
many,
how
often
people
open
that,
how
many
people,
how
often
people
click
and
have
multi-tab
interface-
that's
that
would
constantly
give
us
much
a
higher
quality
statistical
data.
I
think.
B
So
thanks
for
bringing
up
the
multi-tab
kind
of
comment
there,
how
would
you
see
multifile
editing
happening
with
this
source
editor?
Do
you
think
we
could
leverage
something
like
the
tab
interface
that
exists
in
the
web,
ide
yeah
yeah?
I
think
like
that,
would
be
like
the
ideal
scenario
like
yeah.
In
this
non-ideal
scenario,
everything
opens
up
in
a
new
page
but
like
in
in
the
perfect
world.
I
think
we
could
have
it
open
in
the
same
page
as
tabs
would
be
more
yeah,
approachable.
A
I
would
say
we
we
could
approach
this
from
with
with
two
things.
First,
following
exactly
the
same
tabular
interface
that
we
have
in
webide
is
by
far
the
simplest
way,
because
we
from
the
engineering
standpoint,
we
have
all
the
bits
kind
of
ready
for
that.
We
we
we
have
the
architecture
to
support
this
scenario.
We
have
logic
to
to
to
switch
between
the
tabs
and
things
like
this,
the
quite
the
the
only
thing
that
is
different
in
the
single
file
letter
comparing
to
web
id
is
the
geometry
of
this
area.
A
So
it's
much
more
cramped,
so
you
won't
be
able
like
technically
it
will
be
very
uncomfortable
to
open
a
lot
of
tabs
in
this
little
space,
so
introducing
the
full
screen
button,
for
example,
for
the
for
the
editor
where
users
could
okay,
if
it
becomes
too
cramped.
I
just
click
the
full
screen
and
the
editor
expands
on
the
full
screen
and
I'm
in
fully
sort
of
concentrate
mode
for
editing.
A
A
Yeah,
I
think
that
would
that
at
least
I
don't
see
the
reason
why
this
wouldn't
be
a
welcome
change.
I
mean
the
cost
of
of
failing.
This
is,
is
zero
really
in
my
opinion,
because
we
would
not
present
the
the
file
tree
right
away.
It
would
be
just
on.
Demand
means
no
performance
penalty,
no
changes
in
the
ui.
We
just
introduce
a
button
keystroke
an
action
in
the
editor,
whatever
that
user
would
explicitly
request
if
they
need
not.
C
C
B
B
A
Cool,
so
we
are
on
the
editing,
editing
interface.
This
is
a
single
file
editor
as
we
as
we
all
know,
and
somebody
loves
somebody
hates
how
I
envision
this
is
that
this
toolbar,
that
is
not
part
of
the
editor
at
the
moment,
will
be
part
of
the
editor.
This
part
will
be
part
of
the
interface,
so
these
two
things
will
probably
be
split
to
two
different
lines,
but
the
editor
will
have
a
toolbar
that
will
have
different
buttons
on
it,
depending
on
the
file
type
user
edits.
A
A
Editor
will
be
the
one
more
button
that
that,
probably
on
this
side,
that
you
click
and
you
get
the
three
the
file
tree
sliding
or
just
showing
up
on
the
on
the
left-
and
that's
that's
technically
it
we,
oh,
as
I
said
we
might
introduce
another
button
for
the
full
screen
mode
where
things
get
expanded,
but
that's
that's
pretty
much
it.
I
don't
at
the
moment:
that's
that's
when
we
have
the
toolbar
at
the
moment.
A
We
can
start
with
that
that
that
that
was
the
the
the
essence
of
the
comment
that
we
like
having
the
toolbar
mep
well
will
increase
the
success
rate
of
this
integration,
but
technically
we
do
not
need
to
wait
for
that.
We
can
start
working
on
this
even
before
we
have
the
toolbar,
because
it
will
technically
add
one
more
entry
point
to
this
to
this
functionality.
B
C
C
A
A
Why
would
we
show
edit?
So
the
description
has
to
be
updated
and
I
I
think
the
mvp
has
to
be
dramatically
expanded
and
the
first
mvp
will
actually
be
wait.
A
second
we
can,
if
we,
if
we
accept
the
scenario
where
we
potentially
have
two
toolbars
for
markdown
files,
because,
like
the
the
the
editing
that
I've
shown
this,
I
just
I've
just
showed
you
it's
for
markdown
files,
so
only
markdown
files
have
all
those
buttons
right.
A
That
might
be
it
yeah
that
that
that
might
work
out
as
well
or
even
to
to
make
it
even
minimum,
because
technically
the
mvp
should
not
depend
on
the
functionality
that
we
provide
as
the
file
tree
right.
So
so,
as
the
mvp
I
would
say,
the
easiest
way
would
be
to
to
actually
introduce
that
full
screen
button.
B
A
A
B
So
where
I
was
coming
from
with
that
comment
was
in
the
merge
requests
view
there
is,
there
is
a
tree
kind
of
like
there's
an
area
for
a
list
of
files
and
that
kind
of
occupies
the
say.
Well,
it
pushes
the
code
file
over
a
little
bit.
Would
it
be
it
to
me?
It
feels
like
that's
okay
from
a
space
wise,
but
because
it
feels
like
there
will
be
enough
space
to
edit
and
then
having
the
full
screen.
A
B
B
A
A
This
is
this
is
an
interesting
thing
to
think
about
how
we
allow
users
to
preview
the
changes,
considering
that
the
actual
commit
button
and
commit
message.
Interface
is
different
from
web
ide,
and
we
should
support
both
the
single
file.
Editor
experience,
as
we
have
now,
without
any
disturbance
or
actually
showing
changes
even
for
one
file,
probably
is
a
good
idea
as
well.
B
A
A
A
A
A
We
have
the
tool
we're
talking
about
the
toolbar
once
you
start
making
the
changes.
The
toolbar
shows
the
preview
changes
button
once
user
clicks
that,
instead
of
the
editor
interface,
we
technically
show
the
tabular
interface
as
it
is
in
the
in
the
web,
id
the
tabular
interface
with
one
changed
file
at
a
time
that
would
be
simple
to
implement
or
like
okay
like
much
simpler
than
the,
if
you
below
actually
so
that
that
way,
we
would
show
this
as
the
web.
Id
interface
provides
us
with
at
the
moment.
B
B
I
have
another
random
idea
if
you're
in
the
single
file,
edit,
the
source,
editor
and
you're,
editing
something
if
we
had
a
button
that
says
edit
multi
files
or
you
know,
the
label
can
change
whatever.
But
if
you
click
on
it,
it
actually
opens
up
the
web
ide.
Currently
with
that
page
and
it's
changes
applied,
and
then
this
way
we
would
already
have
the
file
tree.
B
We
would
already
have
the
changes
and
commits
and
other
like
the
changes
per
file,
and
this
would
potentially
give
us
a
signal
whether
we
should
make
it
integrated
into
the
source
editor
or
like
live
this
limbo
it
world.
I
think
if
people
do
that
and
the
follow
through
with
that
flow,
then
then
we're
like
okay
cool
there's
something
here
that
we
can
like
double
down
and
move
this
functionality
over
to
the
source,
editor
versus
trying
to
recreate
every
recreate
the
wheel.
A
Yeah,
so
totally
that
that
might
work.
That's
that's
what
I
told
that
we
might
introduce
the
web
id
button
in
the
single
file
editor.
So
using
this
like
adding
this
to
the
toolbar
might
be
a
very
good
iterative.
First,
stop
to
actually
and
again
start
getting
the
information.
There
are
two
things
to
to
keep
in
mind.
A
Disturbed
experience
so,
like
discrete
one,
so
we
are
here
when
we
click
the
web
id
the
new
tab
gets
open.
We
have
to
be
redirected
there.
The
second
one
is
we
do
not
at
the
moment.
We
are
in
this
like
completely
hectic
week
where
we
don't
know
what
happens
to
web
ide
and
how
all
that
thing
will
work
with
vs
code,
and
that
part
is
like
for
the
for
the
time
being.
B
B
C
B
A
The
the
paths
that
I
would
take
are
first
is
yeah.
We
create
an
issue
like
we
have
to
be
done
with
the
toolbar
mvp.
Then
we
we
should
have
the
issue
to
add
this
button
like
go
to
like
editing
web
id
right
there
in
the
single
file
editor.
So
we
click
that
button.
We
have
to
preserve
the
changes
we
redirect
web
id
with
those
changes
preserved
and
that's
that's
the
very
good
first
step
for
iteration.
C
B
A
Cool
very
good.
I
think
that
that
that
makes
a
lot
of
sense,
and
I
I
I'm
I'm
really
excited
about
this
work,
because,
especially
now
in
the
light
of
this
code
coming
to
the
play
and
from
from
what
I've
seen
I
I
really
don't
think
unless
there
are
some
product
concerns
I've
about
about
the
overall
thing
like
technically
it's
it's.
It's
really
great.
A
A
They
won't
be
familiar
with
this
interface.
Moreover,
not
every
developer
is
a
user
of
vs
code
like
I'm
using
jetbrains
products.
I
I
do
know
how
vs
code
works,
but
it
doesn't
sort
of
give
me
any
any
real
benefits,
because
I
don't
know
what
extensions
to
use.
So
I
will
look
at
this
as
a
new
user
as
well,
so
we
might
still
want
to
give
users
an
alternative
in
case
they
feel
really
about
like
just
document
changes,
but
not
opening
the
the
real
ide
application.
B
Yeah
those
concerns
make
sense
when
I
first
saw
the
video
I
thought
about
it,
and
I
was
like
to
me.
The
web
ids
layout
reminds
me
a
lot
of
vs
code.
You
know
with
the
tabs
on
the
side
and
just
the
general
structure
and
the
layout
so
to
me
that
that's
why
my
one
comment
is
like:
can
we
style
it
to
look
like
the
web
ide
because
there's
like
it's
roughly
like
tabs
on
the
side
content
file,
tree
content
but
yeah
yeah?
B
A
Thank
you
very
much
for
setting
setting
this
up
and
I'm
looking
forward
for
us
to
to
get
to
those
those
changes
to
to
to
be
able
to
provide
multifile
and
editing
capabilities
for
for
the
single
file
editor
users.
That
would
be
very
exciting
to
see
the
data
of
how
many
like,
because,
again
before
we
get
the
data,
it's
all
about
speculations
like
whether
users
even
need
this.