Jupyter output messy after recent update 1.65.0

[jslomkowski]

Issue Type: Bug

In a recent update, the 1.65.0 output of Jupyter cells is messy. Please bring back ordered formatting like in previous version 1.64.2 Previous:

Latest:

Downgrading Vscode to previous version 1.64.2 helps. Downgrading Jupyter and/or Python Extensions does not help.

VS Code version: Code 1.65.0 (b5205cc8eb4fbaa726835538cd82372cc0222d43, 2022-03-02T11:12:08.962Z) OS version: Windows_NT x64 10.0.19044 Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz (8 x 2304)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.73GB (16.91GB free)| |Process Argv|--crash-reporter-id 6e933a20-4fd1-44bb-b0d2-e333fd227733| |Screen Reader|no| |VM|0%|

Extensions (25)

Extension|Author (truncated)|Version ---|---|--- better-comments|aar|2.1.0 codegenx|Dee|0.1.4 gitlens|eam|12.0.1 copilot|Git|1.7.5209 vsc-space-block-jumper|jmf|1.2.2 identical-sublime-monokai-csharp-theme-colorizer|max|1.1.0 rainbow-csv|mec|2.0.0 document|min|1.10.2 data-workspace-vscode|ms-|0.1.1 mssql|ms-|1.13.0 python|ms-|2022.2.1924087327 vscode-pylance|ms-|2022.3.0 jupyter|ms-|2022.2.1020642448 jupyter-keymap|ms-|1.0.0 jupyter-renderers|ms-|1.0.6 vscode-ai|ms-|0.6.28 vscode-ai-remote|ms-|0.7.0 azure-account|ms-|0.10.0 resourcemonitor|mut|1.0.7 vscode-sort-json|ric|1.20.0 sourcery|sou|0.10.3 git-prefix|srm|1.3.0 errorlens|use|3.4.1 vscode-icons|vsc|11.10.0 markdown-all-in-one|yzh|3.4.0

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythonvspyl392:30443607 pythontb:30283811 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 vscoreces:30445986 pythondataviewer:30285071 vscod805cf:30301675 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 vsaa593cf:30376535 vsc1dst:30438360 pythonvs932:30410667 wslgetstarted:30433507 vsclayoutctrc:30437038 vsrem710cf:30416617 dsvsc009:30440023 pythonvsnew555cf:30442237 vsbas813:30436447 vscscmwlcmc:30438804 vscgsvid1:30447480 helix:30440343 vscaat:30438848 vsnot107cf:30443615 ```

[jhoneill]

Nearly opened a duplicate of this .
The output has changed from a NON-Proportional font to a Proportional one.
I can't see a setting to manage the typeface.

[Gophen]

You can add this to your notebook to force the output to display like you want it :

from IPython.core.display import HTML
HTML(r"""
<style>
    .output-plaintext, .output-stream, .output {
        font-family: Fira Code; # Any monospaced font should work
        line-height: 1.3 !important;
        font-size: 14px !important;
    }
</style>
""")

[jhoneill]

<style>
    .output-plaintext, .output-stream, .output {
        font-family: Fira Code; # Any monospaced font should work
        line-height: 1.3 !important;
        font-size: 14px !important;
    }
</style>

Whilst this is a fix for new notebooks - although the line-height doesn't work everything is still double spaced ....

existing notebooks WIll render incorrectly. Here's one I reopened from a few weeks ago

again, double spaced.

[rebornix]

Thanks for the bug reports everyone. This is already fixed in Insiders and will be fixed with next recovery build later this week.

[jhoneill]

@rebornix Excellent news, thanks for the update

[JohnnyFoulds]

I won't post about this again because it will sound like I am just complaining, but I have to say it and make clear what I mean.

I am dismayed that in the effort to add fancy new things to notebook functionality (most of which I might never use), the VS Code team has merged code that breaks something you look at every single time you use notebooks. Even with the latest update with 1.65.1, the font issue remains. The bottom line is my example notebook output should look the same as it does in GitHub, and as it did in 1.64.2:

https://github.com/JohnnyFoulds/dsm010-2021-oct/blob/master/coursework_02/cw02.ipynb

Specific examples are the output of PySpark dataframes and Pandas dataframes. And combinations of different fonts when showing the spark session.

[jhoneill]

@JohnnyFoulds

This happens.

• Devs check in code which (to their eyes) makes X look better.
• All automated tests pass.
• Code is released.
• People see that the change affects Y and Z and either outright breaks them or makes it (to their eyes) worse.

So you should both care and complain when this happens, usually the howls of protest from those who care a lot are loud, and people learn, new tests get added to catch it next time.

BUT be wary of saying " the VS Code team has merged code that breaks something you look at every single time "
I'm ex-Microsoft, and things do go out which aren't as they should be, and someone will always say "Microsoft has done something catastrophically stupid - again! Don't they check anything before it goes out?", and insiders think "What - all 100,000+ of us, did it together? " And the truth is that none of the many things which are there to stop something embarrassing going out worked for an error made by one person on one team. And although it matters a lot to some customers and in their eyes the whole organization looks worse, most customers don't notice.

The fix for this is in 1.65.2 which is due out this week and things are absolutely critical and can't wait one can downgrade to 1.64. The development and release process which caused this screw-up also helps get the fix out in a few days.

[JohnnyFoulds]

You are right, of course, but let's not even get started on the constant Microsoft Windows updates (that is such a horrible comparison), I could have taken a couple of years holiday that would have equalled the productivity loss I had with those, to a point where I wish I could never receive an update again in the future (on my corporate machine there is no choice in the matter). But that is beside the point for this discussion - more a joke, not a joke thing. Also, refer to Season 2 of Space Force for a laugh about Windows Updates (yes, I sometimes waste my time by watching stupid TV programs) 😃

I also work in a large multinational, and when something fails, everyone logically understands that not every employee is personally responsible. Not even the team working on something where the failure occurred is personally to blame, not even the individual making a mistake, but rather the gatekeepers that had the final say in what got rolled out and what didn't.

At this point, I am not even upset or annoyed in the slightest about this anymore, so thank you for responding. I have downgraded already two days ago and set to updates to the manual. Somehow it magically updated again to test my patience, and that is when I saw the error is present even in 1.65.1.

What got me annoyed initially is that this is such an obvious blunder and the way the output is rendered now is unacceptable for my use when it was perfect before, as far as I am concerned. In my mind, I didn't understand how the notebooks were tested, when the most obvious thing was broken, which I noticed the instant I opened a notebook after a VS Code restart.

I can easily see how something like this happens when there is a reliance on automated tests, making it very hard to test visual elements. I just needed this to teach me again to never-ever allow software to auto-update. I honestly feel foolish not to have realised this earlier but so far, the updates have been great and Visual Studio Code is probably the best development environment I have ever used. However, it still has "Microsoft" attached to it, so that should have been a warning to me and I should have been wearier of the updates. Thus, in the end, it was my fault anyway, and I can't blame anyone but myself.