Skip to content
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

Add tables extension #339

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

obask
Copy link
Collaborator

@obask obask commented Mar 31, 2024

*please ignore commits before Wire up GFM Tables extension

@obask obask self-assigned this Mar 31, 2024
@obask obask requested a review from rock3r March 31, 2024 07:07
@obask
Copy link
Collaborator Author

obask commented Mar 31, 2024

Also, maybe we could make most of the nodes data classes, but it will require merging some underlying CLs to make inline nodes value classes.

@rock3r
Copy link
Collaborator

rock3r commented Mar 31, 2024

@obask you'll need to sort out conflicts in this PR and in others for me to ship them. Please make sure you stack PRs that have dependencies.

@obask
Copy link
Collaborator Author

obask commented Mar 31, 2024

@obask you'll need to sort out conflicts in this PR and in others for me to ship them. Please make sure you stack PRs that have dependencies.

As I mentioned before, I don't have rights to push to existing branches making this impossible:
$ git push -u origin migrate-components

For example, this check is a requirement for feature branches https://github.com/JetBrains/jewel/blob/main/.github/workflows/codeql.yml#L7, but I don't think running it in a fork will give me an ability to push to origin aka JetBrains/jewel.
The only working solution for an existing setup would be to create a new stacked PR every time I "address comments".

@rock3r
Copy link
Collaborator

rock3r commented Mar 31, 2024

You have full write access to this repository, you shouldn't need to have a fork. I have weakened the branch protection rules even more than they already were. You should be able to push and force push to any branch directly with the exception of main.

@obask
Copy link
Collaborator Author

obask commented Apr 1, 2024

Let's sync on that over video when you have time. I'm getting the same error:

oleg@Olegs-MacBook-Air jewel % git commit -m 'Test branch protection rules'
[test-branch-protection-rules baced50] Test branch protection rules
 1 file changed, 1 insertion(+)
oleg@Olegs-MacBook-Air jewel % git push
Enumerating objects: 23, done.
Counting objects: 100% (23/23), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (12/12), 785 bytes | 785.00 KiB/s, done.
Total 12 (delta 5), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (5/5), completed with 5 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/test-branch-protection-rules.
remote: error: 2 of 2 required status checks are expected.
To github.com:JetBrains/jewel.git
 ! [remote rejected] test-branch-protection-rules -> test-branch-protection-rules (protected branch hook declined)
error: failed to push some refs to 'github.com:JetBrains/jewel.git'

@obask obask enabled auto-merge (squash) April 2, 2024 09:13
@@ -189,8 +190,9 @@ public class MarkdownProcessor(
is ThematicBreak -> MarkdownBlock.ThematicBreak
is HtmlBlock -> toMarkdownHtmlBlockOrNull()
is CustomBlock -> {
extensions.find { it.processorExtension?.canProcess(this) == true }
extensions.find { it.processorExtension.canProcess(this) }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why aren't we just dropping blocks that can't get processed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I'm following what you mean here: are asking why we are keeping noop extensions? I'm planning to fix that later... my ideal API would just run tryProcess and only register extensions if they do something.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I am asking why we have an Elvis that returns a DefaultCustomBlock, which is something that really makes no sense to me. If it's a custom block, the concept of default is meaningless. We should not have it; instead, every extension should have its own custom block(s) — e.g., TableBlock(...): CustomBlock

}

publicApiValidation {
// TODO Oleg remove this once migrated to value classes
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @obask there is a TODO here for ya :) (and in at least another module, too!)

) {
if (block !is CustomBlock.DefaultCustomBlock) return

val head = block.nativeBlock.firstChild as TableHead
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotta love CommonMark APIs 🙃

Can we expose head and body as properties on our table block model?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to invoke the processor unless it's needed for something. Right now the CustomBlock is an interface and we can always convert it to data classes later if we need to.

Comment on lines +7 to +8
public class TableStyling(
public val headColor: Color,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a background or content color? Please name accordingly

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial plan was to make it work as an alpha version. (I didn't think adding tables would be so easy) But yes, we should probably set the right styling in place.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would want to avoid having a half-implemented table extension merged in, unless we're sure the rest of the behaviour/styling is ready to go quickly (one day?)

Comment on lines +7 to +8
headColor: Color = Color.DarkGray,
borderColor: Color = Color.Gray,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these defaults taken from the GitHub CSS, or arbitrary? If arbitrary, please get the actual values from the GitHub CSS (I recommend creating a table in a gist and inspecting in both light and dark themes)

import org.jetbrains.jewel.foundation.GenerateDataFunctions

@GenerateDataFunctions
public class TableStyling(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any facility to set things like cell padding, min row height, etc. Are those coming later? Or simply weren't considered?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My goal was to add an initial implementation of tables and change it later to follow more specific requirements. So the answer is "weren't considered".

@rock3r
Copy link
Collaborator

rock3r commented Apr 2, 2024

Oh btw make sure all extensions are registered in the mergeSarif task — I suspect we may have forgotten that for previous PRs, too — not just this one. See

jewel/build.gradle.kts

Lines 8 to 21 in 5d33bd5

dependencies {
sarif(projects.decoratedWindow)
sarif(projects.foundation)
sarif(projects.ideLafBridge)
sarif(projects.intUi.intUiDecoratedWindow)
sarif(projects.intUi.intUiStandalone)
sarif(projects.markdown.core)
sarif(projects.markdown.extension.gfmAlerts)
sarif(projects.markdown.ideLafBridgeStyling)
sarif(projects.markdown.intUiStandaloneStyling)
sarif(projects.samples.idePlugin)
sarif(projects.samples.standalone)
sarif(projects.ui)
}

@rock3r rock3r added the markdown This issue impacts the Markdown rendering subsystem label Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
markdown This issue impacts the Markdown rendering subsystem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants