Shift-enter should not move cursor to end of line

[arencambre]

Type: Bug

Behaviour

Expected vs. Actual

Expected behavior is after I press shift-enter to run a line of code (thank you for improving this in #13495!), either of these happen:

• Cursor goes to beginning of line
• Cursor stays at same horizontal position. (I am offering this as an idea, but not sure what I think of it. The prior may be better.)

What actually happens is the cursor is jumped to the very end of the line. I am often having to scroll left to recall what the line is about.

Steps to reproduce:

1. Press shift-enter on a line of code when the next line also has a line of code.

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.11.5
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Conda
• Value of the python.languageServer setting: Default

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

User Settings

languageServer: "Pylance"

Extension version: 2024.2.1
VS Code version: Code 1.87.2 (863d2581ecda6849923a2118d93a088b0745d9d6, 2024-03-08T15:20:17.278Z)
OS version: Windows_NT x64 10.0.22631
Modes:

System Info

Item	Value
CPUs	13th Gen Intel(R) Core(TM) i9-13900H (20 x 2995)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	undefined
Memory (System)	31.68GB (11.89GB free)
Process Argv	G:\My Drive\research\Campsite checker\check_sites.py --crash-reporter-id dc4451c2-191b-43ac-a004-eab6bc408e8b
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
2e7ec940:30986170
pythontbext0:30879054
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfcontrol:30979541
d34g3935:30971562
fegfb526:30981948
bg6jg535:30979843
dsvsc020:30976470

[anthonykim1]

Hello, @arencambre. Thanks for the call out! This behavior of the Python extension smartly selecting the minimum amount of executable code, and advancing the cursor to the next executable statement is from the Smart Send feature. This allows Python developers to quickly shift+enter and execute their code inside their Python file.

If you wish to turn off this behavior and get your desired cursor staying at the same position, you may go to settings and type smart send. You should be able to turn off this setting for your user/workspace setting depending on your preference.

Alternative solution to have the best of the both world would be you explicitly selecting/highlighting the chunk of code that you wish to run, this would cause Python extension to execute what you have selected, and will not do anything to move around your cursor. When you do not highlight any chunk of code and shift+enter, you will still be able to use the smart send behavior!

Let me know if you need some other help

[arencambre]

This behavior of the Python extension smartly selecting the minimum amount of executable code, and advancing the cursor to the next executable statement is from the Smart Send feature. This allows Python developers to quickly shift+enter and execute their code inside their Python file.

This is fine, and I love it!

The current behavior is the cursor advances to right after the next executable statement, at the end of that statement's line. For lines that are wider than the viewport, I am scrolled right until the entire statement shows, which obscures the beginning of the statement. It is the beginning of the statement that is most impactful to me, so that is what I prefer to see, not the end.

Also, if I shift-enter, the cursor is placed at the end of a very long line, then I shift-enter again, and the next line is short enough to fit in the viewport, the horizontal viewport isn't scrolled all the way to the left, so even a portion of that short line is obscured.

I think a sensible default is the cursor is advances to the beginning of the line that has the next executable statement. This shows me what is usually the most important part of a line of code, plus I avoid the horizonal position jumping around as I shift-enter through lines of code.

[anthonykim1]

This is fine, and I love it!

Glad you are enjoying the feature!! Thank you :)

I think a sensible default is the cursor is advances to the beginning of the line that has the next executable statement. This shows me what is usually the most important part of a line of code, plus I avoid the horizontal position jumping around as I shift-enter through lines of code.

This can be subjective in a way, but ever since smart send was released on August, users seem to be pretty happy with it.
It may have to do with folks using popular formatter like Ruff and Black-formatter and limit their code length to not be long to encounter the same pain points of the viewport scrolling related issue that you mentioned.

Considering folks will shift+enter as they incrementally write their code throughout the Python file, and have a formatter with around 100 character length, placing the cursor to the end made sense as it seemed more intuitive and gave the sense that they are ready to execute on that line without further changes.

I will still bring this up to the team though.

[arencambre]

Thank you. Here's a practical example of what I am facing. Note how the code gets obscured when I shift-enter from a long line to a short line:

[github-actions]

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.