2.5 KiB
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,