Markdown Tables about notekit

[blackhole89]

Uh, it wouldn't be impossible to add, but I'm thinking it would be kind of hard to make decent UX for it. There is currently code in place that renders fairly arbitrary pieces of markdown as widgets when the cursor isn't near them (this is what both checkboxes and LaTeX rendering use). This makes sense for fairly simple widgets (checkboxes can only be clicked on or off, LaTeX is not interactive at all), but what should it be like for something complex like markdown tables (which support most markdown inside their cells)? Would you expect that you can click and edit a single table cell naturally, without the table being unrendered/reduced down to plaintext? If so, should there be any keyboard/cursor action you can perform while editing inside a table cell that allows you to leave that table cell for an adjacent one?

Most likely, just to render the contents correctly, we'd need something like separate instances of the top-level markdown editor for each table cell either way. This would both be very heavy and would require some finicky changes to how markdown is currently serialised/deserialised, as we'd have to ask each markdown subwidget to serialise and provide its parent with its markdown source, and make sure they always stay in sync.

[sp1ritCS]

Would you expect that you can click and edit a single table cell naturally, without the table being unrendered/reduced down to plaintext?

This would probably be the best UX.

For KB/M I guess the best way to navigate between cells would be MOD (maybe Shift?) +Arrowkeys and ESC to leave the table (move the cursor one line below the table)

I don't know how hard it is to implement this, as I find the code very confusing (i've tried to fix, that the app dosn't crash when entering parsed, but invalid LaTeX) and I'm unsure what is now part of notekit and what is part of gtksourceview

[blackhole89]

I don't know how hard it is to implement this, as I find the code very confusing (i've tried to fix, that the app dosn't crash when entering parsed, but invalid LaTeX) and I'm unsure what is now part of notekit and what is part of gtksourceview

What LaTeX input causes this? This for sure is worth a bug report.

[sp1ritCS]

What LaTeX input causes this? This for sure is worth a bug report.
Im currently unable to find a real-world example (but happens primary because of typos)

But even something simple like
$\frac{3} causes:

** (notekit:220362): ERROR **: 19:33:44.810: 
unhandled exception (type std::exception) in signal handler:
what: Problem with command frac at position 0:9
 caused by: Both numerator and denominator of a fraction can't be empty!

zsh: trace trap (core dumped)  notekit

while $\frac{3$ works. (Again, this error occurred only on typos and it is annoying to restart and retype everything since the last autosave.

I think to fix this you need to
imagewidgets.cpp#128 verify that r is valid.

[blackhole89]

Actually, it looks like cLaTeXMath throws an exception out of LaTeX::parse. 09ae305 should fix this.

what is now part of notekit and what is part of gtksourceview

Well, everything in the source is part of notekit :) In particular, notebook.cpp contains our specialisation of the sourceview control. Like sourceview (and even plain gtktextview), the control allows anchoring arbitrary Gtk widgets inside the text (by putting a special placeholder character and inserting the widget's requested drawing area as the "glyph" when rendering). This has clear applications for rendering special markdown features like checkboxes.

A lot of these features, from a UX perspective, simply take the form of "textual representation should be displayed when the cursor is near, inert image should be rendered otherwise". The widget we anchor inside the text view to display the inert image is CImageWidget and whatever inherits from it, and all of them are supposed to go into imagewidgets.cpp. So far, LaTeX is the only implemented one, but when I add markdown images (and possibly even just nicer bullet points for enumerations), they will clearly work in the same way.

Back on task,

table UX

I agree with you, but this is a lot of work - and I'm still worried about the performance of possibly having n×m little copies of the notebook control floating around in every table. (They'd also need to be adapted a little: no margins, potential changes to how drawings behave in them...)

I guess this is one thing in which we have an inherent disadvantage relative to other markdown editors that include a full-fledged browser (i.e. electron), which contain a sufficiently powerful layout engine that tables can just be supported naturally as part of the same process that lays out text and provides editing. (It's not really an option for this: electron is laggy and doesn't really interact with xinput well enough to do tablet input, webkit's bindings have degraded to the point of unusability in the name of "security", and Gecko's bindings are abandonware)