-
Notifications
You must be signed in to change notification settings - Fork 333
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
Don't trim code selection before sending to kernel #1363
Conversation
@kylebarron It's great that you're taking a look at this! Regarding the patch here:
I'd be happy merging this, assuming there aren't known regressions for other languages. I see this as a high-priority issue because it's quite annoying and affects a very popular language. If problems come up with other languages we can make this behavior grammar-dependent. My attempts to solve this exclusively in a plugin have all run into insurmountable difficulties, so I'm very much in favor of addressing this in hydrogen itself. |
|
That's a good one @kylebarron! Looking quite good! Only thing I could find right now is that a mix of hard tabs and spaces causes Indentation Errors, but that's not supposed to be working in python anyway:
Another point: I would suggest moving the implementation to RE: 3. I'm in favour of expanding the selection to the front of the line, assuming that there is only whitespace at the beginning of the line. Only problem is that from the code now passed to |
If the mix of hard tabs and spaces confuses Python anyways, I don't think we should fix that on Hydrogen's end. Otherwise the file will work with hydrogen but not with
The implementation is in
Maybe I'm confused... The point is that no whitespace is being stripped with this change. If you select both lines and run this: print('hello world')
print('foobar') the text that Hydrogen spits out is exactly:
This should make it easier to find the indentation level, since you can simply get the indentation before the first non-whitespace character. |
You're absolutely right @kylebarron . Sorry, I looked at the wrong fork, as you pointed out in the other thread! Then my remarks are void. |
@mbroedl Sorry! I was just trying to juxtapose them! |
Re my point 3: Let's leave this for now to try to get this fix out faster. I want to clarify, however, that the original suggestion was not to infer the leading whitespace, but rather to read it directly from the text editor (and decide to include it or not based on whether there are any non-whitespace characters in same line as the start-of-selection) Re mixing tabs and spaces: If the whitespace in the original file is a mess, I think the correct action is for the programmer to fix it (Atom has some whitespace normalization commands, I think). I don't see a reason to do this in Hydrogen. Re my point 2: this is still the main one I'm worried about in terms of possible regressions. I know it won't be a problem for Python, but I have no idea how other kernels handle things. But that doesn't mean this PR has to be changed, unless an actual issue is discovered. It looks like you already tested a few of the most popular kernels with this change, and I don't have any others in mind that might be problematic. Perhaps it makes sense to sanity check on multi-syntax documents though, since those use a different code path. Does anyone want to see a particular kernel tested, or have other comments on this PR? Personally I'm in favor of merging now, letting it get tested on master for a little while, and then releasing. |
@nikitakit Thanks for the clarification. And agreed re mixing tabs and spaces. I checked a Python block inside a Markdown document and that worked for indented code. Regarding possible issues with kernels:
I think those three cases should form the entire effect of the change. Thoughts? |
@kylebarron @nikitakit The use of My view is that, as white-space has semantic meaning for some kernels, white-space transformations should live in language-specific plugins (like hydrogen-python). My 👍 to merging this PR as is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent several hours trying to figure out enough JavaScript to remove common leading whitespace
It's really cool that you looked into this and found a fix. I remember doing the same for my first PR here
Thanks for the PR @kylebarron! Would you like to help us maintain hydrogen? |
I'm interested, though at this point my js knowledge is still very weak, and I know nothing about React. In the next couple weeks I may try to create a PR for multiple cursors #1194, which is an enhancement I'd be happy to have. |
Description of the Change
Don't remove whitespace from start and end of string before sending to kernel. Would fix #862.
I spent several hours trying to figure out enough JavaScript to remove common leading whitespace (that's on this branch, and I'd submit that as a PR if preferred) when I realized that the IPython kernel can deal with common whitespace just fine:
The issue is that Hydrogen trims strings by default before sending them to kernels.
hydrogen/lib/code-manager.js
Lines 15 to 20 in ad6217f
So what IPython actually receives is:
![image](https://user-images.githubusercontent.com/15164633/43374758-5399546c-937f-11e8-8c94-3860a83eb404.png)
Alternate Designs
I wrote code that actually removes common leading whitespace. That's on this branch.
The hydrogen-python extension package tries to deal with this but has some limitations that prevent its use.
Benefits
Selection-based Python code would work regardless of the amount of common indentation.
Possible Drawbacks
Other kernels might be expecting strings without any leading or trailing whitespace. I would imagine that kernels would account for extra whitespace if necessary and that it wouldn't be an issue.
Otherwise, to preserve true backwards compatibility we could have only the Python kernel not trim whitespace. Or have a user-defined config setting. Maintainers probably have the best idea for what is best.
Applicable Issues
Would fix #862, half of #1341, #1285.
Examples
(This is the same behavior as the IPython kernel)
![image](https://user-images.githubusercontent.com/15164633/43375297-2b1bb16c-9382-11e8-8c76-0a5dcb2cca14.png)