This should keep too many calls to `request' from occurring at the same time.
Not sure I like blocking while waiting for previous calls to terminate, but for
the moment this seems the easiest solution without going the full deferred route
on `ein:query-singleton-ajax' and wrapping calls with semaphore checks via
concurrent.
Some good ideas from @dickmao, the only difference here is that notebook
autosave is not defaulted to being turned off as this might produce some
unexpected behavior for existing users. What I am doing is decreasing the
default frequency to autosaving once every five minutes.
Use deferred and callbacks instead of `:sync t` for tkf requests which
is known to have issues. Query server attributes once on
notebooklist-open to avoid sequencing issue #176 (but allow Resync).
Under curl backend, a second request for the same "key" as a pending
request will abort the latter, which has resulted in a clobbered
curl-cookie-jar file, so merely warn and don't abort.
Fix#176
Try, but seem to still be mostly failing. Think this is more a personal setup
issue than something in general but this change should, at the very least, not
do any harm.
Really basic support for eldoc, buidling off the oinfo cache code written to
support function annotations for the ein company backend. In theory should also
work the other completion backends, but untested at the moment.
Raise an error if the user does not specify the port or the full URL when
calling functions like `ein:notebooklist-open' and `ein:notebooklist-login'.
It can be debated that ein should assume http over https if the user doesn't
specify, but I currently think it shouldn't. Debate me.
Make `ein:gc-prepare-operation` idempotent and add missing call to
`ein:gc-complete-operation` - without it, each subsequently opened notebook
bumps gc threshold to a higher and higher value, effectively disabling all
garbage collection and seriously degrading overall performance.
Not sure if it is really doing anything, but ein:use-company-jedi-backend is now
a valid setting for ein:completion-backends.
More useful is that connected buffers now use ein's company completeion backend,
so completion should now work across all backends all across ein. Now let's get
something working in org!
Code for getting matches uses deferred and calls to `ein:completer-complete',
avoiding the hacks needed with `ein:completer-finish-completing-company' (names
are shorter too!). Using deferred makes reading the code a bit easier, I think.
EIN will also try to prepare function annotations via the python oinfo object.
Performance is not ideal when the completion candidate list is long, so there is
a new customizable variable `ein:allow-company-annotations' to control this
behavior.
Some functions to find the beginning and ending positions of the python symbol
at point - we might need this if we ever try to implement support for
capf (completion at point function).
