Writing An Editor In Elixir -- Elixir for GUIs? Yes, it’s possible. I’m working on a modern editor in Elixir, and I’ll show you how I’m doing it. Topics will include GUI libraries for Elixir, ports, NIFs, interfacing Elixir with other languages (especially Rust), and general design principles for a modern, programmable editor. https://elixirforum.com/t/14-elixirconf-2017-writing-an-editor-in-elixir-ian-duggan/8950 https://www.youtube.com/watch?v=6lIVWVmuPao Github: https://github.com/ijcd Twitter: @ijcd San Francisco, California SPEAKER NOTES: ------------- Why Design UI Tips I’ve always had an off fascination with editors. The answer, I believe, as to what makes a good editor, is when it makes us more productive. When it allows us to get into a flow. When it gets out of the way and just lets us create. I have a theory that, for some, it’s what makes you most productive quickly (TextMate, Sublime, Atom) For others, it is what you can control deeply (Emacs, Vi, Atom?). But if they are so hard to learn, why do they persist? Power... the power to control your environment (a true hacker wants to control everything... quote? reference?). But... why don’t people just add to Sublime/Atom/TextMate, etc... because of friction. My hypothesis is that the reason Emacs is so powerful, is that you can write emacs in emacs without leaving it it can grow as you use it. Others can too, to some extent, but not to the deep level of customizability you can get from Emacs... Not even vim can do this (which is why Spacemacs exsists... some people want the keys of vi with the features of emacs)... This editor had lisp embedded. It could read email and netnews before your cellphone could make phone calls without being attached to a car. You could customize it, from the very beginning. DECADES AGO. New editors are adding most of its features, except for the ability to CODE ITSELF WHILE RUNNING. Why is this a good idea? 1. Emacs <-> Vixen 2. C core, Elisp control <-> Rust core, Elixir control 3. Elisp <-> Elixir 4. Dynamic <-> Dynamic 5. Runtime eval <-> Runtime compile (hot code reload) 6. Macros <-> Macros 7. DSLs <-> DSLs 8. concurre-what? <-> concurrency 9. immuta-maybe? <-> immutable 10. beachballs <-> no beachballs (if designed well) Rust stuff might mess up your schedulers, Elixir string manipulations might cause GC issues — you need to profile and make a choice. That said, this is an editor and we are using Elixir more for the flexibility than the performance... Some issues around signals, detecting window size (in escripts) Use tty like iex (have user_drv open it), anoint self as shell Very much like unix. A process has a process group. IO is sent to the process group session leader. erlang:display goes around this. editor in control Rust/Termion ruby rust can launch w/out shell and insert ourselves as one can multiplex the shell in our own buffer pty/port-driver combo Telnet Port Driver

1. Writing an Editor in Elixir
today we’re gonna edit like it’s 1999

2. Just how are you
planning to bore me?

3. Why do this? Why???

4. Ok, get on with it
then.
(I only have to sit here for 45 minutes)

5. My story?
(the details of my life are quite inconsequential)

6. Initial release in 1974

7. Computer user since
1979
(core gamer, dude)

8. 1. BLOAD SUPERINV
2. <press play on tape>
3. <wait 10 minutes>
4. BRUN SUPERINV
(something like that — I was 5 in 1979)

9. 5. PLAY SPACE INVADERS!

10. Coding since 1982
10 PRINT “IAN ”
20 GOTO 10

11. Editing since 1993
(when I met my first love, Emacs)

12. Future roadmap?
(destination unknown)

13. So why not write an
editor?
(‘cause we need more of those…)

14. What makes an editor
successful?

15. Why do some come and
go while others persist?

16. Why do neckbeards
cling to 1970s tech?
(or does it cling to them?)

17. Why do hipsters insist on
editing through 20 layers
of abstraction?
(css goes well with a latte, and I’ve got 16 cores man)

18. In the beginning…

19. ED

20. ED

21. (still the best on a teletype…)

22. vi
(also created in 1976…)

23. vim
update in 1991

24. Smalltalk
(go wild man)

25. The GUI Era
“You’re Welcome”
— Java

26. Intellij / Eclipse /
Netbeans
(‘cause I like editing through a peephole)

27. "Modern" Editors
(yeah, man… air quotes)

28. TextMate
(because I’m smart enough to know that
Notepad is inadequate)

29. Sublime
(for when you need a break from broken Emacs)

30. Atom
“I use Atom cause I like mediocre editors”
— ElixirConf2017 Trainer

31. Please, what’s wrong with my
Atom?
(the whole point for me is it should just work)

32. Some of this may
have offended you
(and that’s an important clue)

33. It’s because, as programmers,
we often have a deep, personal
relationship with our editor.
(we’ve spent more time with it than anyone else!)

34. It’s about power and
productivity.
(sometimes a delicate balance)

35. So again, why do
this?

36. I love Emacs, but things
have been rough lately..

37. Maybe it’s a syntax
thing

38. And, as a hacker, I want
to write my own.. :)

39. And we have this great
language that is
simultaneously a perfect
and a terrible choice for
this.

40. Great because…
High level
Easy to develop in
Great for orchestration
Durability through OTP
Code reloading

41. Terrible because…
Mainly because the GUI ecosystem is
pretty limited
That just hasn’t been Erlang’s or
Elixir’s strength
I have arrows in my back to prove
this!!!

42. But we can fix this!

43. Let’s invent on
principle.
(or rather, in this case, shamelessly steal!)

44. A nice correspondence
Emacs Emx
C core Rust core
Elisp Elixir
Dynamic typing Dynamic typing
Code reloading Code reloading
Eval Eval
DSLs DSLs
Mutable Immutability
Beachballs Concurrency

