Repository navigation
fix: parse block quote markers of table lines as BLOCK_QUOTE tokens (IJPL-95908) - #232
Open
jetbrains-air[bot] wants to merge 1 commit into
Open
jetbrains-air[bot] wants to merge 1 commit into
jetbrains-air[bot] wants to merge 1 commit into
Conversation
…IJPL-95908) For a table inside a block quote, the '>' markers of every line after the header ended up in the gaps between block-level productions, and TreeBuilder fills such gaps with WHITE_SPACE tokens. In the IDE these markers therefore landed inside PsiWhiteSpace nodes; whitespace regeneration after a PSI mutation (e.g. the remove row / remove column table actions) can only emit real whitespace, so the '>' markers were lost and the block quote markup broke together with the table. Now GitHubTableMarkerBlock emits a BLOCK_QUOTE token production for each quote marker eaten by the line constraints of a table continuation line, matching how the markers are represented outside of tables. HTML generation is unaffected: TablesGeneratingProvider only consumes HEADER / ROW / TABLE_SEPARATOR children. Produced by Air Automations. Name: Markdown library: fix the bug / Run: https://air.jetbrains.cloud/org/05cf1a7f-6ab5-713b-abd3-29d0c8a05e2d/automations/cb6a17f6-e7a9-41a8-9611-7c95c4eb0141?run=e31aa195-850b-47a7-8b0b-bc40ea2ca4a5 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
Seems to be duplicated of #231 :( Peter Gromov (@donnerpeter) WDYT? |
Contributor
Author
There was a problem hiding this comment.
Approving verdict from my side — no blocking findings! (Posted as a comment because GitHub does not allow this account to formally approve its own PR.)
Produced by Air Automations. Name: Markdown library: review the PR / Run: https://air.jetbrains.cloud/org/05cf1a7f-6ab5-713b-abd3-29d0c8a05e2d/automations/2269eaa4-da15-4cac-957f-3341151c79ec?run=c915e52e-62ca-4c77-9351-57b81d857d7c
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
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.
Fixes IJPL-95908: removing a row / column in a table inside a block quote breaks the table.
Root cause
For a table inside a block quote, only the first
>marker got aBLOCK_QUOTEtoken production (viapopulateConstraintsTokens). The>markers of the separator line and of every data row fell into the gaps between block-level productions, andTreeBuilder/TopLevelBuilder.addRawTokensfills such gaps withWHITE_SPACEtokens.In the IDE those markers therefore ended up inside
PsiWhiteSpacenodes (MarkdownParserDefinition.getWhitespaceTokens()includes the libraryWHITE_SPACE). The table actions themselves don't touch the prefixes — but the whitespace regeneration that the platform performs after a PSI mutation can only emit real whitespace, so the>markers were silently dropped, breaking the block quote markup and the table with it. A plain table survives the same mutation, which is why the bug shows only inside a block quote.Fix
GitHubTableMarkerBlocknow emits aBLOCK_QUOTEtoken production for each quote marker (plus one following space, when eaten by the constraints) on every table continuation line, matching how the markers are represented outside of tables:previously:
Pure indentation (tables in list items) intentionally stays
WHITE_SPACE.Testing
testTableInsideBlockQuoteparsing test covering the exact reproducer from the issue (>|without a space) and a nested>>|block quote.testTableInsideBlockQuoteWithMissingLastPipeandtestTableInsideBlockQuoteInListItem— only the token type of the>prefixes changed.jvmTestsuite passes (1566 tests), including the GFM spec suite: HTML generation is unaffected becauseTablesGeneratingProvideronly consumesHEADER/ROW/TABLE_SEPARATORchildren.Produced by Air Automations. Name: Markdown library: fix the bug / Run: https://air.jetbrains.cloud/org/05cf1a7f-6ab5-713b-abd3-29d0c8a05e2d/automations/cb6a17f6-e7a9-41a8-9611-7c95c4eb0141?run=e31aa195-850b-47a7-8b0b-bc40ea2ca4a5
🤖 Generated with Claude Code