Manual

2. Files and folders

The file tree is the left column. Click a file to open it. The two buttons at the top create a new file and a new folder at the root; to create inside a folder, right-click it (long-press on a touch screen) and use the menu, which also offers Rename… and Delete.

Renaming and deleting keep open tabs honest: a renamed file follows its tab, and deleting a file or folder closes the tabs underneath it and moves you to a neighbour rather than leaving a dead editor.

Where a file actually is

The tree names files by where they sit in the workspace, which is no use the moment you want to hand one to something else. The same right-click menu offers Show location… — the full path on disk, selectable, with a Copy button — and Reveal in Finder, which opens Finder with the file selected. Right-clicking the workspace row itself locates the workspace folder.

Editor tabs have the same two items on right-click. That is the only way to ask about a file opened in place from outside the workspace: it is marked ↗ and never appears in the tree.

Files beginning with a dot are hidden from the tree, which is why your keybindings live in .eeditor/keybindings.eelisp — present, editable, out of the way.

The daily note

⌘D opens today's note, YYYY-MM-DD.md at the root of the workspace, creating it with a date heading if it doesn't exist. It never overwrites an existing one, so pressing it repeatedly through the day just takes you back to the same note.

What a new one starts with can be yours: a (defn daily-template (day) …) in the keybindings' (on-load …) returns its text — or, with the PIM, its pim-daily-template does, with today's agenda filled in. See a daily note that starts with your lists.

4. Tabs

Opening a second note puts it in a new tab rather than replacing what you had. Click a tab to switch, click its × to close. From the keyboard, ⌃Tab and ⌃⇧Tab go to the next and previous tab, ⌘1…⌘8 to the first eight and ⌘9 to the last (Ctrl+1… on Windows and Linux). These are built in; a (bind …) of your own on the same key replaces it — see keybindings for the next-tab, prev-tab, tab-1…tab-8, last-tab and close-tab commands. Inside a running form with windows of its own, ⌃Tab cycles those instead.

A tab marked ↗ is a file from outside the workspace; see §7.

6. Links between notes

