dunlin/musing.md

86 lines
2.5 KiB
Markdown

# 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,