dunlin/musing.md

88 lines
2.4 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
## 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.