►
Description
Mosaic - A Rusty Terminal Workspace and Multiplexer
Mosaic is an open-source terminal multiplexer being developed in Rust (https://github.com/mosaic-org/mosaic)
This talk will introduce the project, talk about its architecture, and some of the ways Rust is unique in helping us build it (eg. webassembly and WASI for our plugin system).
Aram on Twitter: https://twitter.com/im_snif
Rust Linz:
https://twitter.com/rustlinz
https://sessionize.com/rust-linz
https://rust-linz.at
A
So
yeah
thanks
for
having
me
first
of
all
and
thanks
carl
carl,
for
this.
Like
great
talk,
I
was
like
kind
of
generally
aware
there
was
this
whole
ecosystem
of
community
of
like
documentation
with
lake
and
rust,
but
I
haven't
had
a
chance
to
get
into
it
and
like
I'm
still
at
the
stage
of
being
blown
away
by
markdown
inside
comments,
so
very
cool.
Thank
you
for
that
talk
and
yeah.
A
A
It
could
can
also
allow
you
to
have
like
different
tabs,
like
you
have
in
the
browser,
and
also
to
maybe
sometimes
kind
of
detach
from
your
current
session,
close
your
terminal
window
and
open
a
new
terminal
window
and
reattach
that
session.
For
those
of
you
who
have
used
tmux
or
screen
in
the
past,
both
of
them
are
terminal.
Multiplexers
and
mosaic
is
the
new
one.
We
are
building
right
now
in
rus.
A
It's
important
for
me
to
start
by
saying
that
I
use
like
the
plural
sometime
in
this
presentation,
because
this
project
does
not
belong
to
me,
not
just
because
ownership
is
theft,
but
because
there
is
a
whole
team
around
this
project.
We
are
an
open
source
project.
We
are
eight
now
and
while
I
started
this
project,
I
see
myself
now
as
a
part
of
the
team,
so
shout
out
to
all
the
mosaic
team.
A
So
in
order
to
tell
like
the
idea
behind
mosaic,
because
it
is
not
just
a
terminal
multiplexer,
I
want
to
talk
a
little
bit
about
what
brought
me
to
build
it,
and
for
that
I'll
tell
you
a
little
bit
about
myself.
So
I
started
out
my
development
career
in
operations
where
I
was
a
devops
engineer
and
most
of
the
development
I
did
was
like
writing
pearl
and
bash
scripts.
A
So
the
like
editor,
I
used
in
order
to
do
that
was
vim
over
the
years.
As
I
moved
away
from
like
devops
into
more
traditional
development
like
software
development
roles,
then
I
still
kind
of
stuck
with
them,
and
this
is
the
editor
I
use
today
to
write
any
language
like
javascript
rust,
even
some
python,
sometimes
so.
A
A
I
saw
it
as
being
taking
tmox
and
moving
it
to
the
desktop,
so
I'm
able
to
open
multiple
terminal
windows,
each
one
of
them
having
like
the
vm,
editor
open
command
line
like
I
was
enabling
tmux,
but
also
having
a
browser
window,
and
such
this
also
allowed
me
to
build
a
kind
of
an
automation
around
it.
In
order
to
have
like
automated
tasks
of
having
one
pane
spawning
other
things
and
such
and
yeah,
I
guess
I
I
I
want
to
show
this
to
you,
so
this
is
what
I'm
talking
about.
A
B
B
A
A
Amazing,
thank
you
very
much.
Okay,
so
yeah,
as
I
was
saying,
this
is
kind
of
my
desktop
environment.
Right
now
we
can
see
three
terminal
windows
here,
the
like
in
the
middle
we
see
like
an
editor
zim
window
and
on
the
bottom
we
see
a
terminal
that
I
can
use
in
order
to
run
tests
and
like
look
around
the
file
system
and
such
and
on
the
left,
we
see
it's
an
application
in
case
you
don't
know
it.
It's
called
ranger.
A
What
happens
here
is
that
ranger
kind
of
starts
like
a
bash
script,
which
talks
to
like
i3
figures
out
the
like
the
arrangement
of
the
windows
and
figures
out
where
to
open
like
a
new,
a
new
terminal
thing,
so
you
can
do
that
like
with
a
few
things.
So
this
is
what
I
used
for
development
for
a
while,
and
so
this
was
nice.
A
It's
good,
it's
productive
for
me,
but
the
problem
is
that's
like
moving
to
a
different
like
computer
is
something
I
fear
this
is
as
I
alluded,
this
is
kind
of
a
soup
of
bash
scripts
right
now,
so
it's
a
highly
configured
environment,
that's
highly
specific
and
not
very
transferable,
to
other
machines,
not
to
mention
other
people.
If
I
want
to
like
to,
if
someone
sees
this
and
says
hey,
this
is
cool.
How
do
I
work
like
this
too?
A
A
I
have
this
kind
of
development
environment
that
I
created
for
myself
and
to
like
formalize
it
by
formalizing
it
I
mean
to
create
an
infrastructure
that
would
allow
me
to
describe
this
terminal
and
by
this
sorry,
this
a
development
environment
in
a
like
configuration
file
like
a
yaml
file.
That
would
be
brief
and
would
like
I
would
be
able
to
transfer
it
to
any
other
computer
running
that
same
infrastructure.
A
But
now,
like
the
first
thing
I
would
like
to
talk
about,
is
they
get
into
more
of
the
technical
side,
because
this
is
a
rasmus?
After
all,
to
talk
a
little
bit
about
how
a
terminal
multiplexer
actually
works.
Multiplexer
here
is
in
parentheses,
because
first
I
want
to
talk
about
how
a
terminal
actually
works
after
we
do
that
and
we're
kind
of
on
the
same
page
about
like
the
product
we're
talking
about.
A
B
A
This
would
allow
any
developer
to
like
write
a
plugin
for
all
of
this
in
any
compiled
language,
be
it
rust,
go
assembly,
script
or
anything
and
to
have
that
be
kind
of
a
small
applet
within
the
application.
For
example,
if
you
see
in
the
range
or
the
file
explorer
that
I've
seen
before
we,
our
first
plugin
is
a
clone
of
ranger.
That
would
allow
us
to
run
something
like
that
within
pain
without
having
it
to
actually
having
like,
without
it
being
forced
to
actually
be
installed
on
the
computer.
A
A
If
this
is
something
that
interests
you
then
like
these
will
be
like
a
nice
nice
bulletin
list
of
places
you
can
like
insert
yourself
in
the
project,
so
I
want
to
show
you
the
project
itself
and
how
it
is
now
and
before
I
do
that
I
will
mention
that
mosaic
is
kind
of
in
the
late
early
stages.
So
it's
not
a
hundred
percent
stable.
A
I
use
it
myself
as
part
of
my
ide,
like
I
use
mosaic
in
order
to
develop
mosaic,
but
it's
not
like
100,
so
we
are
stabilizing
it.
But
like
please,
forgive
me
if
this
crashes,
so
once
you
clone
the
project,
you
do
a
cargo
run
and
then
we
see
like
immediately
you
get
a
command
line,
which
is
your
default
command
line
like
the
shell.
I'm
using
is
fish.
A
Okay,
so
here
on
the
bottom,
we
can
see
the
status
bar,
so
the
status
bar
is
part
of
the
default
layout
of
mosaic.
An
interesting
thing
is
that
this,
the
status
bar
is
a
plugin.
It
was
written
in
rust
but
compiled
to
webassembly
and
then
imported
by
default,
like
as
part
of
the
default
layout
into
rust
into
this
into
mosaic.
Sorry.
A
So
here
it
shows
us
like
the
key
bindings
so
that
we
don't
have
to
remember
all
the
things
that
we
can
do
and
I'll
clear
here
the
room
to
give
me
my
mouse
back
and
yeah.
So
if
I
do
control
g,
it
gives
us
like
all
all
of
our
current
capabilities.
We
are
able
to
split
the
window
vertically
to
split
it
horizontally.
A
We
are
able
to
do
all
the
terminal
stuff
open,
a
vim
window
like
scroll
through
it
and,
of
course,
use
the
most
important
like
command
line
application.
This
is
mosaic
right
now
kind
of
similar
to
tmox.
But
that's
because
we're
looking
for
like
tmx
is
our
infrastructure
layer,
as
I
mentioned
so.
The
first
thing,
we're
kind
of
doing,
is
kind
of
have
a
feature
parity
with
it
to
be
able
to
like
do
all
the
things
that
it
does
and
build
on
top
of
it.
A
So
moving
on
I'm
going
to
talk,
as
I
said,
about
how
a
terminal
actually
works.
Forgive
me
if
you
already
know
this
I'm
going
to
like
talk
about
a
little
bit
of
basic
concepts,
but
please
bear
with
me.
I
just
want
everyone
to
be
on
the
same
page,
I'm
going
to
go
into
more
advanced
topics
that,
unless
you've
dealt
very
deeply
with
terminals,
maybe
like,
maybe
they
will
be
new
for
you.
So
first,
what's
the
actual
difference
between
a
terminal,
emulator
and
the
shell?
A
Both
are
applications
that
run
on
your
operating
system
and
like
communicate
with
each
other.
The
terminal
emulator
is
the
like
the
black
window
that
you
open
in
your
operating
system,
black
or
white,
depending
on
your
theme
and
like
it's
in
charge
of
displaying
the
text
on
screen,
displaying
like
textual
user
interfaces
and
such
and
is
in
charge
of
the
scroll
buffer.
A
So
if
you
scroll
up
and
down,
if
you
had
like
a
long
command
and
want
to
scroll
up,
that's
the
responsibility
of
a
terminal
emulator,
the
shell
gets
user
input
from
the
terminal.
Emulator
spawns
different
processes
such
as
top
or
ls,
and
sends
its
output
to
the
terminal
emulator
with
instructions
of
how
to
display
it.
Both
of
these
are
connected
by
the
pty.
A
A
A
A
A
A
It's
like
a
function
parameter
34
tells
the
emulator
to
display
the
like
the
following
text
and
what
it
defines
as
blue,
because
these
are
things
that
the
terminal
emulator
can
change
itself.
It's
possible
to
send
more
specific
instructions
like
with
rgb
and
such,
but
for
simplicity.
I
chose
like
the
fixed
stuff
after
this,
it
sounds
like
plain
text,
hello
and
the
terminal
emulator
displays
it
in
blue.
A
A
A
Such
as
vim
and
top
so
aside
from
styling
instructions,
we
need
a
few
basic
things.
We
need
to
be
able
to
send
cursor
movement
instructions
to
tell
like
the
terminal
to
move
its
cursor
to
this
column
and
this
line,
and
then
we
need
like
box
drawing
characters.
We
can
see
the
table
of
them
here
in
the
picture.
A
A
A
This
is
nice,
but
it
does
like
present
some
problem,
as
we
mentioned
for
fixed
content,
because
then
this
happens.
If
we
see
here
on
the
left,
we
have
like
a
like.
Let's
imagine,
the
fixed
content
like
status
bars
on
the
top
and
bottom
and
and
then,
when
we
add
new
line
they're
like
shifted
upwards.
A
So
that's
not
what
we
want
to
do.
This
is
a
self-portrait
by
the
way.
So
the
solution
to
this
is
scroll
region.
Scroll
regen
is
like
a
csi
instruction,
just
like
the
styling
instructions.
This,
as
you
can
see
here,
the
instruction
is
r.
It
tells
the
terminal
that
from
line
two
to
line
four
is
the
scroll
region.
So
this
is
something
that
needs
to
be
treated
just
like
the
scroll
buffer
and
the
terminal
does
the
rest.
A
So
whenever
a
new
line
is
added,
assuming
the
cursor
is
within
the
scroll
region,
then
like
everything
above
and
below
it
stays
the
same
and
like
it
kind
of,
does
the
right
thing
in
the
middle.
The
astute
watchers
here
will
notice
that
the
csi
instructions
in
general
are
one
indexed
rather
than
zero
index,
and
you
can
imagine
how
fun
it
is
to
to
program
if
you
want
to
but
position
lines
in
a
vector,
for
example,
something
to
keep
in
mind.
A
A
On
the
other
hand,
we
also
don't
want
to
keep
these
handsy
strings
on
the
terminal
character.
We
want
to
interpret
them.
The
reason
for
this
is
that,
if
we
kept
the
string
on
the
terminal
character,
then
each
time
we
allocate
a
terminal
character,
it
would
happen
on
the
heap
rather
than
on
the
stack,
and
that,
like
is
a
very,
very
big
blow
for
performance.
A
A
A
This
is
important
because,
if
you
imagine
like
expanding
the
terminal
window
and
having
to
like
unwrap
lines,
then
we
don't
want
to
unwrap
like
unwrap
lines
that
are
canonical,
because
then
you'd
have
like
something
that
clearly
needs
to
be
the
start
of
the
line
like
stuck
to
the
line
before
it,
and
that's
not
what
you
want
so
moving
further
up.
We
have
the
grid.
A
The
grid
has
the
viewport
which
is
what's
displayed
currently
on
the
screen
of
the
pane,
which
is
a
vector
of
these
rows.
We
have
the
lines
above
and
the
lines
below
which
we
use
for
scrolling
and
we
also
keep
track
of
the
cursor,
which
is
just
the
x
y,
coordinates
of
the
cursor
on
the
screen.
If
we
have
a
scroll
region
and
keep
track
of
the
top
and
bottom
line
of
the
scroll
region
and
keep
track
of
the
width
and
height
of
the
grid
to
be
able
to
like
resize
it
as
needed.
A
And
yeah
now,
if
zoom
will
give
me
my
mouse
back,
I
will
move
next,
so
this
is
like
kind
of
how
a
terminal
work
works
and
how
it
is
implemented
in
mosaic.
Now
I
want
to
like
move
like
zoom
out
and
look
at
what
the
terminal
multiplexer
is
so
taking
mosaic.
As
an
example,
mosaic
takes
the
place
of
the
shell,
but
of
course
it
can.
The
shell
can
also
defer
to
it.
A
Of
course,
like
you
can
start
your
terminal
and
start
mosaic,
and
it
stands
between
the
like,
like
between
the
on
the
other
side
of
the
pty
from
the
terminal
emulator
so
and
then
it
does
the
splitting
in
several
ptys
on
its
own
and
decides
like
it
takes
all
that
all
the
like.
The
nc,
vt
100s,
vertex,
et
cetera
instructions
that
we
get
from
the
pty,
creates
an
internal
state
and
then
decides
how
to
draw
that
state
to
the
terminal
emulator.
A
A
What
we
also
see
here
is
the
plugins
that
I,
like
kind
of
touched
on
before
the
plugins,
don't
have
their
own
pty
they're.
Just
they
just
stop,
have
an
internal
api
that
they
use
to
communicate
with
mosaic,
and
we
don't
need
to
like
have
the
operating
system
in
charge
of
our
communication
pipe.
We
just
do
it
on
our
own,
so.
A
So
if
we
look
at
the
architecture
of
mosaic
itself,
like
we
zoom
into
the
mosaic
part
of
that
diagram,
the
mosaic
is
built
out
of
like
three
main
threads,
there's
the
std
and
threads,
which
is
in
charge
of
like
getting
the
user
input
from
keyboard
or
mouse.
The
pty
thread,
which
is
in
charge
of
opening
all
these
pty
connections
with
the
operating
system,
keeping
track
of
them.
A
It
has
like
async
streams
that
use
in
order
to
read
them,
so
they
won't
block
each
other
if
they
can
get
a
lot
of
characters
on
one
of
them
and
we
have
the
screen
thread,
which
is
in
charge
both
of
deciding
what
should
be
on
screen,
which
is
the
focus
tab
which
terminals
should
be
drawn
and
also
of
keeping
track
of
the
state
of
these
terminals.
So
when
I
say
state
I
mean
what
text
is
displayed
in
them
like.
A
When
I
created
this,
I
elected
not
to
use
shared
memory
in
the
form
of
like
arc
mutex,
but
instead
for
all
of
these
to
communicate
with
like
mpsc
channels.
In
case
you
haven't,
used
mpc
in
the
past.
This
stands
for
multi-producer
single
consumer.
It's
a
way
to
send
messages
fast
in
memory
without
having
to
like,
for
example,
with
an
arc
mutex.
A
You
have
to
like
lock
a
certain
part
of
memory,
and
only
one
thread
can
interact
with
it
and
the
time
at
the
time
and
when
another
thread
wants
to
talk
to
it,
it
has
to
like
wait
for
it
to
be
released.
So
this
is
both
the
using
an
mpsc.
It
just
shoots
the
message:
it's
both
faster,
like
it's
more
performance,
which
is
especially
important.
A
A
If
we
want
to
eventually
move
these
threads
to
different
processes
so
like
it
would
be
much
easier
to
already
be
able
to
just
switch
out
the
mdc
channel
for
ipc,
for
example,
let's
take
a
look
at
an
example
of
like
an
action
that
can
happen
and
how,
like
it
moves
between
threads,
so
we
start
with
the
std
and
threads.
We
get
control
gm,
it's
kind
of
a
temporary
shortcut,
we're
still
working
out
the
shortcut.
A
A
Do
your
thing
with
it,
so
the
screen
thread
finds
the
like
largest
empty
space
and
sends
like
a
message
back
to
the
pty
thread,
telling
it
resize
this
id
to
this
size.
You'll.
Remember
that
this
is
important,
because
the
pty
one
of
the
state
that
it
keeps
is
like
how
large
the
like
the
terminal
window
is
so
that,
like
uis,
will
be
able
to
query
it.
A
So
then
pty
threads
talks
to
the
os
and
tells
it
to
like
change
the
silent
size
of
the
of
the
like
pty
that
it
opened
before.
So
this
is
one
example.
We
can
also
imagine
like
an
example
with
the
std
in
thread
communicating
directly
with
the
screen
thread,
for
example,
if
we
want
to
resize
a
pane,
so
it
would
send
this
command
to
the
screen
thread
and
then
the
screen
thread
will
then
send
the
resize
to
the
pty.
A
This
was
all
this
is
like
nice,
but
like
after
I
I
created
this.
When
other
developers
started
hacking
on
the
project,
then
this
like
it
started
to
be
a
little
bit
confusing,
especially
if
you're
a
developer
that
isn't
like
intimately
familiar
with
how
the
app
works
and
you
get
like
a
stacked
phrase
like
a
crash.
A
A
So
you
don't
really
know
this
whole
story
of
where
the
message
got
and
what
initiated
this
and
such
it
can
be
like
more
complex
examples
than
this
and
generally
like
debugging.
It
is
not
the
the
funnest
thing
in
the
world,
so
one
of
the
people,
one
of
the
other
people
on
the
team,
implemented
like
an
error,
handling
mechanism.
For
this.
A
What
we
did
is
we
took
the
mpsc
senders.
We
wrapped
them
in,
like
kind
of
our
own
custom,
struct
that
you
can
see
here
and
we
kept
the
same
api.
So
we
can
still
use
them
to
send
messages
to
other
threads,
exactly
as
you
as
you
could
before.
But
you
can
also
update
them
with
a
custom
error
context
in
our
context,
like
it's
not
displayed
here,
but
it's
basically
like
just
a
textual
lines
of
or
enums
that
can
be
serialized
into
textview
alliance.
A
So
webassembly
allows
us
to
like
precompile
rust
code
into
a
webassembly
asset
and
then
load
it
at
runtime
into
like
into
an
application.
So
the
ui
for
this
can
be
as
easy
as
taking
a
url
of
a
webassembly
asset
and
like
github
releases
somewhere
loading
it
into
your
application,
giving
it
permissions.
And
then
you
have
a
pain,
you're
already
running
application.
A
A
How
does
it
actually
work
in
our
philosophy?
Each
plugin
is
a
separate
pane,
like
you've,
seen
the
status
bar,
for
example.
If
you
want
to
have
an
experience
that
is
multiple
things,
then
you
write
two
plugins
that
communicate
with
each
other
or
one
plugin
that
you
open
twice
and
does
like
different
things
depending
on
what
it
is.
We
have
like
a
message,
or
we
plan
to
have
like
message,
buses
and
such
this.
The
website
system
has
been
merged
into
main,
I
think
two
or
three
weeks
ago.
A
So
everything
is
like
kind
of
new
and
shiny.
You
write
a
rost
application
or
go
application
or
assembly
script,
application
or
c
plus
plus
application,
and
then
that
application
just
renders
itself
through
std
out.
It
can
be
as
simple
as
a
print
statement
or
it
can
use
old,
nc
vt100
goodies
that
we
talked
about
before.
If
you
want
to
do
that,
I
would
warmly
recommend
using
a
framework
which
would
make
your
life
a
little
bit
easier.
If
we're
in
rust
world.
A
I
very
much
recommend
tui,
which
is
a
really
cool
terminal,
ui
framework,
and
in
order
to
have
this
compiled
webassembly
assets
interact
with
the
operating
system.
We
use
something
that's
called
wassi
in
case
you
haven't
heard
of
it.
I
think
don't
like
catch
me
on
this.
I
think
it
stands
for
webassembly
server
interface,
and
this
allows
the
application
to
use
its
native
like
file
system
interaction,
module
and
talk
to
the
operating
system,
but
only
to
the
parts
that
you
give
it
permission
to
talk.
A
So
if
I'm
using
it
to
code,
they
would
only
give
it
permission
to
talk
to
the
like
to
my
repo,
essentially
to
the
place
on
my
hard
drive
in
which
I
hold
it
and
then
like.
If
it
does
crazy
stuff,
I
have
I
have
it
so
I
have
it
all
in
github
or
in
git
somewhere,
one
should
hope
right
now
we
tried
and
it
works
with
interacting
with
the
file
system
in
the
future.
A
We
hope
I'm
just
not
sure
what
the
state
of
losses
in
this
area,
but
we
hope
to
have
it,
interact
with
a
network,
for
example,
and
other
like
os
layer
stuff.
To
give
an
example
of
this,
I'm
going
to
start
mosaic
with,
like
a
layout
that
loads
a
plug-in.
That's
right.
Now,
that's
our
way
to
you
to
load
plug-ins
until
we'll
create
some
sort
of
ui.
That
does
this.
A
If
you
remember
from
the
at
the
beginning
of
the
talk,
I
showed
my
development
environment
and
they
showed
like
ranger,
which
is
the
file
system
explorer.
Our
first
plugin
written
by
a
member
of
the
team,
is
called
strider,
which
is
a
ranger
clone,
as
you
might
notice.
We
are
a
little
bit
of
tolkien,
geeks
and
strider.
This
is
a
webassembly
plug-in
that
is
not
running
on
the
operating
system.
A
It's
running
like
it's
part
of
mosaic
and
one
can
use
it
to
like
explore
the
file
system,
go
up,
go
down
and
even
use
an
api
in
order
to
open
panes
in
mosaic.
What
happened
here
is
that
the
api
sent
the
open
new
pane
command
with
a
file
path
and
mosaic
used.
The
system's
default
editor,
in
my
case,
it's
vim
in
order
to
open
a
pane
where
it
has
the
most
space.
We
can
do
that
we
can
open
one
we
can
open
like.
A
So
this
is
about
how
we
do
it
with
like
webassembly
and
what
we
have
right
now.
These
are
the
two
plugins
right
now
in
existence,
but
in
the
future,
like
one
can
imagine
a
lot
of
stuff
that
we
can
do
with
plugins
personally,
the
the
plugin
that
I'm
most
excited
about
that.
I
hope
someone
will
write
in
the
future,
or
maybe
I
will
get
to
it
is
like
have
a
rust,
analyzer
or
cargo
check
like
if
you
can
imagine.
Sometimes.
A
A
We
call
it
a
mosaic
tile,
which
gives
you
a
trait
that
you
can
implement
and
once
implementing
that
trade
it
has
like
in
it
to
do
some
like
startup
stuff
and
then
draw
which
is
called
every
time
like
that
mosaic
needs
to
render
you
and
it
gives
you
like
the
size
and
such
and
also
allows
you
to
handle
keys
and
stuff,
and
such
this
is
all
on
github.
You
can
check
it
out
like
there
is
nick
something
else
that
we
want
to
do
with
our
architecture.
A
I
mentioned
at
the
beginning
of
the
lecture
that
terminal
multiplexers
team
ups,
for
example,
can
do
like
a
sort
of
client
server
thing
which
allows
you
to
connect
to
a
session
work,
open
things,
do
your
stuff
and
then
detach
from
it
close
the
terminal
window,
open
the
terminal
window
again
reattach
to
the
session
and
continue
your
work.
This
is
especially
powerful
if
you're
like
on
a
remote
server,
for
example.
A
A
For
example,
we
can
imagine
a
plugin
that,
like
knows
when
one
person
is
editing,
struct
and
another
person
is
editing
the
implementation
of
that
struct,
and
then
it
can
like
give
a
certain
warning
change
the
color
of
the
status
bar
or
something
tell
you
hey.
Maybe
you
want
to
like
check
with
the
other
person
to
make
sure
you're
not
like
contradicting
each
other
and
yeah.
A
I
think
the
fun
thing
about
the
plug-in
system
is
that
probably
the
coolest
plug-ins
are
the
ones
that
I
do
not
think
about
the
people
implementing
them
well
in
the
future,
like
this
kind
of
gets
into
like
science
fiction
territory,
because
these
are
things
that
I
hope
will
happen.
I
have
a
general
idea
about
how
they
can
happen
but,
like
I,
don't
see
it
yet.
I'm
saying
it
here,
not
because
I'm
saying
this
is
like
my
plan
or
my
road
map.
A
A
I
also
think
it
can
be
cool
to
do
the
same
thing
with
like
econ
dx
windows,
desktop
environment,
to
be
able
to
open
different
terminal
windows
for
each
terminal,
pane
of
the
session
that
you're
connected
to,
and
maybe,
if
we're
taking
the
plugins.
Maybe
we
can
even
find
some
way
to
interpret
the
textual
user
interface
into
an
actual
interface
that
will
be
displayed
on
x
windows.
A
If
one
is
connected
with
that
client-
and
maybe
even
by
the
way,
I
find
a
way
to
write
a
vs
code
plugin
that
would
like
kind
of
sync
it
with
a
mosaic
session,
and
then
one
person
can
use
vs
code.
Another
another
person
can
use
the
terminal
emulator
and
such
I
would
also
like
to
extend
the
layout
system.
Currently,
we
have
a
layout
system
in
mosaic
that
one
can
like
start
it
with
an
argument
to
a
yaml
file.
A
I
would
like
to
extend
it
and
create
some
sort
of
language
that
would
allow
one
to,
for
example,
borrow
a
page
from
like
web
development
and
be
able
to
change
the
layout
depending
on
the
size
of
the
screen.
So
when
we
resize
the
terminal
window
not
just
to
have
like
the
panes
resize
themselves
relative
to
how
they
were
before.
A
B
A
It
can
conceivably
even
be
a
service
on
the
net
that
you
connect
to
keep
your
sessions
and
such
so
after
we've
talked
about
like
the
idea
behind
mosaic
what
it
is
now
we've
shown
some
depth.
Some
demos
went
to
the
technical
part
like
every
open
source
project
and
every
like
project
in
general
has
like
kind
of
a
story
behind
it.
A
So
I
want
to
share
you
a
little
bit
how
the
beginning
of
mosaic
was
for
me
when
I
started
creating
it
like
a
month
or
two
months
after
it
like
the
task
was
daunting.
It
was
big.
It
was
far
bigger
than
I
thought
it
was
than
I
thought
it
would
be,
as
happens
a
lot
to
us
after
developers,
as
I'm
sure
you
can
relate,
and
I
wasn't
close
to
giving
up,
but
I
was
very
frustrated.
A
So
I
talked
to
a
friend
who
is
now
like
he
was
the
second
ever
maintainer
of
mosaic
and
he
advised
me
to
open
the
project
up.
Just
take
it
as
is
make
it
public
get
other
people
involved.
I
eventually
took
his
advice,
but
it
was
one
of
the
harder
things
that
I
did
because
you
know.
Of
course,
the
project
is
not
ready,
it
can't
be
shared
before
it
is
ready,
but
that
was
wasn't
the
right
way
to
think
about
it.
A
Sharing
the
project
allowed
other
people
to
get
involved
like
kind
of
on
the
ground
level
and
made
the
project
like
not
mine,
but
a
team
effort.
It
would
not
be
close
to
where
it
is
today
without
the
team.
It
probably
would
not
be
so
I'm
incredibly
grateful
to
that
advice,
and
I
want
to
give
that
advice
to
you.
A
If
you
take
nothing
else
from
this
talk,
please
remember
that
if
you
have
a
project
and
you're
kind
of
frustrated
about
it
before
giving
up
on
it
open
it
up
like
when
I
opened
mosaic
up,
it
was
like
there
were
some
files
which
were
2
000
lines
of
code
long.
It
was
like
really.
I
was
I
kept
feeling
that
I
have
to
apologize
for
this
code,
but
that's
not
in
my
opinion.
That's
not
the
right
way
to
think
about
it.
A
As
promised,
some
problems
that
we're
working
on
today,
where
the
project
is
I'm
mostly
concentrating
on
fixing
so-called
compatibility
issues,
which
is
places
where,
like
you,
would
work
with
mosaic,
it
would
work
with
like
lots
of
different
paints
and
run
stuff
into
pains
and
then
stuff
would
either
crash
or
not
behave
correctly.
The
colors
would
be
wrong.
The
lines
would
be
wrong
and
such
so
I'm
fixing
these
like
squashing
them
one
by
one.
A
This
effort
is
kind
of
close
to
its
end
when,
like
mosaics,
like
it
like
I'm
saying
this
carefully,
but
it's
starting
to
be
in
a
pretty
stable
place.
There's
still
work
to
do
here.
If
there's
something
that
interests
you,
I
would
also
want
to
flesh
out
the
layout
system,
as
I
mentioned
before,
doing
all
the
like
a
conditional
layout
and
creating
like
a
domain
language
inside
of
the
yaml
files.
I
think
it
can
be
like
a
pretty
fun
project.
A
A
A
I
would
like
to
end
with
this
quote
from
my
favorite
software.
Philosopher,
douglas
adams
wrote
him
a
salmon
of
doubt
should
not
have
to
be
tyrannized
by
application
developers
who
don't
know
the
first
thing
about
how
actual
people
do
their
actual
work.
We
should
be
able
to
just
pick
up
the
bits
we
like
and
place
them
in,
and
I
think
it
could
be
pretty
cool
if
this
becomes
like
a
workspace
that
people
use
can
just
take
parts
of
applications
that
they
want
paste
them
in
and
work
the
way
they
want.
A
Thank
you
very
much,
thank
you
for
to
russ
lims
for
like
having
me.
Thank
you
for
your
time
for
listening
to
this
talk.
If
mosaic
is
something
that
interests
you
please
visit
us,
I'm
alan!
You
can
follow
me
on
twitter.
I
sometimes
like
write
about
like
terminal
stuff
or
in
github
and
yeah.
Please
join
by.
A
We
also
have
a
discord
server
if
you
want
to
like
learn
more
about
the
project
and
how
you
can
get
involved,
we're
a
friendly
and
welcoming
bunch,
no
matter
your
experience
level
we'll
be
happy
to
have
you
and
I'll
try
to
stick
around
on
the
like
rust
discord,
server
in
case,
you
want
to
talk
to
me
or
have
questions
or
can
ask
me
right
now,
yeah.
Thank
you
very.