CTRL+D delete string shortcut removed in jupyter 4.0.0

[mahashiah]

Deleting a line (string) has become an impossible task on my keyboard since developers removed the Ctrl+D shortcut in version 4.0. I must commend the developers for making it exceptionally challenging to utilize Jupyter on a 60% mechanical keyboard lacking a dedicated delete key. It seems to be an erroneous assumption that every keyboard possesses such a key, which is evidently not the case. Moreover, you have imposed the compulsory assignment of delete as a vital key while assigning Ctrl+D to a new feature that is essentially futile. It would have been far more practical to allocate Ctrl+F for word searches, as you did for Ctrl+D. How can I delete a row in Jupyter 4.0 when the Ctrl+D shortcut is invariably linked to an unhelpful search function? To be frank, I had a favorable opinion of Jupyter, but now I find it necessary to downgrade and revert to a previous version, abandoning 4.0 entirely.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[JasonWeill]

@mahashiah Thank you for your suggestion! We apologize for the regression and we welcome contributions to reinstate it.

[krassowski]

A few clarifications to dissect the issue:

• there was no search keybinding for Ctrl + D added in by JupyterLab team in JupyterLab 4.0. The search widget keybindings are defined here:
  

  jupyterlab/packages/documentsearch-extension/schema/plugin.json

  Lines 35 to 56 in 94a27fb

  	"jupyter.lab.shortcuts": [
  	{
  	"command": "documentsearch:start",
  	"keys": ["Accel F"],
  	"selector": ".jp-mod-searchable"
  	},
  	{
  	"command": "documentsearch:highlightNext",
  	"keys": ["Accel G"],
  	"selector": ".jp-mod-searchable"
  	},
  	{
  	"command": "documentsearch:highlightPrevious",
  	"keys": ["Accel Shift G"],
  	"selector": ".jp-mod-searchable"
  	},
  	{
  	"command": "documentsearch:end",
  	"keys": ["Escape"],
  	"selector": ".jp-mod-searchable"
  	}
  	],

• the change is a result of migration from CodeMirror5 to CodeMirror6 which changed the default keybindings. The new keybinding is Ctrl + Shift + K (defined in codemirror/commands package, here) but it conflicts with the JupyterLab shortcut to open Table of Contents sidebar
  • CodeMirror does define Mod-d for select next occurrence command (which we do not need in most editors as described later)

How we can address this?

• the default keymap of CodeMirror in JupyterLab can be amended to reduce friction for users migrating from 3.x; this likely should happen either;
  • in CodeMirrorEditorFactory if we want to hard-code the shortcut, or
  • getDefaultExtensions if we want to expose this as customisable option
• the search keybindings keymap should probably be removed from inline editors (those are added here) because JupyterLab has a custom search & replace implementation - now independent of CodeMirror; the downstream users will still be able to enable the search by passing extensions in options (which we may need to do in JSON setting editor as this one does not implement documentsearch provider)

Finally, @mahashiah:

• please be mindful that Project Jupyter contributors (including contributions to our GitHub discussions) are expected to follow the Code of Conduct, in particular I would like to highlight the section about expected behaviour - sarcastic and accusative tone do not feel appropriate here.
• in future please feel welcome to contribute by trying out beta/release candidate versions - critical feedback is easier to address at these stages, and these can usually be trialled without installation on Binder.

[mahashiah]

@krassowski krassowski thank you for your dedicated time and clarifying that I did not intend to show a sarcast

ic or provocative tone at any time, it was translation by gpt. what happened was a critical error, 60% keyboards (60%size) mechanic keyboards, don't have the delete key, just backspace, jupyterlab 3.6 has the default shortcut to delete in crtl+D, in version 4.0.0 released this shortcut was changed, when I installed the version 4.0 in my environment crtl+D was assigned a word search function, when pressing crtl+D it selected a word and found all the same words (as if it were crtl+F) I accessed the settings part to change the shortcuts and this search The function had crtl+D frozen, making it impossible to assign crtl+D to any other shortcut, including delete. I can redo the process with recording and if the same problem occurs, bring the video here. when closed we can, if possible, delete the topic. Thankyou.

