lampsitter / egui_commonmark Goto Github PK

Currently, public structs from this crate don't implement Debug trait, which causes issues if I want to store cache in some object that is Debug, as well as goes against a pretty strong suggestion in Rust docs

I recently moved the syntax highlighting code I had in egui_demo_lib to egui_extras: emilk/egui#3333

Importantly, it has a simple fallback that works even without the syntect crate (which has a tendency to bloat .wasm files quite a bit).

egui_extras::syntax_highlighing does not yet support everything that egui_commonmark offers, in particular it doesn't yet have add_syntax_from_folder, add_syntax_from_str, add_syntax_themes_from_folder, and add_syntax_theme_from_bytes.

column a   | column b
-----------|----------
item 1     | item 2
`item` `3` | item 4

This should be rendered as

With egui_commonmark, it's rendered as

Is looks like TextStyle::Monospace doesn't affect that part.

Having a "copy content" button appearing on hover over code blocks (typically top right) is quite common on modern web template (e.g. in our own docs at Rerun). It would be great to have something similar in egui_commonmark.

This is currently covered by having the code block text selectable, but this feels a bit clunky. (It's nice to have though, in cases the user wants to copy only part of the text.)

Related to:

• #10

#52 could have (hopefully) been avoided if there was a FAQ item about this.

Is there a way to make part of a text (or a full markdown text) selectable and copyable?

Safari has a marked tendency of rejecting copy operations that it can't link to user action. For this reason, most copy operations used to fail on Safari with egui/wasm. This was recently fixed in egui 0.24 (emilk/egui#3513), and now copying from code blocks works when selecting text and copy. However it still fails when using the copy button.

Here is a dev build of Rerun based on egui 0.24 where select-and-copy works on Safari, but not the copy button:

https://demo.rerun.io/pr/4111/examples/structure_from_motion/

One must scroll down the description view to reach a code block:

Clicking the "Copy" button fails with this error:

For reference, this is another dev build that is based on egui 0.23 and where all forms of copying fail:

https://demo.rerun.io/pr/4324/examples/structure_from_motion/

It would be useful to skip the parsing for markdown embedded directly into the application.

egui_commonmark supports rendering checkboxes, but they are not clickable.

Possible implementations:

• There could be a version of CommonMarkViewer::show that takes &mut String, and mutates the string directly when a checkbox is clicked.
• There could be some kind of a response from CommonMarkViewer::show that gives the byte position of the checkbox that was clicked, so the user could use it to update the string manually.

Requires collecting the events and process them when everything else has been parsed. Some ruler separation between content and footnote is probably desirable.

Currently, bulleted lists always wrap to the edge of widget. It would look much nicer if they didn't, and instead wrap "correctly":

FWIW, I just added some ad hoc implementation of that in Rerun: https://github.com/rerun-io/rerun/blob/142557e11c035172ba530187f5930895305b5003/crates/re_viewer/src/ui/welcome_screen/welcome_section.rs#L26-L41

Example markdown

- ```rs
  let x = 3;
  ```

Expected

https://spec.commonmark.org/dingus/?text=-%20%60%60%60rs%0A%20%20let%20x%20%3D%203%3B%0A%20%20%60%60%60%0A

Actual

Discovered from a picture in #43

Here's an unstyled table, it's fine:

And then adding a bit of bold and italics...:

Screenshots are from https://github.com/rerun-io/rerun which uses this crate to render markdowns with egui :). Rerun Sided tracking issue rerun-io/rerun#5588

Minimal reproducible example with eframe:

use eframe::egui;
use egui_commonmark::{CommonMarkCache, CommonMarkViewer};

fn main() {
    let native_options = eframe::NativeOptions::default();
    eframe::run_native(
        "Commonmark bug",
        native_options,
        Box::new(|_cc| Box::new(App::default())),
    )
    .expect("failed to run app");
}

#[derive(Default)]
struct App {
    cache: CommonMarkCache,
    content: String,
}

impl eframe::App for App {
    fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
        egui::CentralPanel::default().show(ctx, |ui| {
            egui::Grid::new("my_grid")
                .num_columns(2)
                .striped(true)
                .show(ui, |ui| {
                    ui.label("row 1, col 1");
                    ui.label("row 1, col 2");
                    ui.end_row();
                    ui.label("row 2, col 1");
                    CommonMarkViewer::new("my_commonmark")
                        .max_image_width(Some(512))
                        .show(ui, &mut self.cache, &self.content);
                });
        });
        self.content += "a";
        ctx.request_repaint();
    }
}

Is LaTeX support planned?

Advantages

• Better github flavoured support

Disadvantages

• More dependencies
• Slower than pulldown-cmark (don't know by how much)

Will probably keep both pulldown-cmark and comrak as a backend if it's not too much work.

Stuff:
* foo
* bar

That's it.

=>

Notice two problems:

• Extra vspace above the list
• Missing vspace below the list

I have noticed that when egui_commonmark renders the following md:

This is the list:
* The first item
	* First A nested item
	* First Another nested item
* The second item
	* Second nested item
		* A nested nested item
		* A nested nested another item
	* Second another nested
* The third item

A numbered list:

1. One
	1. One nested
	2. Two nested
		1. One one nested
		2. Two two nested
2. Two
3. Three

This is after the list.

we get this rendering with the line after the list attached to the list:

to make it behave like github would be nice to render it like this:

The change is small one more newline:

            pulldown_cmark::Tag::List(_) => {
                self.indentation -= 1;
                if self.indentation == -1 {
                    newline(ui);
                    newline(ui);
                }
            }

I understand this may be subjective though, what do you think?

Consider the following markdown content (which can by copy-pasted in the hello_world.rs example):

### Title

![Demo recording]()

### Some text

This is some text.

### Some other text

This is some other text.

The expected result would be to have the same spacing between all titles and their respective bodies.

The actual result is a missing space between the Some text title and the This is some text body:

This phenomenon disappears if the (empty) image is removed. Note that this is not related to the image failing to display. Here is the "real world" context where I identified this issue:

(Note the missing space after Logging your own data.)