event-queue.txt

# Event Queue

heterogeneous - keys, macros, mouse, OP_X
abstract: queue of [timestamp, type, data] -> API
owned by NeoMutt?

Actions: keypress, mouse move, code push (command)
are keypresses independent of processing?
    who interprets?
    when?
    -> check_for_keys() -> queue_key()
       process_queue() -> get_event()

how's it fit into external event loop?

how are events interpreted?
    need 'd' -> OP_DELETE lookup
    need "<F1>" (macro) -> "Twork<enter>;d"
    need ":push 'text'" -> *insert* into queue

single keypress is easy to interpret

is macro 'n' keypresses?  or atomic text string?
    atomic ->
        1) bind a, 2) bind b, 3) bind ab + macro "ab" triggers 3)

dialog wants event; queue has plenty
dialog needs to specify *all* of its function handlers!
each function handler is associated with a Window
Global event handler offers each Window a "go" + recursion
    -> Reply: Yes, No, Longer

Yes: might imply a macro has inserted more events to the head
=> each Window needs to be able to handle any type of Event

can global handler deal with macros?  probably

bind ab, macro ax
    offer 'a' -> longer
    offer 'ax' -> fail
    then what?
who errors 'a' unknown?
do we try 'x' again?  probably

---

macros *must* be interpreted letter by letter - nested macros or other bindings

problem: macro "abc" where 'a' expands to "xyz"
    need to insert "xyz" while global handler is working on "abc"

macro "aaaaaXbbbbb"  (X expands)

need 1 char (char could be multibyte utf-8)
queue doesn't understand data
macro object could keep track
caller could peek at queue (ok for a single thread)

caller: t = q_top(); get_char(t)
    what if it returns OP_X?

if t is empty, pop and retry

caller gets X, expands to macro "RST" (could be multiple items)
    could be multiple substitutions

"aaaaaXbbbbb" isn't finished

caller: q_insert_head("RST")
next get/peek gets "RST"

macro calls: "push '...'"  (global)

macro more events from  ":source script.sh|"

callers from different Windows / levels
    who's driving?

If in AliasDlg -> MsgWin (:command) does <next-entry> work?
    currently no, but with global event handler, yes
    could we stop it happening?   Alias could check focus
    do we want to stop it happening?
        it could change the select
    what if the <exit> the dialog?! -- let them?
    might not be possible if MsgWin handles <exit>

---

macro calls: push "RST"             Q: "aaaaaXbbbbb2"; other
macro object points to first 'b'    Q: "RST"; "aaaaaXbbbbb2"; other

parse_rc_line()

radical idea... are `:command`s part of the event queue?
config/hook:   echo apple; push "<banana>"; echo cherry
the entire string is queued as a single item...
the "processor" gets the top of the queue, parses "echo apple;" and executes it
the queue is left with:  push "<banana>"; echo cherry
the "processor" gets the top of the queue, parses: push "<banana>"
"push" causes the text to be inserted
queue:  "<banana>"; "echo cherry"
parse and execute <banana>
parse and execute "echo cherry"

what about
	sync-`echo mailbox`
	shell command must be synchronous

echo apple
push "<enter-command>echo banana<enter>"
echo cherry

---

parse_rc_line()
	"sync-`echo mailbox`"
	echo apple; push "<banana>"; echo cherry
	echo apple; source banana.sh|; echo cherry

banana -> "echo x; push y; echo z"

normally x| output is read and processed from the pipe
save to file and queue the file?
	need file?
	it could be big

does the normal config read use the same mechanism?

source a.rc -> source b.rc, c.rc -> x.rc, y.rc
	a.rc
	├── b.rc
	└── c.rc
	    ├── x.rc
	    └── y.rc

Q object: filename, current line
what's the diff between startup config and :source?
	latter can <push>
what does push do at startup?
who is interpreting <xyz> and when?
needs to be put into Q and parsed when it's read
	which Q items interpret <X>, which are literal?