# Braindump

This is a combination of a thinking-out-loud document and a TODO list.
It is not a document of record. You should not expect to derive value
from reading it

tl;dr what if ... a web browser, but tabs were more like emacs buffers?

## objects/data types

buffer
  Buffer.find ;; by name, title, url
  Buffer.by_name (maybe?)

  buffer has-a webview but it is not shown by default. Later we may
  add some kind of webview reuse so that invisible and old buffers
  don't need to have a webview until needed.

  I seem to be using "buffer" and "tab" mostly synonymously

frame
  Frame.the-frame
  frame.set-buffer (buffer)
  frame.get-buffer => buffer
  frame.commander - text entry widget
  frame.actions - container of toolbar buttons

  in future we may be able to split a frame into multiple windows
  which show different buffers

location (url)
document
document element(?)
webview
lua's standard types

-----

a consideration we haven't touched on yet: in emacs, not all buffers
are files - e.g. the buffer list, or the process list, or the magit
status buffer - there is a well-used affordance for elisp to put
semi-persistent interactable content onscreen - do we need such a
thing here or is it ok to say "just call gtk" to command authors?

----


is there a role for TAB?

- in the shell it activates completion or  shows options: we don't need that if we're updating them automatically

- we could use it to cycle through the available completions: switch
focus from entry to step through the completions then RET activates


-----

# TODO

* [done] show loading progress
* [done] show url when the commander is inactive
* [done] visit-location url defaults to current
* [done] ESC to cancel interactive command
* [done] C-g to cancel key sequence
* [done] display unbound key error
* [done] back binding
* [done] save url history, use it in completions
* [done] autocomplete command name
* [done] keyboard navigation of completions

* custom rendering for completions (e.g. buffer thumbnails)
* less ugly default completions rendering
* buffer name is often going to be useless. find buffers by url/title
   still need some 1:1 mapping between the buffer object and
   a text-representable form of same
* bind event to echo-area click, ideally dependent on what's being shown in there
* in general, can we bind commands to widget events?
* command to create new buffer

* suppress "Return is undefined" message after a command executes

----

can we increase the testability? e.g. for command processing,
define a command, feed in some keystrokes,