45. Foundational Features
Programmable
Composable
Introspectable

46. Basic Design
Rust for low-level
(where necessary)
Back-end
(Elixir)
Front-ends
(text, GUIs)

47. Core / Back-end
Sessions:
have multiple buffers
shared or not
Buffers:
text, files, etc
rust-backed for performance (maybe?)
Event-maps:
map input actions to state transformations

48. Front-ends and
Sessions

49. Sessions

50. Front-ends

51. Buffers
defprotocol for multiple implementations:
• Sting-based
• Elixir “ropes”
• Rust “ropes”

52. Buffers

53. Buffers

54. Buffers

55. Buffers

56. Event-maps
Can be code or data
Stateless
Allows for easy code-
reloading

57. Key-code parsing

58. Key-code parsing

59. Ropes

60. Ropes
Basically a string as a
binary tree
Balancable

61. Ropes
Index(i): character at i, (log N)
Concat(S1, S2): concatenate two ropes, O(1) (or O(log N))
Split (i, S): split into two ropes O(log N)
Insert(i, S’): insert string at i O(log N)
Delete(i, j): delete the substring Ci..Cj, O(log N)
Report(i, j): output the string Ci..Cj, O(j + log N)

62. Elixir Ropes
I updated a library
Thank you @copenhas on github.
I did a PR.
Can I publish it to hex.pm?

63. Rust Ropes
In development.
Makes use of Ropes from the Xi
project.
Will integrate as Rustler resource
object.

64. Front-end
terminal
(tty_sl, others)
Wx
(:wx provided by OTP)
Electron
(just kidding, but why not, help me add it?)
Exui
(maybe? Boyd and I are already talking)

65. BEAM/OTP is 500k lines
of C code and 2.4 M lines
of Erlang code!
Atom / Electron is
scary?

66. Front-end protocol
Connect to backend, receive a session
Send input events (keys, mouse, etc.)
Receive output events, render
(sound familiar anyone?)

67. escript
mix.exs

68. mix.exs
escript

69. GenServer
escript

70. erl start options
—no-input
(don’t read input)
—no-shell
(don’t start the erl shell)

71. GenServer
escript

72. escript

73. IO.Ansi
IO.Ansi didn’t have cursor
movement stuff

74. Emx.Ansi
Maybe it should be core?

75. But there were some
issues
You can't have erlang shell or IEx
with it (terminal ownership conflict)
I couldn't get IEx —remsh working
wth it (even with elixir, mix, iex, etc
running)…
(someone please help?)

76. Maybe a port?

77. Do what IEx does?
IEx replaces the erlang shell
erl … -user Elixir.IEx.CLI

78. The erlang shell
There’s a great explanation of how it works here:
https://ferd.ca/repl-a-bit-more-and-less-than-that.html
I’ll summarize it quickly

79. “Old” shell

80. “New” shell

81. IO Protocol
Phoenix uses this during code
reload.
Basically send/receive bytes/
characters as messages.

82. Enables remote
shells

83. Replace tty_sl?
Let erlang think it’s in control
of the terminal.
We’ll secretly control the
terminal.

84. Run our back-end as
a port-driver?
It can own the terminal and
provide the shell.
This is really a variation of the
other ideas.

85. Use a pty?
We’ll can start erlang with a pty
so it thinks it owns the terminal.
This has the benefit of letting us
do other-language front-ends
that run a backend over the pty.

86. Remember this guy?

87. We can fake it with a pty

88. We can fake it with a pty

89. Rust-based PTY
Front-end
TODO: show termion code.

90. But why another node?

91. My old friend, telnet
The name stands for
"teletype network”
Basically “terminal over network”
This is a prototype, so start simply.
Eventually this should be SSH.

92. My old friend, telnet

93. Ranch Telnet
GenServer1

94. Ranch Telnet
Telnet.SessionHandler

95. Ranch Telnet
Telnet.SessionHandler

96. Let’s try connecting
telnet <my_ip_here> 5555

97. Wx
If you want to do cross-platform GUI work, your
options are really limited
They fall into a few basic categories:
Looks native on the platform (lowest common
denominator, WX)
Looks the same everywhere (consistency of
implementation over consistency of look)

98. :wx erlang module
:wx.observer
:wx.demo

99. :wx erlang module

100. :wx.wx_object

101. How to wrap the
constants

102. But this is tedious

103. So I wrote a library.

104. And then I found this post ! :)

105. WxWidgets
code wrapping
helpers for records and
constants
adapt for elixir idioms

106. Very basic, still needs
work
:wx wraps WxWindows directly… so…
All the arguments are in the wrong
order!
Makes fluid interfaces hard

107. Also needs docs
I think I will find some way to
wrap and import the docs from
WxWindows and attach them
to the right methods

108. Code wrapping

109. Code wrapping
Tell me if there’s a better way, but I
think macros might obscure too much…

110. use WxObject

111. And voila!

112. wx_const(:FOO)

113. WxObjectServer

114. Supervising
(YMMV, not sure how well this works yet…)

115. Let’s try it out.

116. TIL
(please learn from my mistakes)

117. Don’t spend days fighting
with regexs, use a parser.
(you are clearly using the wrong tool)

118. Combine is great, but
it still needs laziness.

119. Lazy Parsing in Combine

120. Do not name your
top-level module Wx
(you’ll spend hours wondering why things don’t
work — I still don’t know why)

121. Codez
https://github.com/ijcd/wx_widgets
https://github.com/ijcd/ropex
https://github.com/ijcd/emx
(available soon)