-
Notifications
You must be signed in to change notification settings - Fork 121
Paragraph spans #278
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
Merged
Merged
Paragraph spans #278
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* <li> is a block element so, treat it like one: span's range covers the whole of its content, not just a mark on a newline as before * add visual newlines to block elements as an extra parsing step, after all block spans have been added to the Spannable. This way, it's simppler to find the spots that visual newlines are needed * Recursive html production by translating each block span to its own block * AztecParserTest tests pass but other tests (mainly the editor ones) are broken UnknownHtmlSpan is an exception to the above: it's handling has been left as it was. Will probably refactor it later.
The outer one is the list and the inner one is the first list item. BlockElementsTest are also green now.
Now all HeadingTest tests pass.
For instance, expand both the list and the list item block.
That was a Kotlin gotcha for me! The "-1" seemed to be counted twice for some reason.
Editing works.
So to be able to render a block element in the "empty" text.
That is, no <br> that can be assumed by looking at the visual editor. The list itself is a block element.
Contributor
And don't show the bullet/number when the depth is greater than the current list item.
For example, a nested list starts a line after the list item that encloses it.
Contributor
Author
8ec075c to
07ff6be
Compare
since the handlers it manages only actually care about the addition of newlines (or the END_OF_BUFFER_MARKER)
This regression was caused with the split of the list item block handler from the list handler.
Contributor
Author
theck13
approved these changes
Mar 16, 2017
0nko
approved these changes
Mar 16, 2017
khaykov
approved these changes
Mar 16, 2017
Contributor
|
Awesome work, @hypest! |
This was referenced Mar 17, 2017
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #125, #126, #170, #188, #194, #247 (but with a new issue), #251, #264
🎉
This PR introduces a different method of marking and handling block elements. Here's a list of the changes it introduces:
SPAN_PARAGRAPHflag and never change it. See the Spanned.java source for details. Paragraph spans must start after a newline (or the start of buffer) and end right after a newline (or the end of the buffer). The auto-changing nature of the SPAN_PARAGRAPH span becomes tricky when text is replaced instead of just added/removed and a few classes are dedicated to handling that (ParagraphBleedAdjuster, ParagraphCollapseAdjuster, ParagraphCollapseRemover)nestingLevelfield, corresponding to its nesting level in htmlKnown issues:
This is a fairly big and broad PR, sorry for that :(. The changes are too close to the core to keep it small though. I'm open to ideas on how to break it down to smaller PRs if needed :). Thanks!