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.

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. ⌘⌥→ and ⌘⌥← move between tabs if you bind them — see keybindings for the next-tab, prev-tab and close-tab commands.

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.

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.

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 and :visible. 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. Opening a form runs nothing: only run does, the same rule as sheets and eelisp blocks.

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.

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

Seven 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 ")")))

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.

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. 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.

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.

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-Shift-i"
  (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"))

14. Shortcut reference

The defaults. ⌘ is Ctrl on Windows and Linux.

Every one of these is a line in your keybindings file, and every one can be changed.