[SysuJayce]

So can we have ctrl+D to delete line again ?

[andrii-i]

Thank you for interest in this issue @SysuJayce. It seems that people participating in the discussion agree that the default keymap of CodeMirror in JupyterLab can be amended and this issue is planned to be resolved within current 4.0.x milestone. Contributions to resolve it are also welcomed.

[SysuJayce]

Thank you for interest in this issue @SysuJayce. It seems that people participating in the discussion agree that the default keymap of CodeMirror in JupyterLab can be amended and this issue is planned to be resolved within current 4.0.x milestone. Contributions to resolve it are also welcomed.

Thank you @andrii-i . I also migrate from 3.x and I like the keyboard shortcut of 3.x. It is great to know that we can change the default keymap in 4.x 👍

[RafalSkolasinski]

I would really love if it would be possible to have both shortcuts for multi select and full line removal. Preferably configurable to have mutli select on ctrl+d and line removal on ctrl+shift+k to match VS Code defaults

[kelvinAI]

For people who uses normal keyboards which have the Delete key, Shift+Delete seems to do the job of deleting the line the cursor is on, at least on Jupyter Lab 4.0.3 with default settings. That being said I'd still advocate for Ctrl+D as it is consistent with popular editors such as VS Code etc and it's easier to execute.

[y-he2]

For people who uses normal keyboards which have the Delete key, Shift+Delete seems to do the job of deleting the line the cursor is on, at least on Jupyter Lab 4.0.3 with default settings. That being said I'd still advocate for Ctrl+D as it is consistent with popular editors such as VS Code etc and it's easier to execute.

It seems Shift+Del is equivalent as Line Cut in standard PC:
https://en.wikipedia.org/wiki/Cut,_copy,_and_paste#Common_keyboard_shortcuts
so a Ctrl-X would prob do the same trick on Windows. Although beaware it could mess up your current clip-board, which personally is the biggest reason to use a separate hotkey (eg. Ctrl-D) for "line delete".

Also I would like to contribute to this issue. (Ctrl-D is like a religious thing to me when rapid prototyping.) Could someone point a direction where to look into, or is there any meeting I could join regarding this? Just saw @krassowski post above, may start look from there.

[krassowski]

Hi @y-he2 are you still interested in contributing? Let me know if you need further pointers.

[y-he2]

Hi @y-he2 are you still interested in contributing? Let me know if you need further pointers.

Absolutely, Im pretty determined to solve this and #4778.
(Two draw back may be I have never worked in the framework used by Jupyter 4 before, also I have limited time.)

It would be easiest if I can join some meeting or if we can do some "Discord" to get me started.

[JasonWeill]

@y-he2 Thank you for your interest! We don't have an official Discord, but you can join our Gitter chat server here: https://app.gitter.im/#/room/#jupyter_jupyter:gitter.im

[krassowski]

We also have a contributing guide - don't feel obliged to read it all, but it will likely have answers to most of questions about setup and contributing, basically if you can't find something in there after 15 minutes shout out in gitter.

[y-he2]

Right, thanks for the info, will join and have a look at the guide.

[SysuJayce]

any progress?

[y-he2]

I have setup the environment and started to study the code. Have been busy all week days as usual.
Trying to figure out next how to do amount other stuff:

"or
[getDefaultExtensions] https://github.com/jupyterlab/jupyterlab/blob/94a27fb987afddaf75d65265d825f24774247598/packages/codemirror/src/extension.ts#LL593C19-L593C39) if we want to expose this as customisable option"

and how these factories works with custom hotkey stuff.

Can keep us updated with further detail when I have more.

[jtrauer]

Desperately need ctrl-D back.

[dimi-tree]

Is this issue being worked on? I can help if no one is looking at it.

[y-he2]

Is this issue being worked on? I can help if no one is looking at it.

My current understanding is we understand the priority for it, but not being worked on too much unfortunately. (pls correct me if wrong) So yes, please do help if you have some frontend skills or even better CodeMirror (the editor component used in Jupyter Lab) experience.

