Lists within tables

Linux Mint 2.8.7

I'm not sure what is part of Markdown and what is part of Joplin. I'm asking here to further my understanding of some boundaries.

For most use, I use WYSIWYG editor as I use Joplin for reference notes. However, one thing seems to be a subject which comes up time and time again... that of lists within table cells.

The main explanation is that Markdown doesn't support lists within table cells as the cell has to all be on one line. However, I've read that people have got around this on other systems by using HTML <ul><li></li></ul> ... and while this works in Joplin it is among some html that is stripped out... apparently when switching from WYSIWYG to text, or switching to another page and then back again.

I have read that the explanation of this is that the WYSIWYG editor only supports what Markdown supports... but that seems odd to me, because markdown doesn't seem to care about HTML, and if other people are using HTML to get around this, then why isn't Joplin?

Incidentally, I have noticed that after creating a list as a bullet, going to the text editor the - are prefixed with a \ ... but not for the first one in the line. Also, if I put the HTML list in the text editor, it survives the transit to WYSIWYG and I can actually edit the list, add more elements, etc. but on flipping back to the text editor... it's gone again.

It does strike me that Joplin could leave the HTML intact for the list, but I'm wondering if I'm missing something in my understanding.

It is because Joplin has to run through a conversion. If your note is of markup type markdown and you open it in the richtext editor then everything you type is in HTML. Joplin then has to take that HTML document and convert it into markdown in order to save it in the database - as Markdown is the "standard" way of saving note data.

GFM only supports inlines within tables: see - GitHub Flavored Markdown Spec

Each row consists of cells containing arbitrary text, in which inlines are parsed, separated by pipes (|). A leading and trailing pipe is also recommended for clarity of reading, and if there’s otherwise parsing ambiguity. Spaces between pipes and cell content are trimmed. Block-level elements cannot be inserted in a table.

Lists are blocks and therefore not valid markdown to add them to table cells.
Whilst it is valid markdown to insert HTML into markdown docs, the same cannot be said of inserting it into the richtext editor as what is displayed is not markdown - the conversion is on saving the data to the database so it can lead to inconsistent behaviour depending on what is doing what on the back and forth conversions and rendering.

This is reflected in the limitations shown on the website:

If a note is of 'Markup - Markdown' and contains HTML formatting, this may be lost when editing in the Rich Text editor as it cannot be converted to Markdown. Notes of 'Markup - HTML' are not affected by edits in the Rich Text editor as this conversion does not take place.

As for that last bit, an HTML note is something you import as HTML or create as HTML from the webclipper.
However to try and avoid some of these problems I have a (somewhat neglected) plugin to allow manually creating new HTML notes and converting existing notes which flags to Joplin that conversions to markdown should not take place - this does mean that the markdown editor will just show the pure HTML and not markdown so is much tricker to edit but if you want to have a look you can download from the github repo releases and manually install it (it cannot be found within Joplin yet).

Thanks for the detailed information. I really appreciate it.

I don't currently have any plugins installed and I'd rather keep it simple if I can. I did, however, look to set the note to type HTML and at the moment, I can't find it. The note properties shows the markup as Markdown, but no option to change it.

I understand that the save process is what is taking place when I switch between notes, but some HTML appears to be stored. The obvious question to a newcommer like me is, why not list HTML. The editors certainly seem to be able to handle it very smoothly.

You can't, that is why I made the plugin unless you want to edit the database directly.

Some will have a jop-no-conv (?) class added to the element, the issue is balancing where it should go, if we should support it and if it would just cause more problems and other weird edge cases.

Ahhh!!! Makes sense. I'll grab the plugin now.

I do plan to publish this eventually, it had an annoying visual glitch which I thought was something I did wrong and couldn't work out how to solve but instead I think it related to a different bug which has recently been resolved so I really need to revisit this and publish it.

Its a stupidly simple plugin, it won't do anything weird to Joplin or make any new buttons, all it does is give you access to two new commands toggleMarkupLanguage and newHtmlNote.

The former just finds the markdown type of the current note and inverts it:

	if (curNote.markup_language == 1) {
		customMarkup = 2;
	} else if (curNote.markup_language == 2) {
			customMarkup = 1;
		};

The latter makes a new note of type html then focuses it.

const newNote = await joplin.data.post(['notes'], null, { title: "", parent_id: folderId, markup_language: 2 });	

await joplin.commands.execute('openNote', newNote.id);

It seems to work but interested to hear any feedback. The next step would be potentially to add menu items or something.

That's impressive.

Unfortunately, as you pointed out, it won't survive being edited in the wysiwyg editor, but it's a major help.

Thank you very much.

1 Like

Ah. Unfortunately it didn't seem to survive a save and reload. Hmmm...

It may not fit your use case fully, personally I don't ever use the richtext editor so this was really just designed to make sure Joplin didn't touch any markdown formatted notes with html inside if the user accidentally swapped to the richtext editor and made a change.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.