This is about the new version of my Common Lisp Interface Manager (using McCLIM),
NicCLIM map editor on itch.io.
NicCLIM v2 mainly adds
execute-list
which believes cur1
to be a list of commands, and tries to execute them with lisp’s dolist
.com-apply
and com-funcall
which apply
and funcall
the cur1
cursor to the current x y map cell.com-change-player
, com-gets
and com-setsgets
: the frame now has an active player symbol. com-gets
get
s cur1
from the plist of that symbol, and com-setsgets
stores cur1
in cur2
’s get.There are additional utilities like doas-list
which combines com-change-player
and com-execute-list
, not pictured here.
• (setq inferior-lisp-program "ecl")
• (slime)
• (setq eepitch-buffer-name "*slime-repl ECL*")
(ensure-directories-exist #p"~/GAME/")
(uiop:chdir "~/GAME/")
(uiop:chdir "~/GAME/")
(rect-file "TEST.TXT" 3 2 ())
(enclose-map "TEST.TXT")
Note that rect-file
appends if TEST.TXT
already exists. TEST.TXT anyway:
NIL NIL NIL
NIL NIL NIL
anything with lists, or nothing, both work
com-execute-list
Here we set cur1
to a (list of commands)
and call Execute List
(autocompleted). The commands go down (COM-J
), right (COM-L
) and then push cur1
(which was the list of commands): ((COM-J) (COM-L) (PUSH-CUR1))
.
So we can execute macro CLIM
command lists in NicCLIM v2
.
com-apply
and com-funcall
Here we push 4
and 5
to one of the map cells, set cur1
to +
, then issue the command apply
. We then push cur1
into the cell, seeing that it was 9
. We also try funcall
with car
which seems important, as does copy-list
.
change player
, setsgets
and gets
We needed an idea of registers. I chose to add an active player (symbol) to the map editor, and use their symbol-plist
to store (setsgets
) and retrieve (gets
) cursor values. The GIF is a little confusing, so here’s what happens:
change player
to zaphod
. Zaphod has no :last-x
or :last-y
so the cursor is sent to 0,0.Set Cur1 FOO
in so many words.Swap
- now cur2
is FOO
and cur1
is NIL
again.Set Cur1 BAR
, and Swap
- Now cur1
is FOO
and cur2
is BAR
.Setsgets
- Now (get 'zaphod 'bar)
is FOO
. I.e. cur2
is the key and cur1
is the value.Push Cur1
- still FOO
and step right (L
)Gets
, Push Cur1
- NIL
: This was (get 'zaphod 'foo)
and step right againSwap
, Gets
, Push Cur1
- this was FOO
. We swapped BAR
into cur1
and got the cur1
from Zaphod
, whose value writes over cur1
. We stored FOO
under Zaphod’s BAR
a moment ago.In my heart of hearts, this was modeled after Bill Joy’s VI (which DM tells us was designed with investigation of other screen editors including emacs). [Edit: somewhat improved].
Firstly, in VI the @
command performs a list of VI
command actions. In our case, execute-list
(hotkey meta- shift- b but who’s counting) executes cur1
, hopefully a list of CLIM
command objects (basically lists of command names and arguements).
Secondly, where VI has lisp mode
which I have seen at least somewhere has the notice “THIS WILL NEVER BE IMPLEMENTED”, NicCLIM offers apply
and funcall
with cur1
’s value and the map cursor’s list as arguements. This is the access provided to the host lisp.
Thirdly, where VI allows us to kill and yank to and from registers using the "
prefix command, NicCLIM
v2 defines an active player symbol, with gets
and setsgets
(i.e. get
and put
) to the active player symbol.
I’m going to try homing my lisp programming in these for a while- one challenge is that map files are currently only acceptable lisp files if every cell is construed to be com-funcall
ed with cur1
=eval
, which clearly loses everything three dimensional and hyperconnecting about the NicCLIM
working environment, though it is appealling to be able to ‘deploy’ somewhat unexciting map files as regular lisp files. I dunno, what do you think.
NicCLIM v2 will have some more content patches (like the keyboard layout layout we worked on before), and it needs a use-from-lisp example like this one.
Lastly, quickly about threading- I thought about introducing threading with players, but it’s easy to get tripped up as to what *package*
is currently going to be with CLIM and multithreading. Furthermore, the primary contribution of CLIM viz threading is to syncronize execution requests, since asyncronously sent commands are linearized as they pass through the running application-frame’s threadsafe command queue. So multithreading goes elsewhere.
Talk on the Mastodon as always please. I for one am interested in though a bit nervous about feedback from DM (and you.).
screwlisp proposes kittens