As I said in #4778 (comment), I saw these two issues are related in terms of hotkey customization/mechanism in CodeMirrow. I was pretty determined to solve them, however I totally underestimated the complexity with CodeMirror, my frontend skills, and spare time.

I do still believe these two issues are pretty important to solve, so please, any one with the right skills are needed. Im slowly studying the code but let me know if I can help in any way. My understanding is it looks like a small thing to implement but may require some big change in the CodeMirror code structure, or at least some helper mechanism to be implemented for hotkeys.

Maybe we can create a Discord server or Gitter thread specific for these two issues (this and #4778), do you think its good practice @JasonWeill @krassowski ?

[marius311]

I know this sounds dramatic but as someone that was rght on the edge of dropping JupyterLab entirely in favor VSCode's Jupyter because of its superior editor functionality, this ended up being a straw the broke the camels back and I've switched. Just my personal feedback if its helpful for devs to prioritze work. I could see myself swtiching back bc other stuff is better here, but I currently feel handcuffed in the JupyterLab editor (worse multicursor, less productivity plugins, ofc the now-missing Ctrl+D, etc...)

[JasonWeill]

@y-he2 @marius311 Thank you for your continuing engagement with this issue! You can join us in our Matrix (Gitter, Element) chat room about JupyterLab here: https://matrix.to/#/#jupyterlab_jupyterlab:gitter.im

Our developers would be happy to review a pull request to help fix this issue.

[y-he2]

I know this sounds dramatic but as someone that was rght on the edge of dropping JupyterLab entirely in favor VSCode's Jupyter because of its superior editor functionality, this ended up being a straw the broke the camels back and I've switched. Just my personal feedback if its helpful for devs to prioritze work. I could see myself swtiching back bc other stuff is better here, but I currently feel handcuffed in the JupyterLab editor (worse multicursor, less productivity plugins, ofc the now-missing Ctrl+D, etc...)

I think we all understand the importance of this issue, just it may not be as easy to fix even if it looks like a small thing on the UI side.

[krassowski]

Our developers

To clarify, there is a group of folks who maintain and/or contribute to JupyterLab project, some of whom are volunteers and in general there is no ownership of developers; Project Jupyter itself (as far as I know) does not employ any developers (though maybe I am wrong? this is probably a topic for a different discussion). That said, it is true that (part of) JupyterLab team expressed intent to prioiritize review of pull requests fixing regressions in 4.0 over other pull requests.

As previously stated, I am happy to guide any contributor in my free time.

just it may not be as easy to fix as it seems

II think it would be fair to say that it is quite time consuming to fix as it involves both codemirror and JupyterLab shortcut systems, and there is so much time one can sacrifice from the family time in the evenings 🤷‍♂️

[JasonWeill]

I agree with @krassowski that JupyterLab is a community-run project. We have a large community of contributors, and we welcome contributions from anyone who can help improve our software. The best way to have a positive impact on the community is to work on and contribute pull requests. Adding comments and votes on issues makes them more visible, but there is no core dev team that uses them to prioritize work.

[y-he2]

@y-he2 @marius311 Thank you for your continuing engagement with this issue! You can join us in our Matrix (Gitter, Element) chat room about JupyterLab here: https://matrix.to/#/#jupyterlab_jupyterlab:gitter.im

Our developers would be happy to review a pull request to help fix this issue.

Thanks for the links again, I was trying to pointing @dimi-tree to it (he offered help) but didnt pasted it.

More over, I was thinking maybe creating a thread in that Gitter chat room, or a Discord server specifically for this issue and #4778 so we wont spam the main chat, before the pull request. Because I feel like we would need to gather some work force for these two issues, and it would be easier to communicate by just join the specific server for it for discussions. Since it may be a bit too much for solos alone.
This was the essential point I pinged you guys, because I didnt knew if it would mess things up by creating separate unofficial communication channels. @krassowski @JasonWeill

it is quite time consuming to fix as it involves both codemirror and JupyterLab shortcut systems, and there is so much time one can sacrifice from the family time in the evenings

Yes I totally agree and that was part of the message I was trying to forward, apologies for any misunderstanding that may be caused by any miscommunication.