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?

----


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,
we are amused 2022-12-23 19:45:58 +00:00			`# Braindump`
initial commit 2022-12-19 18:19:13 +00:00
we are amused 2022-12-23 19:45:58 +00:00			`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`
initial commit 2022-12-19 18:19:13 +00:00
we are amused 2022-12-23 19:45:58 +00:00			`tl;dr what if ... a web browser, but tabs were more like emacs buffers?`
initial commit 2022-12-19 18:19:13 +00:00
			`## 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.`

we are amused 2022-12-23 19:45:58 +00:00			`I seem to be using "buffer" and "tab" mostly synonymously`

initial commit 2022-12-19 18:19:13 +00:00			`frame`
			`Frame.the-frame`
			`frame.set-buffer (buffer)`
			`frame.get-buffer => buffer`
			`frame.commander - text entry widget`
			`frame.actions - container of toolbar buttons`

we are amused 2022-12-23 19:45:58 +00:00			`in future we may be able to split a frame into multiple windows`
			`which show different buffers`

initial commit 2022-12-19 18:19:13 +00:00			`location (url)`
			`document`
			`document element(?)`
			`webview`
			`lua's standard types`

clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`-----`
we are amused 2022-12-23 19:45:58 +00:00
clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`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`
trim outdated stuff 2023-01-15 16:57:25 +00:00			`thing here or is it ok to say "just call gtk" to command authors?`
some musing about switch-to-buffer 2022-12-26 11:31:35 +00:00
clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`----`
some musing about switch-to-buffer 2022-12-26 11:31:35 +00:00

clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`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`
some musing about switch-to-buffer 2022-12-26 11:31:35 +00:00
clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`- we could use it to cycle through the available completions: switch`
			`focus from entry to step through the completions then RET activates`
some musing about switch-to-buffer 2022-12-26 11:31:35 +00:00

clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`-----`

			`# TODO`
some musing about switch-to-buffer 2022-12-26 11:31:35 +00:00
clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`* [done] show loading progress`
			`* [done] show url when the commander is inactive`
			`* [done] visit-location url defaults to current`
WIP popup commander 2023-01-01 16:49:15 +00:00			`* [done] ESC to cancel interactive command`
			`* [done] C-g to cancel key sequence`
trim outdated stuff 2023-01-15 16:57:25 +00:00			`* [done] display unbound key error`
			`* [done] back binding`
			`* [done] save url history, use it in completions`
repair command completions 2023-01-15 18:29:46 +00:00			`* [done] autocomplete command name`
make keyboard completions work 1. When adding a button to flowbox, the flowbox widget interposes a flowboxchild between the two, which can receive events and so becomes part of the tab order. this is why our buttons weren't getting activated - they weren't focused even though they looked focused. So, use labels instead of buttons for completions 2. For some reason I don't understand, flowboxchild widgets receive :activate only on keyboard activation. So instead of using it, we connect to :child-activated on the flowbox. 3. Setting widget:on_foo adds a handler to the widget instead of replacing what was previously there. There is no nice way to remove handlers from a widget either. Because we need a new on_child_activated handler every time the completions change, the only way I can see to achieve this is to create the flowbox afresh on each keystroke instead of creating it once when the frame is created 2023-01-17 21:43:53 +00:00			`* [done] keyboard navigation of completions`
clean up the spew file a bit 2023-01-01 00:15:26 +00:00
			`* custom rendering for completions (e.g. buffer thumbnails)`
WIP popup commander 2023-01-01 16:49:15 +00:00			`* less ugly default completions rendering`
			`* buffer name is often going to be useless. find buffers by url/title`
clean up the spew file a bit 2023-01-01 00:15:26 +00:00			`still need some 1:1 mapping between the buffer object and`
			`a text-representable form of same`
make keyboard completions work 1. When adding a button to flowbox, the flowbox widget interposes a flowboxchild between the two, which can receive events and so becomes part of the tab order. this is why our buttons weren't getting activated - they weren't focused even though they looked focused. So, use labels instead of buttons for completions 2. For some reason I don't understand, flowboxchild widgets receive :activate only on keyboard activation. So instead of using it, we connect to :child-activated on the flowbox. 3. Setting widget:on_foo adds a handler to the widget instead of replacing what was previously there. There is no nice way to remove handlers from a widget either. Because we need a new on_child_activated handler every time the completions change, the only way I can see to achieve this is to create the flowbox afresh on each keystroke instead of creating it once when the frame is created 2023-01-17 21:43:53 +00:00			`* bind event to echo-area click, ideally dependent on what's being shown in there`
WIP popup commander 2023-01-01 16:49:15 +00:00			`* in general, can we bind commands to widget events?`
			`* command to create new buffer`

trim outdated stuff 2023-01-15 16:57:25 +00:00			`* suppress "Return is undefined" message after a command executes`
WIP popup commander 2023-01-01 16:49:15 +00:00
trim outdated stuff 2023-01-15 16:57:25 +00:00			`----`
make keyboard completions work 1. When adding a button to flowbox, the flowbox widget interposes a flowboxchild between the two, which can receive events and so becomes part of the tab order. this is why our buttons weren't getting activated - they weren't focused even though they looked focused. So, use labels instead of buttons for completions 2. For some reason I don't understand, flowboxchild widgets receive :activate only on keyboard activation. So instead of using it, we connect to :child-activated on the flowbox. 3. Setting widget:on_foo adds a handler to the widget instead of replacing what was previously there. There is no nice way to remove handlers from a widget either. Because we need a new on_child_activated handler every time the completions change, the only way I can see to achieve this is to create the flowbox afresh on each keystroke instead of creating it once when the frame is created 2023-01-17 21:43:53 +00:00
			`can we increase the testability? e.g. for command processing,`
			`define a command, feed in some keystrokes,`