Because global-font-lock-mode will call font-lock-initial-fontify, the
inconsistency caused by nullifying font-lock-function while preserving
font-lock-fontify-buffer-function causes the whole buffer to get
fontified in polymode
Commit a969736 duplicated the before-until advice on
syntax-propertize. This broke polymode badly, and yet none of my
tests catch this (partly because it's hard to test font-lock).
C-c C-d breaks undo. Fix as follows:
Before: turn on slide indicator via C-c S, toggle type with C-c C-d
After: toggle type with C-c S.
Benefits: Fixes undo, simplifies slideshow operation, elpy users are
accustomed to having C-c C-d be "jump to doc"
M-x customize-group RET ein
Toggle Ein:Polymode
Avoid trying to emulate jump-to-definition, eldoc, and autocompletion
functionalities that Elpy will always do better.
Fixes#497#482#418
Do not assume python... leverage ESS to improve R interaction.
Fix both undo and fontify in the presence of toggling cells (`C-c
C-t`)
Fix and test switching kernels
Be more informative to the user when we cannot find an executing cell in either
`ein:worksheet-jump-to-first-executing-cell' or
`ein:worksheet-jump-to-next-executing-cell'.
Coursera appears to kill websockets every minute or so, and I'm
observing firsthand the buggy behaviors described in #356. This PR
cleans up the websocket code and kernel restart logic. Removed
backwards compatibility for the v2 messaging api
as keeping it in the presence of the refactoring would make it more
broken that it already was.
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.
Full undo support, including undoing cell actions, is still unstable and can
cause corruption of worksheet data so I am making this an optional feature. See
the variable `ein:worksheet-enable-undo', which by default will be set to nil.
It seems there are enough people out there still on Emacs 24 to warrant undoing
some of my recent moves away from eieio to cl-generic. For the near future I
will try to keep any changes that are incompatible with Emacs 24 to a
development branch. There is still probably plenty of opportunity to make the
code more future-proof for an eventual move away from eieio (I'm looking at you
oref and sref...)
