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

-----

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

----

when input widget is active for a parameter, show the completions
flowbox

while typing, use the typed input to get a completions list.  each
completion is an acceptable value: convert to a gtk widget by calling
(to-label value) and add to flowbox.


if the value is a table
  if :to-label key present, use it as-is
  else Gtk.Label { :label value.value }
else (assume it's a string)
  Gtk.Label { :label value }

on RET, check there is a completion value whose stringification
matches the input string. Hide the flowbox

to activate a rendered completion, the callback needs to perform the
same action as RET would on the chosen value

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

* 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
* click in commander widget activates visit-location
* in general, can we bind commands to widget events?
* display unbound key error
* autocomplete command name
* command to create new buffer
* keyboard navigation of completions

----

I think we're misusing the commander to show url and error messages
and key prompts. It's OK to have that part of the screen be multipurpose
but philosophically those things are not related to the command system.

- hide commander when inactive and replace it with echo area
- move it to bottom?

commander can't hide itself, it needs to ask its parent to hide it