dunlin/musing.md

# 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

## next steps

* [done] change define-command so that the parameters are ordered
* display unbound key error
* ESC to cancel interactive command
* autocomplete command name
* parameters with non-string values (e.g. buffer)
* show current url when command inactive
* [done] show prompts for parameter
* multiple buffers
  - create buffer
  - list buffers (where does the output go?)
  - find and switch to buffer


how do we do the buffer list thing?
- generate html, or
- use native widgets

native widgets seems neater
- how do we permit commands to insert widgets into the frame?
- how do we get rid of them?

we could have an "output overlay" inserted underneath the commander.
could we use the same thing for completions? we haven't addressed
non-string parameters yet, really

M-x switch-to-buffer
 Buffer mai_

 +------+  +---------+
 | main |  | mailing |
 +------+  +---------+


-----

so there are two things going on here

1) how to implement switch-to-buffer with appropriate autocomplete
on the buffer name - perhaps involving showing buffer thumbnails etc

2) 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

are these the same problem or are they separate problems? do we have
the second problem?  What I will do is address the first one and
see if it's generalisable once I've done it.