Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ipython-notebook layer commands not working as expected (i.e. SPC f s doesn't really save the notebook) #5671

Closed
jbmorgado opened this issue Apr 4, 2016 · 8 comments
Labels
- Bug tracker - Ready for work stale marked as a stale issue/pr (usually by a bot)

Comments

@jbmorgado
Copy link

Description

Some ipython-notebook layer commands not working as expected. For instance: C-r doesn't call the ein:notebook-rename-command as expected, and worst SPC f s doesn't save the notebook like you would a regular buffer and as expressed in the documentation, instead it saves the all ein environment.

Reproduction guide

  • Start Emacs
  • Open a Jupyter notebook in command line.
  • Create a Notebook in Emacs with SPC a i n and then choosing new notebook (or open an existing one).

Observed behaviour:

  • SPC f s calls basic-save-buffer instead of the intended ein:notebook-save-notebook-command
  • C-r doesn't do anything

Expected behaviour:

  • SPC f s should save the notebook correctly by calling ein:notebook-save-notebook-command
  • C-r should rename the notebook correctly by calling ein:notebook-rename-command

System Info

  • OS: darwin
  • Emacs: 24.5.1
  • Spacemacs: 0.105.14
  • Spacemacs branch: master (rev. 3aff734)
  • Graphic display: t
  • Distribution: spacemacs
  • Editing style: vim
  • Completion: helm
  • Layers:
((auto-completion :variables auto-completion-enable-snippets-in-popup t auto-completion-complete-with-key-sequence-delay 0.8 auto-completion-enable-help-tooltip t auto-completion-private-snippets-directory "~/Dropbox/Apps/Yasnippet")
 emacs-lisp ess extra-langs
 (git :variables magit-repository-directories
      '("~/repos/"))
 html ipython-notebook
 (latex :variables latex-build-command "LatexMk")
 markdown
 (org :variables org-enable-github-support t)
 osx
 (python :variables python-enable-yapf-format-on-save t)
 shell
 (spell-checking :variables spell-checking-enable-auto-dictionary t spell-checking-enable-by-default nil)
 (syntax-checking :variables syntax-checking-enable-tooltips nil syntax-checking-enable-by-default nil)
 (version-control :variables version-control-diff-tool 'diff-hl version-control-global-margin t))
@AlejandroCatalina
Copy link
Contributor

Actually, those bindings are intented to be for major mode, so my guess is that it should work by pressing SPC m f s and so.

@cpaulik
Copy link
Contributor

cpaulik commented Apr 4, 2016

The SPC f s bug was introduced in 9befd20#diff-843bfb6ce8877b56e6d6252b9519852dL62

@TheBB @justbur is it still ok to use (evil-leader/set-key-for-mode)?

C-r is indeed supposed to be used with SPC m.

@magebeans
Copy link

Is there any way to map SPC f s to ein:notebook-save-notebook-command? I've been trying to override maps, remapping at hooks, everything. The closest I got was remapping it in evil-normal-state-map but that doesn't keep it buffer local, and for some reason I can't change it in the buffer local version of the map, evil-normal-state-local-map

@cpaulik
Copy link
Contributor

cpaulik commented Jun 10, 2016

Have you tried (evil-leader/set-key-for-mode) ?

@cpaulik
Copy link
Contributor

cpaulik commented Jun 11, 2016

@ManasGeorge See #6289

@magebeans
Copy link

Didn't seem to work. How is evil-leader/set-key-for-mode different from spacemacs/set-leader-keys-for-major-mode again?

@TheBB
Copy link
Contributor

TheBB commented Jun 11, 2016

They're the same, as @bmag mentioned in the PR.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- Bug tracker - Ready for work stale marked as a stale issue/pr (usually by a bot)
Projects
None yet
Development

No branches or pull requests

8 participants