mirror of
https://github.com/vale981/tridactyl
synced 2025-03-05 09:31:41 -05:00
design.md: Fix markdown whitespace.
This commit is contained in:
Colin Caine
parent
4a3b7ee2df
commit
58ae747714
1 changed files with 104 additions and 104 deletions
200
design.md
200
design.md
|
|
@ -4,30 +4,30 @@ Replace ff's default control mechanism with one modelled on the one true editor,
|
|||
|
||||
Principles:
|
||||
|
||||
* Keyboard > mouse
|
||||
* default keybinds should be Vim-like
|
||||
* actions should be composable and repeatable
|
||||
* ex mode should expose all the browser functionality anyone might want
|
||||
* Arguable: most (all?) actions should have an ex mode version (departure from Vim?)
|
||||
* users can map actions and commands to other keys
|
||||
* Keyboard > mouse
|
||||
* default keybinds should be Vim-like
|
||||
* actions should be composable and repeatable
|
||||
* ex mode should expose all the browser functionality anyone might want
|
||||
* Arguable: most (all?) actions should have an ex mode version (departure from Vim?)
|
||||
* users can map actions and commands to other keys
|
||||
|
||||
Other objectives:
|
||||
|
||||
* be fast - the whole point of a keyboard interface is to be more efficient, don't compromise that with slow code
|
||||
* don't crash - we're the new UI and we shouldn't crash
|
||||
* be maintainable - code should be well documented, reasoned about and tested.
|
||||
* be fast - the whole point of a keyboard interface is to be more efficient, don't compromise that with slow code
|
||||
* don't crash - we're the new UI and we shouldn't crash
|
||||
* be maintainable - code should be well documented, reasoned about and tested.
|
||||
|
||||
Non-objectives for v1:
|
||||
|
||||
* insert mode (embedded (n)vim would be good for future)
|
||||
* caret or visual mode - I'm not good enough at vim to find these easier than selecting with the mouse, and they require text motions, which I would prefer to delegate to vim.
|
||||
* insert mode (embedded (n)vim would be good for future)
|
||||
* caret or visual mode - I'm not good enough at vim to find these easier than selecting with the mouse, and they require text motions, which I would prefer to delegate to vim.
|
||||
|
||||
Prior art:
|
||||
|
||||
* pentadactyl/vimperator - dying with XUL
|
||||
* cVim/vimium
|
||||
* vimfx - transitioning to WebExtensions, but no ex commands
|
||||
* qutebrowser/jumanji - see standalone route.
|
||||
* pentadactyl/vimperator - dying with XUL
|
||||
* cVim/vimium
|
||||
* vimfx - transitioning to WebExtensions, but no ex commands
|
||||
* qutebrowser/jumanji - see standalone route.
|
||||
|
||||
## Standalone route
|
||||
|
||||
|
|
@ -39,15 +39,15 @@ If it's comparable to this project done in webextensions, then we might want to
|
|||
|
||||
But what do we lose? What do the non-gecko bits of firefox do? What's left in the chrome repo if you remove webengine? I don't really know.
|
||||
|
||||
* Kerning/font presentation code? (text in qutebrowser looks bad on Windows, don't know why)
|
||||
* Cross-platform OS shit
|
||||
* Firefox sync is neat and would be missed.
|
||||
* safebrowsing?
|
||||
* how much security stuff in engine/vs browser?
|
||||
* webm, webgl and similar? Presumably handled either by the engine or externally, but maybe picking and maintaining link to external thing is expensive.
|
||||
* flash handling?
|
||||
* What UI stuff are we not replacing?
|
||||
* developer tools (neat, but no reason for us to re-implement).
|
||||
* Kerning/font presentation code? (text in qutebrowser looks bad on Windows, don't know why)
|
||||
* Cross-platform OS shit
|
||||
* Firefox sync is neat and would be missed.
|
||||
* safebrowsing?
|
||||
* how much security stuff in engine/vs browser?
|
||||
* webm, webgl and similar? Presumably handled either by the engine or externally, but maybe picking and maintaining link to external thing is expensive.
|
||||
* flash handling?
|
||||
* What UI stuff are we not replacing?
|
||||
* developer tools (neat, but no reason for us to re-implement).
|
||||
|
||||
We also lose access to the existing addon/extension repos. Maybe if we implemented webextension support in our own browser we'd get them back? Don't know how difficult that is.
|
||||
|
||||
|
|
@ -57,21 +57,21 @@ What addons do I use and would I miss them?
|
|||
|
||||
Should be part of the browser anyway:
|
||||
|
||||
* stylish --> :style, or maybe .vimperator/styles/ (with magic comments?)
|
||||
* greasemonkey --> builtin/extensions/autocmds
|
||||
* site blocker --> /etc/hosts
|
||||
* stylish --> :style, or maybe .vimperator/styles/ (with magic comments?)
|
||||
* greasemonkey --> builtin/extensions/autocmds
|
||||
* site blocker --> /etc/hosts
|
||||
|
||||
Maybe not:
|
||||
|
||||
* element hiding rules (ublock) not supported
|
||||
* tree tabs --> better :buffer?
|
||||
* lazarus form recovery is brilliant...
|
||||
* noscript is shit anyway
|
||||
* hide fedora is neat, but maybe just an element hiding list? Maybe it does have to parse differently.
|
||||
* example of neat addon that a smaller browser wouldn't have available, anyway.
|
||||
* ref control is neat, but the UI is pants. Would be easy to build an ex-mode interface.
|
||||
* pwgen is trivial
|
||||
* https everywhere --> builtin?
|
||||
* element hiding rules (ublock) not supported
|
||||
* tree tabs --> better :buffer?
|
||||
* lazarus form recovery is brilliant...
|
||||
* noscript is shit anyway
|
||||
* hide fedora is neat, but maybe just an element hiding list? Maybe it does have to parse differently.
|
||||
* example of neat addon that a smaller browser wouldn't have available, anyway.
|
||||
* ref control is neat, but the UI is pants. Would be easy to build an ex-mode interface.
|
||||
* pwgen is trivial
|
||||
* https everywhere --> builtin?
|
||||
|
||||
## WebExtension option
|
||||
|
||||
|
|
@ -81,36 +81,36 @@ cVim and vimium implement some kind of vim experience using webextensions, but (
|
|||
|
||||
TODO:
|
||||
|
||||
* Test cVim and vimium
|
||||
* Look for UI WebExtension proposals
|
||||
* Test cVim and vimium
|
||||
* Look for UI WebExtension proposals
|
||||
|
||||
### Required WebExtension APIs
|
||||
|
||||
Don't exist:
|
||||
|
||||
* keyboard (not yet existent) (if content script isn't nice enough)
|
||||
* ui (for hiding and for non-content-script statusline, tho not so important)
|
||||
* keyboard (not yet existent) (if content script isn't nice enough)
|
||||
* ui (for hiding and for non-content-script statusline, tho not so important)
|
||||
|
||||
Do exist:
|
||||
|
||||
* storage (.vimperatorrc)
|
||||
* tabs
|
||||
* history (for auto completion of open, etc)
|
||||
* bookmarks (auto completion, obvious)
|
||||
* windows (buffers)
|
||||
* webNavigation (autocmds) - maybe content script would just do this for us.
|
||||
* storage (.vimperatorrc)
|
||||
* tabs
|
||||
* history (for auto completion of open, etc)
|
||||
* bookmarks (auto completion, obvious)
|
||||
* windows (buffers)
|
||||
* webNavigation (autocmds) - maybe content script would just do this for us.
|
||||
|
||||
### Stuff we want to do that I know how to do:
|
||||
|
||||
* Show hints:
|
||||
* For each link in viewport (how to restrict to viewport?):
|
||||
* Add an element styled to appear on top of it
|
||||
* Listen for keystrokes.
|
||||
* Does vimperator just go for <a> tags? I think it probably knows about elements that can be clicked for other effects.
|
||||
* Change tab
|
||||
* tabs.update(tabtodisplay, {active: true})
|
||||
* Change window focus
|
||||
* windows.update(windowtofocus, {focused: true})
|
||||
* Show hints:
|
||||
* For each link in viewport (how to restrict to viewport?):
|
||||
* Add an element styled to appear on top of it
|
||||
* Listen for keystrokes.
|
||||
* Does vimperator just go for <a> tags? I think it probably knows about elements that can be clicked for other effects.
|
||||
* Change tab
|
||||
* tabs.update(tabtodisplay, {active: true})
|
||||
* Change window focus
|
||||
* windows.update(windowtofocus, {focused: true})
|
||||
|
||||
### Stuff I don't know how to do:
|
||||
|
||||
|
|
@ -128,85 +128,85 @@ Do exist:
|
|||
* redo/undo (in text boxes)
|
||||
|
||||
* ff elctrolysis framework (concurrency)
|
||||
* Do we automatically use it with we're using webextensions? Seems unlikely...
|
||||
* How to store state?
|
||||
* e.g. command history, marks, mappings, configuration, autocmd registry,
|
||||
* Do we automatically use it with we're using webextensions? Seems unlikely...
|
||||
* How to store state?
|
||||
* e.g. command history, marks, mappings, configuration, autocmd registry,
|
||||
|
||||
## Vimperator features in sort of priority order for a MVP
|
||||
|
||||
### Normal mode
|
||||
|
||||
j/k
|
||||
gt/gT
|
||||
H/L
|
||||
b
|
||||
/
|
||||
n
|
||||
N
|
||||
f
|
||||
y
|
||||
]]
|
||||
rapid hint mode?
|
||||
j/k
|
||||
gt/gT
|
||||
H/L
|
||||
b
|
||||
/
|
||||
n
|
||||
N
|
||||
f
|
||||
y
|
||||
]]
|
||||
rapid hint mode?
|
||||
|
||||
### Ex commands
|
||||
|
||||
o
|
||||
t
|
||||
w
|
||||
nnoremap
|
||||
h
|
||||
source
|
||||
save
|
||||
autocmd
|
||||
o
|
||||
t
|
||||
w
|
||||
nnoremap
|
||||
h
|
||||
source
|
||||
save
|
||||
autocmd
|
||||
|
||||
+autocomplete
|
||||
|
||||
### Hard mode
|
||||
|
||||
:js
|
||||
:!
|
||||
:js
|
||||
:!
|
||||
|
||||
## Architecture
|
||||
|
||||
ex-commands as functions (typed and with helper functions in some other scope):
|
||||
|
||||
* open(url)
|
||||
* scroll(x=+10)
|
||||
* mark(<elem>)
|
||||
* map(actions, keys)
|
||||
* ...
|
||||
* open(url)
|
||||
* scroll(x=+10)
|
||||
* mark(<elem>)
|
||||
* map(actions, keys)
|
||||
* ...
|
||||
|
||||
helper functions for actions:
|
||||
|
||||
* scroll-x, scroll-y
|
||||
* jumplist.get/getrelative/store
|
||||
* undo-tab-deletion
|
||||
* scroll-x, scroll-y
|
||||
* jumplist.get/getrelative/store
|
||||
* undo-tab-deletion
|
||||
|
||||
Count and range:
|
||||
|
||||
* given as arguments?
|
||||
* just repeat the call 'count' times?
|
||||
* given as arguments?
|
||||
* just repeat the call 'count' times?
|
||||
|
||||
for default actions, a mapping from key to helper function.
|
||||
|
||||
Generated parsers (command and normal mode):
|
||||
|
||||
* command mode pretty conventional. Include type checking.
|
||||
* For auto-complete to work, need to be able to parse partial results sensibly.
|
||||
* actions will be a slightly weirder grammar:
|
||||
* More permissive
|
||||
* Time sensitive
|
||||
* command mode pretty conventional. Include type checking.
|
||||
* For auto-complete to work, need to be able to parse partial results sensibly.
|
||||
* actions will be a slightly weirder grammar:
|
||||
* More permissive
|
||||
* Time sensitive
|
||||
|
||||
* In vim, actions compose as you write them (d takes a motion as an argument, for example), I can't think of any examples of this in vimperator: actions sometimes take a count or argument, but that argument is never an action.
|
||||
* In vim, actions compose as you write them (d takes a motion as an argument, for example), I can't think of any examples of this in vimperator: actions sometimes take a count or argument, but that argument is never an action.
|
||||
|
||||
* If actions did compose, we would have to give them types, as vim does for motions, and the parsing would be less trivial.
|
||||
* If actions did compose, we would have to give them types, as vim does for motions, and the parsing would be less trivial.
|
||||
|
||||
Autocomplete functions for commands:
|
||||
|
||||
* Split from implementation of command.
|
||||
* Could perhaps be automatic from command's parameter types?
|
||||
* Split from implementation of command.
|
||||
* Could perhaps be automatic from command's parameter types?
|
||||
|
||||
Some actions have their own interactive mini-mode:
|
||||
|
||||
* hints
|
||||
* searching
|
||||
* hints
|
||||
* searching
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue