gogoengie
The legacy extension they are referring to is Tab Groups [0]. It allowed you to separate the tabs of a single session into groups. Selecting the active group would hide the other tabs.
[0] https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...
reported: https://github.com/philc/vimium/issues/2510
closed with: https://github.com/philc/vimium/pull/2602
I'm not familiar with their release cycle, so I don't know when it'll hit AMO.
Personally, I'm running Firefox 55.0.3 with `vimium-ff` 1.6.0 (current build on addons.mozilla.org), and the `t` keybinding opens new tabs just like `Ctrl-t`. Command repetition also works (eg, `5t`).
https://github.com/piroor/treestyletab/issues/1224#issuecomm...
https://github.com/piroor/treestyletab/issues?q=is%3Aissue+i...
For a general progress report:
https://github.com/piroor/treestyletab/issues/1224#issuecomm...
https://www.youtube.com/watch?v=4QCJlBDAK80
The performance jump in capture time and resolution blew me away. Really exciting to see it coming on-line.
My private notes include a claim (original source uncited, sadly) that because the prime density from 1..n decreases (approximately) as `1/ln(n)`, then the corresponding effective key space density for RSA decreases at a related rate, which was what led to the corresponding reduction in the "equivalent" key size. If my notes on this are complete bunk I'd love to hear it. (Even a simple 'yes' would suffice and I'll revisit the subject.) Ta!
[0] https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-...
[edit: this paragraph, based on my old notes on the subject, seems to be incorrect, see sdevlin's comment below] More specifically, because of the RSA dependency on prime numbers, the RSA effective key space is very sparse (which is why going from 2048-bit RSA to 4096-bit RSA only increases the effective key space by ~16%). With elliptic curves, the key space is very dense, which reduces the key size for an "equivalent" encryption strength. Elliptic curve solutions also tend to be more computationally efficient, both in terms of key generation as well as encryption operations; this performance delta increases rapidly as "equivalent" key sizes grow.
Regarding "trending":
-- They're under active fundamental research, which is fun (RSA is well established, whereas new EC proposals are still under active debate)
-- They've been the subject of some drama, which is also "fun" (conspiracy theories related to several EC proposals/recommendations, debates regarding a primary EC researcher, etc)
I group my work into topics by desktop; one browser instance per desktop, with an average total of 200+ tabs across eight windows. Restarting Firefox means sorting eight browser instances, one hotkey to snap them to half-width. Restarting Chrome required sorting sixteen browser windows, then manually aligning each primary window plus its tab window using the mouse. I tried, I really did, but that never became less of a pain.
Add it to your `ftplugin/python.vim`. Requires you to have activated the Conda environment before opening the Python file, uses hard-coded Python versions, doesn't work with multiple environments, doesn't bother with `os.path.join` so no Windows compatibility, etc etc. Like I said: a hack.
" Cheap trick to use the Conda environment with omnicompletion
python3 << EOF
import os
import sys
cenv = os.environ.get('CONDA_PREFIX')
if cenv is not None:
# Taken from `sys.path` as reported by ipython
sys.path.insert(0, cenv + '/lib/python3.5/site-packages')
sys.path.insert(0, cenv + '/lib/python3.5/lib-dynload')
sys.path.insert(0, cenv + '/lib/python3.5/plat-linux')
sys.path.insert(0, cenv + '/lib/python3.5')
sys.path.insert(0, cenv + '/lib/python35.zip')
sys.path.insert(0, cenv + '/bin')
EOF
set omnifunc=python3complete#Complete
More useful, IMHO, is the general solution of jumping to the definition that would be resolved by the python interpreter, regardless of location. For that, the key binding will depend on the plugin. For `jedi-vim`, you use `<leader>d` [0].
Incidentally, if you're new to using VIM as a python IDE, also note the value of `jedi-vim` providing Python docstrings via the standard VIM keybinding `K`. This is also mentioned in [0].
From all these considerations, there are two problems: 1. Measurement technique (getting the data) 2. System dynamics calculations (analyzing the data)
For measurement, the article mentions both visual and spectroscopic (wavelength) measurements; overviews of these and other techniques are discussed in [1]. You are correct, distance from the measurement device makes things interesting, especially in the presence of atmospheric distortion, but there are lots of tricks that can improve the effective resolution (eg, speckle imaging, which uses a bunch of images taken in rapid succession [2]).
As for the orbital period, think of it like measurements of a line. You don't need every point, just two. If you have several measurements of a celestial body, you can plot them on one of the (MANY) celestial coordinate systems [3] and do some estimates. Longer periods mean more observations for better accuracy, but you don't need to wait for a complete orbital period to get a decent estimate.
Hope this at least gives some useful keywords for your searches!
[1] https://en.wikipedia.org/wiki/Binary_star#Methods_of_observa... [2] https://en.wikipedia.org/wiki/Speckle_imaging [3] http://csep10.phys.utk.edu/astr161/lect/time/coordinates.htm...