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

Add shortcut to edit cell #9929

Merged
merged 1 commit into from Sep 12, 2016

Conversation

Projects
None yet
5 participants
@takluyver
Member

takluyver commented Sep 2, 2016

I've integrated some code @carlsmith posted on the mailing list to open the current cell in a text editor to edit a larger chunk of code. This reduces the need for %edit, and has the benefit that edited code goes into the IPython history.

What should the shortcut be? Carl used Ctrl-N, but nothing about that says 'edit' to me. I've gone for F2, which is used in Excel to edit the selected cell, and I've enabled it for both emacs and vi keybindings. If we don't use an F-key (or something funky like Insert), we probably need separate emacs and vi shortcuts.

@takluyver takluyver added this to the 5.2 milestone Sep 2, 2016

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Sep 5, 2016

Member

No objection for F2. Is this 5.2 material ?

Member

Carreau commented Sep 5, 2016

No objection for F2. Is this 5.2 material ?

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Sep 12, 2016

Member

It's a simple enough addition that I'd be inclined to backport it to 5.x.

Member

takluyver commented Sep 12, 2016

It's a simple enough addition that I'd be inclined to backport it to 5.x.

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Sep 12, 2016

Member

It's a simple enough addition that I'd be inclined to backport it to 5.x.

Fair enough, let's add F2 for Py2.

Member

Carreau commented Sep 12, 2016

It's a simple enough addition that I'd be inclined to backport it to 5.x.

Fair enough, let's add F2 for Py2.

@Carreau Carreau merged commit 4e52127 into ipython:master Sep 12, 2016

3 checks passed

codecov/patch 25.00% of diff hit (target 0.00%)
Details
codecov/project 73.14% (-0.01%) compared to b067fe9
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

Carreau added a commit to Carreau/ipython that referenced this pull request Sep 18, 2016

Backport PR #9929: Add shortcut to edit cell
I've integrated some code _carlsmith posted on the mailing list to open the current cell in a text editor to edit a larger chunk of code. This reduces the need for `%edit`, and has the benefit that edited code goes into the IPython history.

What should the shortcut be? Carl used **Ctrl-N**, but nothing about that says 'edit' to me. I've gone for **F2**, which is used in Excel to edit the selected cell, and I've enabled it for both emacs and vi keybindings. If we don't use an F-key (or something funky like Insert), we probably need separate emacs and vi shortcuts.
@anntzer

This comment has been minimized.

Show comment
Hide comment
@anntzer

anntzer Jan 31, 2017

Contributor

Can vimmers also get "v" (in command mode) for this purpose? It is the equivalent shortcut in vi-mode for bash & friends.

Contributor

anntzer commented Jan 31, 2017

Can vimmers also get "v" (in command mode) for this purpose? It is the equivalent shortcut in vi-mode for bash & friends.

@takluyver takluyver deleted the takluyver:edit-cell-shortcut branch Jan 31, 2017

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Jan 31, 2017

Member

Sounds reasonable. Do you want to make a PR adding it? See IPython.terminal.shortcuts.

Member

takluyver commented Jan 31, 2017

Sounds reasonable. Do you want to make a PR adding it? See IPython.terminal.shortcuts.

@carlsmith

This comment has been minimized.

Show comment
Hide comment
@carlsmith

carlsmith Feb 1, 2017

Contributor

Thanks for adding this @takluyver.

P.S. I only went with n because I normally use ne (the Nice Editor).

Contributor

carlsmith commented Feb 1, 2017

Thanks for adding this @takluyver.

P.S. I only went with n because I normally use ne (the Nice Editor).

@plumps

This comment has been minimized.

Show comment
Hide comment
@plumps

plumps Feb 3, 2017

Funny, in my case, it doesn't seem to respect $EDITOR, while %edit does.

plumps commented Feb 3, 2017

Funny, in my case, it doesn't seem to respect $EDITOR, while %edit does.

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 3, 2017

Member

Funny, in my case, it doesn't seem to respect $EDITOR, while %edit does.

Strange. Try updating Prompttoolkit.
What version of IPython and PTK do you have ?

Member

Carreau commented Feb 3, 2017

Funny, in my case, it doesn't seem to respect $EDITOR, while %edit does.

Strange. Try updating Prompttoolkit.
What version of IPython and PTK do you have ?

@plumps

This comment has been minimized.

Show comment
Hide comment
@plumps

plumps Feb 3, 2017

IPython 5.2.2
prompt-toolkit 1.0.13

plumps commented Feb 3, 2017

IPython 5.2.2
prompt-toolkit 1.0.13

@plumps

This comment has been minimized.

Show comment
Hide comment
@plumps

plumps Feb 3, 2017

Ah my EDITOR value of subl -w (which means sublime shall wait to return until files are closed) seams to be the culprit.

EDITOR=vim works though

plumps commented Feb 3, 2017

Ah my EDITOR value of subl -w (which means sublime shall wait to return until files are closed) seams to be the culprit.

EDITOR=vim works though

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 4, 2017

Member

Ah my EDITOR value of subl -w (which means sublime shall wait to return until files are closed) seams to be the culprit.

EDITOR=vim works though

Ha ! Need to be fixed in prompt_toolkit. As things get passed manually to subprocess.call it's trying to find the executable subl -w

As a workaround create a sublw file in your $PATH,make it executable and use it as your $EDITOR:

~/bin $ cat sublw
#!/bin/bash
subl -w $1
 ~/bin $ chmod u+x sublw

That should work.

Member

Carreau commented Feb 4, 2017

Ah my EDITOR value of subl -w (which means sublime shall wait to return until files are closed) seams to be the culprit.

EDITOR=vim works though

Ha ! Need to be fixed in prompt_toolkit. As things get passed manually to subprocess.call it's trying to find the executable subl -w

As a workaround create a sublw file in your $PATH,make it executable and use it as your $EDITOR:

~/bin $ cat sublw
#!/bin/bash
subl -w $1
 ~/bin $ chmod u+x sublw

That should work.

Carreau added a commit to Carreau/python-prompt-toolkit that referenced this pull request Feb 4, 2017

Handle arguments in the $EDITOR or $VISUAL env variable
On OSX, users will typically use `subl -w` to use sublime tet on
blocking mode, though this will be passed ass it to subprocess.call
leading to the `subl -w` command not found.

See ipython/ipython#9929

this should fix that. It would affect users with actual space on the
path of their editor executable, but I'm unsure how to handle both case.
It seem to me like passing flags would be the most common use case.

Workaround is to tell users to create an shim executable which pass the
options.
@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 4, 2017

Member

I've submitted a patch to prompt toolkit.

Member

Carreau commented Feb 4, 2017

I've submitted a patch to prompt toolkit.

@plumps

This comment has been minimized.

Show comment
Hide comment
@plumps

plumps Feb 4, 2017

I'll wait for the patched prompt-toolkit

plumps commented Feb 4, 2017

I'll wait for the patched prompt-toolkit

jonathanslenders added a commit to jonathanslenders/python-prompt-toolkit that referenced this pull request Feb 5, 2017

Handle arguments in the $EDITOR or $VISUAL env variable
On OSX, users will typically use `subl -w` to use sublime tet on
blocking mode, though this will be passed ass it to subprocess.call
leading to the `subl -w` command not found.

See ipython/ipython#9929

this should fix that. It would affect users with actual space on the
path of their editor executable, but I'm unsure how to handle both case.
It seem to me like passing flags would be the most common use case.

Workaround is to tell users to create an shim executable which pass the
options.

meeseeksdev bot pushed a commit that referenced this pull request Feb 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment