Open d-e-v-esh opened 3 years ago
@irmerk That is great. Will that take very long? Should I write the description of changes and limitations in more detail?
@irmerk That is great. Will that take very long? Should I write the description of changes and limitations in more detail?
Yeah I think so. This is a sensitive change, so as much helpful context would be great.
@dselman @irmerk I have updated the pull-request body and added more context highlighting the problem. Does this bring more clarity? Ask me any question that comes to your mind or regarding anything that was unclear.
When I test this using the Netlify preview there's something strange happening with the selection. Try selecting multiple paragraphs forwards, or backwards, and you see that the selection is getting extended outside of the selection target.
@dselman I don't see that behavior. Can you make a screen recording to show exactly what is strange?
@d-e-v-esh https://www.loom.com/share/56a2f8833f9f481e96dd5582fce0b745 I think @dselman may be talking about this thing.
@dselman I don't see that behavior. Can you make a screen recording to show exactly what is strange?
It seems to be specific to Safari - I don't see it on Chrome.
@K-Kumar-01 Is this happening only on this update or is this on the master branch? You cut out the URL.
@K-Kumar-01 Is this happening only on this update or is this on the master branch? You cut out the URL.
@d-e-v-esh It is happening in the deployment of this PR only. I have rechecked it. I clicked on the deploy preview and then made the above video.
@K-Kumar-01 That is actually a really bad bug. I'll see what is causing the problem and update.
@dselman Can you show which merge started converting blank lines to \
in markdown that you talked about here down in #269? I think that could be the one causing this problem. Because that was not happening in the initial commit and that did not happen when I run it locally until a did a git pull
and now nothing I do reverses this thing.
@irmerk Does this look good now?
Yes looks good. I think wait to rebase again (because there are conflicting files after I merged a couple other PRs) until we review.
I've finally been able to look more into this. This is really thorough and I think is on the right track. Some residual awkward behavior I'm seeing is when you press ENTER at the end of "My Heading" at the top of the demo, it inserts two new paragraphs, both of which are not headings, and places the cursor at the beginning of the second one. Could this be because we are inserting lineBreakNode
in insertLineBreak
?
As of right now #263 and #269 are solved for sure. I believe #267 is resolved, will want extra eyes on this from @dselman and/or @jeromesimeon.
@irmerk Oh yes, I remember that being very annoying. I don't know why I kept it, probably because it was there from the beginning. And we were talking about implementing this after the linebreak issue is resolved so that would be getting solved anyway. It is fixed for now.
Great! It looks like there are still merge conflicts, so you'll want to rebase to resolve those.
@irmerk I am not sure if this worked. Did the conflicts go away? I can't see them.
Suspicious, I refreshed and it said the conflicts were there, refreshed again and they were gone.
There are still two issues with headings:
Note: I'm looking at your code locally to see if I can see the solution.
@irmerk I think we can create a new and fully working headingBreak with all the bugs fixed under the PR of #260 after this is merged. I think that would be better, isn't it? I think fixing the headingBreak is whole another thing in itself.
OH yes! Good point. There's so many related Issues/PRs here I'm getting confused. Okay great, even better. This PR looks good so I'm going to merge!
@d-e-v-esh we're going to put the changes in this PR on the working group call tomorrow to try to make sure it doesn’t lead to further confusion around linebreaks/softbreaks. If you’ll be on during the call, feel free to add to the conversation. If not, I think @dselman and I can present what the changes will do.
@dselman I think the reason for that seems to be this that I talked about earlier. It seems like something changed in the conversion. That behavior is not present in the master and it was also not present when I made the PR. Do you know where it could be coming from?
@dselman I think the reason for that seems to be this that I talked about earlier. It seems like something changed in the conversion. That behavior is not present in the master and it was also not present when I made the PR. Do you know where it could be coming from?
Sorry, no idea. Can you reproduce the issue when you run locally using this branch?
@dselman Yes I can. It doesn't go back to when this was not happening.
Update: This PR should no longer address #267
Also, this should unblock #260 and #284
@irmerk I have implemented the new paragraphBreak
and also fixed the error that @dselman pointed out. I think it should be perfect now. Now we just need to update the demo text on the editor.
Pinging @dselman on this again.
@d-e-v-esh looks great. Can you please resolve the merge conflicts and then I will merge.
Would love to get this into the next release (this week). @d-e-v-esh will you have time to resolve the merge conflicts?
@d-e-v-esh Any Updates on this? If not, I would love to fix it up and send a PR
@adithyaakrishna Got extremely busy. I'll get to it in a few days. You can find other issues. This PR is complete, just needs the merge conflicts to be resolved.
@dselman I removed all the merge conflicts and it works totally great. You can check it out.
Closes #263 #267
Update
This was my thought process of finding the problem and the solution.
Identifying the problem
As you can see here, we do not have any function for the
softbreak
.The functions that exist there are
insertLinebreak
andinsertHeadingbreak
.So I thought that maybe
softbreak
was not working because there is no function for it. But that is actually not the case.The
softbreak
was not working because of this conditional statement here. This basically means that ifEnter
is being pressed from a non-heading block then we totally skip out hotkey actions. That is also the reason why pressingCtrl
+Enter
did not inset a page break. If you remove that statement thensoftbreak
and page break works like normal.And this should TOTALLY prevent us from getting a
linebreak
in a paragraph. And the only reason pressingEnter
is still functional is because of this and this functions where we are overridinginsertBreak()
. You can put a fewconsole.log()
there and check which functions work and which do not.That is also the reason why inserting a page break (
Ctrl
+Enter
) andsoftbreak
(Shift
+Enter
) works absolutely fine for all the heading blocks because this conditional statement only restricts non-heading blocks from all theEnter
functions.Exchange in types of
break
BuginsertLinebreak
andinsertHeadingbreak
.console.log()
statement after this line like this:By doing this, we get:
Here:
Pressing
Enter
results in a =>headingbreak
PressingShift
+Enter
results in a =>linebreak
This is the case because this is how it is mentioned in the
hotkeys
file as you can see here.Shift
+Enter
is creating asoftbreak
as it should but it is named as alinebreak
andEnter
is always creating a falseheadingbreak
no matter the type of block. It is falseheadingbreak
and does not do anything because of the problem I mentioned above that is pressingEnter
is useless in a non-heading block because of this conditional statement hereWhat is happening till now: Every time we press Enter, a heading break is going to get inserted.
How it was implemented was:
enter
keyword when being pressed from a non-heading block. This was causing #263headingblock
then we will go to our custom hotkeyActions and create a heading breakenter
is called from a non - heading block then we will skip our custom hotkeyActions and a default enter linebreak will occurChanges
headingbreak
to linebreakheadingbreak
Related Issues
Author Checklist
--signoff
option of git commit.master
fromfork:branchname