PR: Restore code cells and block comments in the Outline pane and fix other issues

[andfoy]

Description of Changes

This PR introduces pyls-spyder as a dependency in order to restore code cells and block comments on the outline explorer. It also fixes some minor UI details such as idle spinners on files that do not have outline support and adding an option to hide variable symbols.

Code cells and block comments

Hide/display variable symbols

• Wrote at least one-line docstrings (for any new functions)
• Added unit test(s) covering the changes (if testable)

• Included a screenshot or animation (if affecting the UI, see Licecap)

Issue(s) Resolved

Fixes #13896
Fixes #13877
Fixes #13872

Affirmation

By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: @andfoy

[andfoy]

pyls-spyder feedstock PR on conda-forge: conda-forge/staged-recipes#12758

[pep8speaks]

Hello @andfoy! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file external-deps/python-language-server/pyls/plugins/jedi_completion.py:

Line 60:80: E501 line too long (88 > 79 characters)

• In the file external-deps/python-language-server/pyls/plugins/mccabe_lint.py:

Line 15:80: E501 line too long (111 > 79 characters)

• In the file external-deps/python-language-server/pyls/plugins/pycodestyle_lint.py:

Line 24:80: E501 line too long (81 > 79 characters)

• In the file external-deps/python-language-server/pyls/plugins/pydocstyle_lint.py:

Line 29:80: E501 line too long (80 > 79 characters)

• In the file external-deps/python-language-server/pyls/workspace.py:

Line 261:80: E501 line too long (83 > 79 characters)

Comment last updated at 2020-10-31 21:39:17 UTC

[andfoy]

@jnsebgosselin, does this fixes the navigation issues?

[jnsebgosselin]

@jnsebgosselin, does this fixes the navigation issues?

I think you have not pushed the commits do do that yet?

[jnsebgosselin]

Also, the option to hide the variables from the explorer does not seem to work for variables that are attributes of an object.

[andfoy]

I think you have not pushed the commits do do that yet?

You're totally right!

[andfoy]

Also, the option to hide the variables from the explorer does not seem to work for variables that are attributes of an object.

Since we are separating variables from attributes, I don't know if we want to hide attributes as well

[andfoy]

@jnsebgosselin the commits are now in the branch

[jnsebgosselin]

Also, the option to hide the variables from the explorer does not seem to work for variables that are attributes of an object.

Since we are separating variables from attributes, I don't know if we want to hide attributes as well

If this is possible, I would vote to hide the attributes as well. I think that for writing scripts, showing the variables and attributes can be very useful. However, when writing object oriented code, this add a lot of clutter to the explorer that is not that much useful. But maybe that's just me.

Edit: However, I think that disabling the auto-expand items to follow cursor will make this less of an issue and will not be that much of a problem for me after all.

[ccordoba12]

Thanks a lot @andfoy for this! I left a (mostly cosmetic) review for you.

I still have to review how this one works locally.

[jnsebgosselin]

In the previous version, the outline explorer is reflecting the position of the cursor in the editor down to the innermost visible element in the tree, without expanding anything.

Currently however, the outline explorer is not updated at all when the position of the cursor changes and Always display the innermost element is unchecked. For example, in the screenshot below, I would expect the setup_filter to be highlighted in the outline explorer without being automatically expanded to highlight the root_path attribute.

[andfoy]

@jnsebgosselin, does the latest commit improves the navigation experience when not navigating to the innermost element?

[ccordoba12]

Thanks a lot @andfoy for creating pyls-spyder and your awesome work here to complete the migration of the Outline to use the LSP architecture.

[ccordoba12]

@spyder-ide/core-developers, @goanpeca, this PR added a new dependency to Spyder: pyls-spyder. You can install it with

conda install -c spyder-ide/label/dev pyls-spyder

@jnsebgosselin, please test the Outline next week with these changes to see if you can spot other regressions. Thanks for your help!

[jnsebgosselin]

@jnsebgosselin, please test the Outline next week with these changes to see if you can spot other regressions. Thanks for your help!

I will do, thanks for the work that was done on this.

[jnsebgosselin]

I cannot see code cells and block comments in the outline explorer even after this PR. Should I open an issue about it or you already know?

I haven't installed pyls-black yet though. Might this be related?

[ccordoba12]

Did you install pyls-spyder?

[jnsebgosselin]

I cloned the repo and added it to my PYTHONPATH and I'm running it from source.

[jnsebgosselin]

mmmh I think spyder doesn't see plugins anymore if I add them like that. It used to work though, since that is how I have always installed spyder-notebook and now it seems this plugin doesn't show in spyder if I do this like that.

[ccordoba12]

Sorry but that's a Setuptools plugin (not a Spyder one), so it needs to be properly installed. Or at least you need to run pip install -e . in your clone.

[jnsebgosselin]

Sorry but that's a Setuptools plugin (not a Spyder one), so it needs to be properly installed. Or at least you need to run pip install -e . on your clone.

Ok I understand. I will install it from conda and see if that works.

Is it the same reason why it is also happening with spyder-notebook too ? I can't simply run it from the git repo anymore?

[jnsebgosselin]

Ok I confirm that it is working if I install pyls-spyder with conda, thank you very much!

[jitseniesen]

Is it the same reason why it is also happening with spyder-notebook too ? I can't simply run it from the git repo anymore?

On my computer, spyder will find the spyder-notebook plugin if the plugin is in PYTHONPATH; you don't need to pip install it (though I prefer to do it that way). This is with Spyder 4.2.0.dev0 (Commit: e813165).

[CAM-Gerlach]

As a general note, pip install -e . is almost always preferable to manual PYTHONPATH hacking in the modern era (and directly obsoletes python setup.py install, python setup.py develop etc that I still see an unfortunate number of places), since it has the same desired effect as adding the repo to your path (changes to the repo will be reflected in the installed package), while also running the setup.py to install it properly, and allowing it to be accessed and managed with pip, conda, setuptools, pkg_resources, etc.

[jnsebgosselin]

The feature looks even better than before since you removed the ----. I think this looks great, good job.

[jnsebgosselin]

Is it the same reason why it is also happening with spyder-notebook too ? I can't simply run it from the git repo anymore?

On my computer, spyder will find the spyder-notebook plugin if the plugin is in PYTHONPATH; you don't need to pip install it (though I prefer to do it that way). This is with Spyder 4.2.0.dev0 (Commit: e813165).

Ok thank you very much for taking the time to answer.

As a general note, pip install -e . is almost always preferable to manual PYTHONPATH hacking in the modern era (and directly obsoletes python setup.py install, python setup.py develop etc that I still see an unfortunate number of places), since it has the same desired effect as adding the repo to your path (changes to the repo will be reflected in the installed package), while also running the setup.py to install it properly, and allowing it to be accessed and managed with pip, conda, setuptools, pkg_resources, etc.

I should start doing that, I agree, thanks for the tip.

But you know how it is... It all looks good on paper until it screw your python installation and you have to reinstall everything and I just don't have time for that at the moment so I'm not risking it lol.

[CAM-Gerlach]

Yeah...if it works as is then yeah. In the future though manual PYTHON hacking and particularly python setup.py develop have a higher chance of breaking your environment than pip install -e . since the latter registers everything it does in a standardized fashion and performs a bunch of sanity checks, and they are making a number of improvements in that latter regard with all the UX and dependency validation work they are doing.