Skip to content

Conversation

@hypest
Copy link
Contributor

@hypest hypest commented Mar 6, 2017

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:

  • Mark the whole content of a block with the span
  • Set the block spans with the SPAN_PARAGRAPH flag 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)
  • Each block element/span has a nestingLevel field, corresponding to its nesting level in html
  • Block spans are sorted by position and nesting and then exported recursively to html
  • Code that performs each block element's behaviour (list, listitem, heading, quote) runs "in parallel" to the other block elements to enforce a separation of concerns between the various types of block elements. AztecText's text mutation (like deleting the double-newline to close a quote) happens only after all block handlers have finished their processing.
  • Listitem behaviour handling is implemented in a separate handler than the List itself
  • Double-enter at block's end closes only the inner block when nested. This allows editing in the outer block to continue.
  • Complex conditionals are split into series of simpler conditionals that return early in order to make the algorithm more readable. Example.

Known issues:

  • Text is now never empty (there's a ZWJ if buffer empty) so, hint text is never shown. We can prolly tackle that in a separate PR.
  • Nested blockquotes inside lists don't show the bullet/number of the list item they're on

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!

* <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.
@theck13
Copy link
Contributor

theck13 commented Mar 6, 2017

Add #264 to the list of fixes. Thanks, @hypest!

hypest added 5 commits March 6, 2017 19:51
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.
@hypest
Copy link
Contributor Author

hypest commented Mar 7, 2017

Added a couple of commits (6960ea2, 07ff6be) that fix an issue where closing a nested list didn't properly close the parent list item.

Also added a fix for #125 (Nested lists show multiple bullets) with commits d5be1db and ab20128.

@hypest hypest force-pushed the experiment/paragraph-spans branch from 8ec075c to 07ff6be Compare March 7, 2017 17:06
hypest added 3 commits March 7, 2017 19:57
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.
@hypest
Copy link
Contributor Author

hypest commented Mar 7, 2017

Fixed (with 6981223) a rather "invisible" regression that happened with 56f9427.

@theck13 theck13 requested review from 0nko, khaykov and theck13 March 15, 2017 16:06
@0nko
Copy link
Contributor

0nko commented Mar 16, 2017

Awesome work, @hypest!
:shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Nested lists show multiple bullets

5 participants