Write [[Note name]] to link to another note. Typing [[ opens an autocomplete list of existing notes, so links stay spelled the way the files are.

In preview, a wiki link is a plain click. In the editor, ⌘-click it. Either way you land in the linked note.

Backlinks

Under the editor, a bar lists every note that links to the one you're reading — ↩ 3 backlinks: index.md, projects.md, 2026-08-09.md. Click one to follow it. The bar hides itself when nothing points here.

Notes opened from outside the workspace are not part of the link graph, so they show no backlinks and aren't offered in autocomplete.

8. The agenda

The agenda is a personal information manager in the Lotus Agenda tradition: you throw text at it, and structure emerges from rules rather than from forms you fill in.

Adding items

The box at the top of the agenda panel takes plain language and parses it — call Bob tomorrow !! becomes an item due tomorrow at high priority. Dates, priorities and people are recognised as you write them.

Tasks typed in notes

A - [ ] … line typed in a note is only text until it is linked to an item — it gets a {#12} at its end when it is. Under its items the agenda panel lists the lines that aren't yet, in a folding group, in notes, not in the agenda · N, by note. Click one to open its note at that line; ＋ makes it an item and links the line. Lines inside ``` fences are examples and are left out.

Editing an item

Click one to expand its editor, which holds:

• text — the item itself
• when — a due date
• priority
• notes — free text underneath
• recurrence — daily, weekly or monthly, with an interval
• categories — one or more, from those you've defined

Categories

Categories are hierarchical: work/clients/acme is a child of work/clients. Assigning a child implies its parents, and an exclusive parent allows only one of its children at a time — so an item can't be both status/open and status/done.

Rules

Rules are the part that makes the agenda feel alive. A rule is a condition and an action; run them and every matching item is filed automatically. Open the setup panel to define categories and rules, then apply them.

(defrule invoices
  :when   (str-matches text "invoice|bill|payment")
  :assign "finance/invoices")

Inside a condition the item is in scope: text, notes, id, categories and props are bound, along with (get "field"), (has-category "work"), (overdue?) and (match n) for the capture groups of the last regular expression. Because rules are stored as EELisp and re-evaluated, anything the language can express, a rule can decide.

Views

A view is a saved filter with optional grouping — everything overdue, grouped by category. Define with defview, list with views, display with show.

The calendar

The calendar button opens a month grid of dated items. Drag an item to another day to reschedule it; the change is written straight back.

Recurrence

A recurring item regenerates when completed. every handles the date arithmetic — daily, weekly and monthly, with intervals like every 2 weeks — without depending on an external calendar.

The PIM: notes kept in step with the agenda

The PIM is a set of keys and functions, written in EELisp, that ties notes and the agenda together: a line like - [ ] pay the rent tomorrow !! {#12} is agenda item 12, ticked in the note when it's done in the panel and the other way round. With it come capture (⌘⌥N), refile (⌘⌥F), reminders, a time clock (⌘⌥I/⌘⌥O), a tracker (⌘⌥L), live blocks that refresh with ⌘⌥U, and a weekly review (⌘⌥V).

Its keys aren't part of the defaults. A folder gets them with the sample notes, or — for a folder you already use — right-click the workspace and choose Install the PIM keys…: they're added to your keybindings, your own keys stay as they are, and ⌘⌥K answering No clock running says they're live. The PIM guide has every key and function.

It puts two buttons in the header — ↻ update (⌘⌥U, recompute the note's lists) and ⇄ sweep (⌘⌥S, every note in step with the agenda) — and every key of it is in ⌘P's actions by name, with a few more that have no key: Insert the tasks in a category…, Insert a board of a category…, Insert the inbox, Open the Agenda window.

The sidebar's agenda, as a form

The PIM draws the agenda section as a form, pim/Side.eeform, in place of the built-in list: a quick-add box (the PIM's own reading of the line — #tags become categories, text after | its notes), N overdue · N today · N open, every category with how many open items it holds — children indented under their parent, the parent's count taking theirs in — and the items by date, overdue first. Pick a category to list only its items. ✓ done finishes the one picked; ⤢ agenda opens the big window. The in notes group stays under it.

It is an ordinary form, put there by one line in your keybindings — (panel "agenda" "pim/Side.eeform"), see panels. Open it in the designer to change what it shows, point the line at a form of your own, or take it out for the built-in list.

The agenda, big

⤢ above the sidebar's agenda opens pim/Agenda.eeform filling the window — the PIM as one interface, a tab each: Start here (is it all live, every key), Agenda (quick add, filters, an editor for one item), Board, In notes, Capture, Clock, Tracker and Review. ⤢ in its title bar, or a double-click on the title, gives the room back.

A board

The Board tab is a kanban of your categories. Pick one under Columns and its children are the columns — work/l2l, work/admin, then work itself for what is filed under it alone — or the top-level categories, with no category last. An item shows once, in the first column that holds it. Drag a card to another column, or press ⌥← / ⌥→ on the one picked, and the item is refiled: out of the categories that put it in the column it left, under the new one. Double-click a card to edit it.

Lists in a note

Any of the agenda's lists can live in a note, as a block that ⌘⌥U recomputes: the expression goes in the opening line, its result between the two. The preview draws it and the PDF prints it.

<!-- eel: (pim-category "work") -->
<!-- /eel -->

The task lines a block writes are the items themselves, {#12} and all: ⌘⌥T on one there finishes it in the agenda.

10. Forms

A form is a window you draw — buttons, boxes, a grid — with EELisp behind its events. It is the Visual Basic and FoxPro way of putting a screen over a table, and it lives in your workspace as a file: Contacts.eeform sits in the tree, opens in a tab, and can be renamed, moved and searched like a note. Right-click a folder and choose New form…, or type a name ending in .eeform into ＋.

A form tab has three modes, switched at the top of the pane: design, code and run.

The designer

Three columns, as VB had them.

• The toolbox, on the left. Click a kind of control, then click on the form to place one there — or drag out the size you want.
• The canvas, in the middle, the size of the form. Click a control to select it, drag to move it, pull a handle to resize it. ⇧-click adds to the selection, a drag from empty canvas draws a box around several, ⌘A takes them all. Arrows nudge by a grid step (⇧ by a pixel), Delete removes, ⌘D duplicates, ⌘C ⌘X ⌘V copy, cut and paste — into another form's tab too. ⌘Z undoes, because every change is one edit to the file. The small square at the bottom right resizes the form itself.
• The properties, on the right: the selected control's name, position and size, what it holds, and its events. With several selected the panel becomes align, same size and spread evenly, all relative to the one you picked last — drawn with the heavier outline. With nothing selected it shows the form: title, size, menu, and what runs when it loads.

The file

Switch to code and there is no second language. The form is EELisp: one (form …) holding the layout, which the designer rewrites as you work, followed by your own code — a table, and the handlers the events name. Edit either half; the other follows.

(form "Contacts" :size (480 400) :on-load load-contacts
  (label   lblName :text "Name" :at (16 20) :size (72 24))
  (textbox txtName :required true :at (96 16) :size (240 28))
  (label   lblAge  :text "Age" :at (16 56) :size (72 24))
  (textbox txtAge  :number true :min 0 :max 150 :at (96 52) :size (80 28))
  (button  btnSave :text "Save" :submit true :default true :at (96 96) :size (88 30) :on-click save-contact)
  (grid    grdAll  :columns ("name" "age") :sortable true :filter true :page-size 5
           :at (16 144) :size (448 232) :on-change pick-contact))

(deftable contacts (name:string age:number))

(defn load-contacts (f)
  (ui-set "grdAll" :rows (query contacts :order "name")))

(defn save-contact (f)
  (insert contacts {:name (ui-get f "txtName") :age (ui-get f "txtAge")})
  (ui-set "txtName" :value "")
  (load-contacts f))

(defn pick-contact (f)
  (let (row (ui-get f "grdAll"))
    (ui-set "txtName" :value (dict-get row "name"))
    (ui-set "txtAge" :value (dict-get row "age"))))

Attaching code to an event

Double-click a button. That names its on-click handler after it, writes an empty (defn btnSave-click (f) …) at the end of the file, and opens the code with the caret on it. The … beside any event in the properties panel does the same, and you can type any function's name there instead.

A handler is a function of the form. Its one argument, f, is the whole form as a dict keyed by control name, so (ui-get f "txtName") is what the box holds — text, a number, true or false, the chosen item, the selected row. To change the form, a handler queues changes; EEditor applies them, in order, when the handler returns.

Everything else is the language: insert, query, update, sheet-get, your own functions. A grid takes what query returns as its :rows, and the row a user picks comes back as a dict, so (dict-get row "id") is what update and delete want. Handlers are ordinary functions: try one from the REPL with a dict of your own.

The controls

Every control has a name, :at, :size, :enabled, :visible and :anchor (see Maximizing below). Events are properties naming a function: :on-click for a button, :on-change for anything with a value, :on-load for the form. The order of the controls in the file is the Tab order when it runs; the properties panel has earlier and later buttons to move one.

Checking what was typed

A :submit button does three things before its handler runs. First each control's own rules: :required, :min and :max on numbers and dates, :pattern — a regular expression the whole text must match. The first one broken is marked, focused and named: Age must be at most 150. Then the button's :on-validate handler, if it has one — a function of the form that returns a message to refuse, or nil to go ahead. Then :on-click.

(defn check-contact (f)
  (if (str-contains (ui-get f "txtName") " ")
    nil
    "A contact needs a first and a last name"))

Running it

▶ run evaluates the file — the table gets defined, the handlers too — builds the controls, and fires on-load. What the form writes goes into the workspace's database, the same one the REPL and your notes see, so (browse contacts) shows what it saved. ■ stop is the way back to the designer, and F5 runs the form in front again, as it did in VB6.

Opening a form asks: ▶ Run or Design. Running a form runs its code, so Design is what ↵ picks and what Esc leaves you with — the designer runs nothing, the rule sheets and eelisp blocks keep, and a form someone sent you can be looked at first. That is the line (forms-open "ask") in your keybindings file: "run" opens forms running without asking, "design" in the designer, "code" as their text. A new form, and an app imported from an exported page, always open in the designer.

To keep a form open while you write, run it in a window: type (ed-form "Contacts") in the REPL, bind it to a key, or press ⧉ on a running tab. The window floats over the app, drags by its title bar, and comes back where you left it. (ui-open …) from another form opens one the same way.

Keys in a form

In a listbox or a grid, ↑ ↓, Home End and PageUp PageDown move the pick, and :on-change hears it; ↵ is a double-click. A form can take keys of its own as well: :on-key names the handler, and :keys the keys it takes, written as a (bind …) writes them. The key arrives as $pressed and the control that had the focus as $control, both read with ui-get.

(form "Two folders" :size (520 320) :on-load fill :on-refresh fill
  :on-key on-key :keys ("Mod-Right" "Mod-Left" "Tab")
  (listbox lstLeft :at (10 10) :size (245 300))
  (listbox lstRight :at (265 10) :size (245 300)))

(defn fill (f)
  (ui-set "lstLeft" :items (map (fn (e) (dict-get e :name)) (dir-list "inbox")))
  (ui-set "lstRight" :items (map (fn (e) (dict-get e :name)) (dir-list "archive"))))

(defn on-key (f)
  (let (key (ui-get f "$pressed") left (ui-get f "lstLeft") right (ui-get f "lstRight"))
    (cond (and (= key "Mod-Right") left)
            (ui-editor (ed-move (str "inbox/" left) (str "archive/" left)))
          (and (= key "Mod-Left") right)
            (ui-editor (ed-move (str "archive/" right) (str "inbox/" right)))
          (= key "Tab")
            (ui-focus (cond (= (ui-get f "$control") "lstLeft") "lstRight" true "lstLeft")))))

The keys a form names are its own while it has the focus, even one the app uses — ⌘B, say — but never while the caret is in a text box, where typing comes first. With no :keys, the form takes every key with ⌘, ⌃ or ⌥, and F1–F12. The modifiers come in the order Mod, Ctrl, Alt, Shift: "Mod-Alt-Left". After file commands a form hands to ui-editor — ed-move, ed-copy, ed-delete, ed-mkdir, ed-write, ed-append — its :on-refresh runs once they are done, so a listing shows the folder as it is now.

Maximizing, and controls that stretch

⤢ in a window's title bar — or a double-click on the title — fills the app with it, and EEditor remembers that per form. The form is still drawn at its :size; :anchor says which sides of the form a control keeps its distance to when there is more room. Anchored left and right it grows wider, right only it moves with the right edge, and the same for top and bottom. Unset is "tl": it stays where it was drawn. So a grid is "tlbr", the buttons under it "lb", an editor down the right "tr".

(grid grdItems :columns ("text" "when") :at (20 136) :size (660 496) :anchor "tlbr")
(button btnSave :text "Save" :at (700 612) :size (72 30) :anchor "rb")

A form in the sidebar

A (panel …) line in your keybindings draws a form in the sidebar. "agenda" puts it in the agenda section, in place of the built-in list; "tags" in the tags section, in place of the cloud; any other name makes a section of its own.

(panel "agenda" "pim/Side.eeform")
(panel "tags" "pim/Tags.eeform")
(panel "Habits" "habits.eeform")   ; a section of its own

There it has no title bar and is as wide as the section — anchor its controls "tlr" to stretch with it. Its :on-refresh handler runs whenever the agenda may have changed (a key, the REPL, another form) and when a note is saved, which is how it stays current; it doesn't redraw while you are typing in it. Saving the form's file runs the new version there, and taking the line out brings back what the section had.

(form "Count" :size (224 48) :on-load fill :on-refresh fill
  (label lblCount :at (8 8) :size (208 24) :anchor "tlr"))
(defn fill (f) (ui-set "lblCount" :text (str (item-count) " items")))

Menus, pages, and a sheet in a form

A :menu on the form puts a menu bar under its title; each item names the handler it runs, "-" is a separator. The designer edits it as text — a title on its own line, items indented as label = handler.

(form "Contacts" :size (480 400)
  :menu (("Contacts" ("Reload" load-contacts) ("-") ("Close" close-form))
         ("Help" ("About" about)))
  …)

A tabs control lists its :pages, and any control with :page "Details" belongs to that page and shows only while it is open. Controls stay flat in the file with their own coordinates — draw them inside the tabs control's box — and the designer shows one page at a time; click a tab header on the canvas to open another.

A sheet control shows a .eesheet beside the form as the real grid, formula bar and all. Handlers read and write it with sheet-get and sheet-set, and the grid follows.

Example forms

Eleven forms to download, run and take apart. Save one into your workspace — any folder — and it appears in the tree; press ▶ run, then switch to code to see how it's done. Each file opens with a comment saying what it shows, and every handler has a line above it saying what it does. They write to your workspace's database, into tables of their own (books, customers, orders…), and the ones that start empty have a menu item that adds sample rows.

Contacts — the first one to read

Contacts.eeform · A table, a grid, and boxes to fill it. Required and number boxes, a submit button with its own check, an editable grid with sorting, a filter and pages, and a menu — nearly everything in this chapter, in sixty lines.

Books — one record at a time

Books.eeform · The dBASE way of working through a table: |◀ ◀ ▶ ▶| move record by record, Record 2 of 3 says where you are, and a find box jumps to the first title or author that matches. New, Edit, Save, Cancel (or Esc) and Delete do what they say. While you browse, the boxes are locked; while you edit, moving is. That is one function setting :enabled on every control, and it is the part worth copying:

;; Browsing: the boxes locked, moving allowed. Editing: the other way round.
(defn bk-mode! (mode n)
  (set! bk-mode mode)
  (let (editing (not (= mode "browse")))
    (for-each c '("txtTitle" "txtAuthor" "txtYear" "txtNotes" "btnSave" "btnCancel")
      (ui-set c :enabled editing))
    (ui-set "btnNew" :enabled (not editing))
    (ui-set "btnPrev" :enabled (and (not editing) (> bk-pos 0)))
    …))

Where you are is a variable, bk-pos, defined in the file with def and moved with set!. The file is evaluated when the form runs, so it starts at the first record every time.

Functions — the language, browsed

Functions.eeform · Every function in scope in a grid you can filter: the builtins, the special forms, the macros, the snippets you've loaded, the functions in your notes, and the form's own handlers. Pick one and its source appears — for anything written in EELisp, the definition as it was written, comments and all. Type arguments the way you would at the REPL and press Run. Double-click a row to start from its parameter names.

It is built on two functions that return what (functions) and (source …) print, as data a program can use:

(function-list "str-j")
; → ({:name "str-join" :kind "builtin" :sig "(str-join sep parts) → string" :summary "Joins a list…"})

(source-text "take")   ; → the text (source take) prints

;; Run: the call is written out as text and read back, so arguments are typed as at the REPL.
(eval (parse (str "(" name " " args ")")))

Files — two folders side by side

Files.eeform · A file manager in the Norton Commander tradition, for your workspace. Each panel is a folder, folders first, with sizes and dates. Tab goes to the other panel, ↵ opens a folder or puts a file in a tab, ⌫ goes up. ⌘→ and ⌘← move what is picked into the other panel's folder, ⌥⌘→ and ⌥⌘← copy it, ⌘⌫ sends it to the Trash. ⇧⌘→ and ⇧⌘← show this panel's folder in the other one, and ⌘G goes to a folder you type — notes/2026, /projects, ~Downloads/invoices. The box underneath renames, makes a folder, or goes to one. Nothing is ever written over, and each panel remembers its folder for next time.

It is about 140 lines of EELisp, comments included. (dir-list …) reads a folder; the moves are ed-move, ed-copy and ed-delete handed to the app, which keeps any tab open from a moved file in step and then runs the form's :on-refresh; the keys are :on-key (see Keys in a form). The moving, in short:

;; From one panel's pick into the other panel's folder — never over a name that is taken.
(defn fm-across (f from how)
  (let (row (fm-picked f from) to (fm-other from))
    (if (not (fm-real? row))
      (fm-say "Pick something first")
      (let (target (fm-join (fm-dir to) (dict-get row :file)))
        (ui-editor (if (= how "copy")
                     (ed-copy (dict-get row :path) target)
                     (ed-move (dict-get row :path) target)))))))

It works on the workspace and the folders you add outside it (⋯ → Add a folder outside the workspace…), which head each panel as ~Downloads/ — not the whole disk — and only in the app: an exported page has no folder to read.

Tables — any table, dBASE-style

Tables.eeform · Pick any table in the workspace. Narrow it with a where — plain SQL, year < 1985 — choose an order and a limit, and press Query. The line above the grid is the query exactly as it ran; paste it into the REPL and you get the same rows. Double-click a cell to change it, add an empty row, delete one, and Pack to remove deleted rows for good.

The table is picked while the form runs, so its name is in a variable. Any database function takes the table as a bare name — (query books) — or as an expression that works one out:

(query (str tb-table) :where "year < ?" :params (list 1985))
(update (str tb-table) id {:title "…"})

Orders — master and detail

Orders.eeform · Two tables tied by a field — orders.customer holds a customer's id. Pick a customer and their orders appear, each with its amount worked out and a total underneath. Add an order, change one in place, delete one; the total follows.

(query orders :where "customer = ?" :params (list or-customer))

Agenda — the agenda, as a form

Agenda.eeform · The agenda from chapter 8, and nearly every kind of control: a menu bar, tabs, a grid that sorts and pages, a date box, a radio group, dropdowns, a checkbox, and a timer that refreshes the list every minute.

• Items — what's due today, in the next seven days, overdue, or all of it, or a search. Pick one to edit it — text, date, priority, category, notes — or double-click to mark it done.
• Quick add — type it the way you'd say it; the box below shows what was understood before you add it.
• Categories & rules — the category tree; define one; add a rule that files an item when its text contains a word; apply the rules now, or as items arrive.
• Views — saved filters: overdue, text containing a word, or in a category.

An item read by id comes back whole with item->dict — notes included, which the grid doesn't carry:

(let (it (item->dict (item-get id)))
  (ui-set "txtNotes" :value (dict-get it "notes")))

defcategory, defrule and defview read their arguments as written — they are meant to be typed — so a form writes the call out as text and evaluates it, with json-stringify to put quotes around what was typed safely:

(eval (parse (str "(defrule " name
                  " :when (str-contains (str-lower text) " (json-stringify word) ")"
                  " :assign " (json-stringify category) ")")))

Office — the others as one app

Office.eeform · run it in your browser · Books, Orders, Tables, Agenda and Functions as the screens of one application, the dBASE way: pick one from the list and it fills the frame on the right; open another and the first stays open, with what you typed in it. The Window menu switches between them (⌃Tab too), closing one goes back to the one before, and the screen's own menus join Office's while it shows. Office remembers the last screen you used and opens it again next time. Download it with the five it opens, into one folder.

(form "Office" :main true :size (1040 640) …
  (listbox lstNav :items ("Books" "Orders" "Tables" "Agenda" "Functions") … :on-change office-go)
  (frame frmMain :at (192 8) :size (840 624) :on-change office-switched))

(public last-screen "" :persist true)    ; kept between runs

(defn office-go (f)
  (ui-open (ui-get f "lstNav") :in "frmMain"))   ; Books.eeform, beside Office

Three things make several forms one app. A frame is where the forms a form opens run — one at a time (:mode "screens"), as tabs, or as windows inside it. A variable declared (public …) is shared by a form and every form it opens, and a form with :on-public hears when another changes it; (local …) is one open form's own, so two copies of Books keep their own place. And a name in ui-open is found beside the form that asks, so the app's folder can go anywhere.

Display, Raycaster, MSX — screens: a picture, the keys, sound

A screen control is a picture the program draws. It evaluates its :frame expression :hz times a second and paints the frame that comes back — a dict saying what kind of picture it is and carrying its bytes. In the expression, ui-held is the keys held down ({"ArrowLeft" true}, by key code) and ui-ms the milliseconds since the screen started. Click a screen and it takes the keys; ⛶ fills the window with it.

(screen scrDemo :frame "(display-frame ui-held ui-ms)" :hz 35 :at (16 44) :size (480 324))

(defn display-frame (held ms)
  …                                    ; move the square, draw the picture with bfill
  {"kind" "indexed" "w" 160 "h" 100 "order" "columns"
   "pixels" (bytes->base64 display-fb) "palette" display-palette "border" 0 …})

An "indexed" frame is a byte a pixel into a palette of up to 256 colours; "rgba" is four bytes a pixel. A frame may also carry sound: "tones", notes for the browser to play ({"hz" 440 "ms" 120 "wave" "square"}), or "audio", 8-bit samples of its own. Sound starts at the first click on the screen, and 🔈 mutes it.

• Display.eeform · run it in your browser · The one to read first: a sky and ground drawn a column at a time, a square the arrow keys move, a note while Space is held.
• Raycaster.eeform · run it in your browser · A first-person maze: rays cast across a map, textured walls, sliding doors, lamps and barrels hidden behind the walls, footsteps — in about 10 ms a frame.
• MSX.eeform · run it in your browser · A whole MSX1 in EELisp: the Z80, the TMS9918 video chip, the PSG sound chip, booting the free C-BIOS. Snake plays a game, Load cartridge… takes a .rom of your own — and Make an MSX game writes that snake from nothing, in Z80 assembly.

One file that runs anywhere

Right-click a form in the tree and choose Export as HTML…. EEditor writes one file beside it — Office.html — that runs in any browser, offline, opened straight from disk: the EELisp engine is inside it, compiled to WebAssembly, with the form and every form it opens. Nothing to install, nothing to host; e-mail it, put it on a USB stick or a web page. That is what the two links above are.

What the app stores is kept in the browser that runs it, between visits. Save data… under the app downloads it all as a SQLite file, and Open data… loads one back — how data moves to another computer or another person. Change the forms in EEditor and export again: the new file finds the data the old one kept, in the same browser.

12. Keybindings

⌘⇧K opens .eeditor/keybindings.eelisp, writing the documented defaults into it the first time. That file is the shortcut table. Save it and it reloads at once; delete it and the built-in defaults apply again.

Writing a binding

(bind "Mod-i" body…)

Modifiers join with - or +. Mod is ⌘ on macOS and Ctrl elsewhere, and Cmd, Ctrl, Alt (Option) and Shift can be named directly: "Mod-Shift-f", "Ctrl-Alt-t". Every binding needs at least one modifier — function keys and Esc may go bare. Named keys are Left Right Up Down, Enter, Tab, Escape, Space, Backspace, Delete, Home End and PageUp PageDown. A later binding wins the same key, and unbinding one hands the key back to the editor's own behaviour.

What a binding returns

The body is EELisp, evaluated on the engine when the key fires. It returns editor commands as data, and a binding may list several — they run in order against the live document. The REPL carries out the same commands: type (ed-insert "hello") at the prompt and it lands in the note.

Files and folders

A key or a form can read the whole workspace and rearrange it. Reading happens in EELisp itself; changing goes through the app, so a tab open from a file that moves follows it.

;; ⌘⌥J — file the note in front under journal/, by month: journal/2026-11/…
(bind "Mod-Alt-j"
  (ed-mkdir (str "journal/" (date-format *date* "yyyy-MM")))
  (ed-move *file* (str "journal/" (date-format *date* "yyyy-MM") "/" *file*)))

to is always the whole new path. Nothing is ever written over: a move or copy onto a name that is taken is refused, with a message, and so is any path that would leave the workspace.

Folders outside the workspace. ⋯ → Add a folder outside the workspace… in the desktop app grants one — your Downloads, say — and from then on a path names it as ~Downloads/…: (dir-list "~Downloads"), (read-note "~Downloads/notes.md"), (ed-move "~Downloads/invoice.pdf" "money/invoice.pdf"), and a note there opens in a tab like any other. (roots) lists what was granted. Only you can grant one, with the folder picker; a script can't, and the list is kept in EEditor's own settings, not in the workspace, so a folder someone sends you can't grant itself anything. Remove a folder outside the workspace… in ⌘⇧P takes one back. :modified counts seconds the way (now) does, so (date-format (dict-get e :modified)) reads it.

What your code can see

These are defined fresh before every run:

*selection* and *buffer* are only computed when your binding mentions them, so a shortcut stays fast in a large document.

The header's buttons

The buttons above the editor are the file's (button …) lines, left to right in the order they are written. A button can press a key, run a body as a binding does, or run one of the app's commands — and one that runs a command may leave its label out: EEditor labels it, hides it where it can't work, and shows it pressed while it is on. Delete a line and the button goes; move it and it moves.

(button "↻ update" "Mod-Alt-u")        ; does what ⌘⌥U does
(button "today" (ed-cmd "daily-note"))  ; a body, as a bind takes
(button (ed-cmd "toggle-theme"))         ; labelled by the app
(button (ed-cmd "insert-image"))
(button (ed-cmd "toggle-preview"))
(button (ed-cmd "export-pdf"))
(button (ed-cmd "open-keys"))
(button (ed-cmd "toggle-repl"))

A file with none of those six command buttons — one written before they were buttons — gets them anyway, after its own. Write one of them and the header is yours. (panel …) lines draw forms in the sidebar: see a form in the sidebar.

Actions of your own

An (action "label" …) line is written like a button, but it's listed only in ⌘P's actions — for the things worth finding by name that don't deserve a key or a place in the header. Its body is a binding's, or a key to press:

(action "Work tasks here"   (pim-insert-block "(pim-category \"work\")"))
(action "Open the roadmap"  (ed-open "projects/roadmap.md"))
(action "Sweep" "Mod-Alt-s")

A key needs no action line to be listed: the comment right above its (bind …) names it. A capitalised name before a colon is the whole name — ;; ⌘⌥G — Set the category: file the caret's task under one — and the keys written in front of the dash are left out.

Choosing what opens at launch

(on-start …) runs the same kind of commands once, after the workspace loads. With no on-start form at all, EEditor opens welcome.md while that is still around, and today's note — created if it doesn't exist yet — once it isn't.

(on-start (ed-open "todo.md"))         ; always this note
(on-start (ed-cmd "daily-note"))       ; today's note, created if needed
(on-start (ed-new (str *date* ".md")))  ; the same, spelled out
(on-start)                              ; nothing — an empty editor

An empty (on-start) is deliberately different from leaving the form out: one says "open nothing", the other says "decide for me".

Built-in commands

Anything here can be named by (ed-cmd "…"):

Worked examples

;; A timestamped heading at the caret, on its own line
(bind "Mod-Alt-h"
  (ed-insert (str (cond (= *col* 1) "" true "\n") "## " *time* "\n\n")))

;; Wrap the selection in bold
(bind "Mod-b" (ed-replace (str "**" *selection* "**")))

;; A task line
(bind "Mod-Shift-t" (ed-insert "- [ ] "))

;; Link back to today's note
(bind "Mod-Shift-b" (ed-insert (str "[[" *date* "]]")))

;; File this note under a dated folder and tell me about it
(bind "Mod-Alt-n"
  (ed-new (str "journal/" *date* ".md") (str "# " *date* "\n\n"))
  (ed-message "journal entry ready"))

A daily note that starts with your lists

daily-template is what a new daily note starts with — ⌘D, the daily-note command, Today's daily note in ⌘P's actions:

(on-load
  (defn daily-template (day)
    (str "# " day " · " (date-format day "EEEE") "\n\n## Today\n\n- [ ] \n\n## Notes\n\n")))

With the PIM, ⌘D makes the note from pim-daily-template; define that one instead and the note can open with live lists — each a block that's filled when the note is made and that ⌘⌥U refreshes through the day. A list of headings and blocks keeps it easy to change:

(on-load
  (def my-daily-blocks
    (list (list "Agenda" "(pim-agenda 1)")
          (list "Work"   "(pim-category \"work\")")
          (list "Inbox"  "(pim-inbox)")))
  (defn pim-daily-template (day)
    (str "# " day " · " (date-format day "EEEE") "\n\n"
         (str-join "" (map (fn (b) (str "## " (first b) "\n\n" (pim-block (second b)) "\n\n"))
                          my-daily-blocks))
         "## Log\n\n\n## Notes\n\n")))

14. Shortcut reference

The defaults. ⌘ is Ctrl on Windows and Linux.

Most of these are a line in your keybindings file. The tab keys, ⌘W, ⌘B and F5 are built in, and a (bind …) of your own on one of them replaces it; ⇧⌘W and ⌃⌘N belong to the File menu. The PIM adds its own ⌘⌥ keys — ⌘⌥T a task, ⌘⌥U update the blocks, ⌘⌥B links to a tag's notes and the rest; the PIM guide lists them all.