hiro/tridactyl
1
0
Fork 0
mirror of https://github.com/vale981/tridactyl synced 2025-03-05 09:31:41 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

design.md: Fix markdown whitespace.

Browse source
This commit is contained in:
Colin Caine 2017-02-13 17:49:49 +00:00
parent 4a3b7ee2df
commit 58ae747714
1 changed files with 104 additions and 104 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

208
design.md
View file

@ -4,30 +4,30 @@ Replace ff's default control mechanism with one modelled on the one true editor,
Principles: Principles:
* Keyboard > mouse * Keyboard > mouse
* default keybinds should be Vim-like * default keybinds should be Vim-like
* actions should be composable and repeatable * actions should be composable and repeatable
* ex mode should expose all the browser functionality anyone might want * ex mode should expose all the browser functionality anyone might want
* Arguable: most (all?) actions should have an ex mode version (departure from Vim?) * Arguable: most (all?) actions should have an ex mode version (departure from Vim?)
* users can map actions and commands to other keys * users can map actions and commands to other keys
Other objectives: Other objectives:
* be fast - the whole point of a keyboard interface is to be more efficient, don't compromise that with slow code * 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 * 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 maintainable - code should be well documented, reasoned about and tested.
Non-objectives for v1: Non-objectives for v1:
* insert mode (embedded (n)vim would be good for future) * 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. * 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: Prior art:
* pentadactyl/vimperator - dying with XUL * pentadactyl/vimperator - dying with XUL
* cVim/vimium * cVim/vimium
* vimfx - transitioning to WebExtensions, but no ex commands * vimfx - transitioning to WebExtensions, but no ex commands
* qutebrowser/jumanji - see standalone route. * qutebrowser/jumanji - see standalone route.
## 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. 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) * Kerning/font presentation code? (text in qutebrowser looks bad on Windows, don't know why)
* Cross-platform OS shit * Cross-platform OS shit
* Firefox sync is neat and would be missed. * Firefox sync is neat and would be missed.
* safebrowsing? * safebrowsing?
* how much security stuff in engine/vs browser? * 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. * 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? * flash handling?
* What UI stuff are we not replacing? * What UI stuff are we not replacing?
* developer tools (neat, but no reason for us to re-implement). * 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. 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: Should be part of the browser anyway:
* stylish --> :style, or maybe .vimperator/styles/ (with magic comments?) * stylish --> :style, or maybe .vimperator/styles/ (with magic comments?)
* greasemonkey --> builtin/extensions/autocmds * greasemonkey --> builtin/extensions/autocmds
* site blocker --> /etc/hosts * site blocker --> /etc/hosts
Maybe not: Maybe not:
* element hiding rules (ublock) not supported * element hiding rules (ublock) not supported
* tree tabs --> better :buffer? * tree tabs --> better :buffer?
* lazarus form recovery is brilliant... * lazarus form recovery is brilliant...
* noscript is shit anyway * noscript is shit anyway
* hide fedora is neat, but maybe just an element hiding list? Maybe it does have to parse differently. * 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. * 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. * ref control is neat, but the UI is pants. Would be easy to build an ex-mode interface.
* pwgen is trivial * pwgen is trivial
* https everywhere --> builtin? * https everywhere --> builtin?
## WebExtension option ## WebExtension option
@ -81,36 +81,36 @@ cVim and vimium implement some kind of vim experience using webextensions, but (
TODO: TODO:
* Test cVim and vimium * Test cVim and vimium
* Look for UI WebExtension proposals * Look for UI WebExtension proposals
### Required WebExtension APIs ### Required WebExtension APIs
Don't exist: Don't exist:
* keyboard (not yet existent) (if content script isn't nice enough) * keyboard (not yet existent) (if content script isn't nice enough)
* ui (for hiding and for non-content-script statusline, tho not so important) * ui (for hiding and for non-content-script statusline, tho not so important)
Do exist: Do exist:
* storage (.vimperatorrc) * storage (.vimperatorrc)
* tabs * tabs
* history (for auto completion of open, etc) * history (for auto completion of open, etc)
* bookmarks (auto completion, obvious) * bookmarks (auto completion, obvious)
* windows (buffers) * windows (buffers)
* webNavigation (autocmds) - maybe content script would just do this for us. * webNavigation (autocmds) - maybe content script would just do this for us.
### Stuff we want to do that I know how to do: ### Stuff we want to do that I know how to do:
* Show hints: * Show hints:
* For each link in viewport (how to restrict to viewport?): * For each link in viewport (how to restrict to viewport?):
* Add an element styled to appear on top of it * Add an element styled to appear on top of it
* Listen for keystrokes. * Listen for keystrokes.
* Does vimperator just go for <a> tags? I think it probably knows about elements that can be clicked for other effects. * Does vimperator just go for <a> tags? I think it probably knows about elements that can be clicked for other effects.
* Change tab * Change tab
* tabs.update(tabtodisplay, {active: true}) * tabs.update(tabtodisplay, {active: true})
* Change window focus * Change window focus
* windows.update(windowtofocus, {focused: true}) * windows.update(windowtofocus, {focused: true})
### Stuff I don't know how to do: ### Stuff I don't know how to do:
@ -118,95 +118,95 @@ Do exist:
* Use promises from a sane language (coffeescript, livescript, elm, etc). * Use promises from a sane language (coffeescript, livescript, elm, etc).
* Find promises to cancel their chain. * Find promises to cancel their chain.
* Communication between background and content scripts. * Communication between background and content scripts.
* Access a single tab's history * Access a single tab's history
* scroll * scroll
* print * print
* zoom * zoom
* access OS clipboards * access OS clipboards
* redo/undo (in text boxes) * redo/undo (in text boxes)
* ff elctrolysis framework (concurrency) * ff elctrolysis framework (concurrency)
* Do we automatically use it with we're using webextensions? Seems unlikely... * Do we automatically use it with we're using webextensions? Seems unlikely...
* How to store state? * How to store state?
* e.g. command history, marks, mappings, configuration, autocmd registry, * e.g. command history, marks, mappings, configuration, autocmd registry,
## Vimperator features in sort of priority order for a MVP ## Vimperator features in sort of priority order for a MVP
### Normal mode ### Normal mode
j/k j/k
gt/gT gt/gT
H/L H/L
b b
/ /
n n
N N
f f
y y
]] ]]
rapid hint mode? rapid hint mode?
### Ex commands ### Ex commands
o o
t t
w w
nnoremap nnoremap
h h
source source
save save
autocmd autocmd
+autocomplete +autocomplete
### Hard mode ### Hard mode
:js :js
:! :!
## Architecture ## Architecture
ex-commands as functions (typed and with helper functions in some other scope): ex-commands as functions (typed and with helper functions in some other scope):
* open(url) * open(url)
* scroll(x=+10) * scroll(x=+10)
* mark(<elem>) * mark(<elem>)
* map(actions, keys) * map(actions, keys)
* ... * ...
helper functions for actions: helper functions for actions:
* scroll-x, scroll-y * scroll-x, scroll-y
* jumplist.get/getrelative/store * jumplist.get/getrelative/store
* undo-tab-deletion * undo-tab-deletion
Count and range: Count and range:
* given as arguments? * given as arguments?
* just repeat the call 'count' times? * just repeat the call 'count' times?
for default actions, a mapping from key to helper function. for default actions, a mapping from key to helper function.
Generated parsers (command and normal mode): Generated parsers (command and normal mode):
* command mode pretty conventional. Include type checking. * command mode pretty conventional. Include type checking.
* For auto-complete to work, need to be able to parse partial results sensibly. * For auto-complete to work, need to be able to parse partial results sensibly.
* actions will be a slightly weirder grammar: * actions will be a slightly weirder grammar:
* More permissive * More permissive
* Time sensitive * 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: Autocomplete functions for commands:
* Split from implementation of command. * Split from implementation of command.
* Could perhaps be automatic from command's parameter types? * Could perhaps be automatic from command's parameter types?
Some actions have their own interactive mini-mode: Some actions have their own interactive mini-mode:
* hints * hints
* searching * searching