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

Could the markdown conversion convert unsupported attributes to plain text insead of throwing an error? #405

Open
maelchiotti opened this issue Aug 14, 2024 · 8 comments · May be fixed by #418
Labels
enhancement New feature or request

Comments

@maelchiotti
Copy link
Contributor

Is your feature request related to a problem? Please describe.

When using text formatting in the editor that isn't supported in markdown (such as underlining), it breaks the conversion to markdown since the attribute cannot be handled.

Describe the solution you'd like

If you want to keep this behavior, maybe an option could be added to just treat those attributes as plain text? It would allow me to export text even if it has some unsupported markdown in it. This option would be opt-in, and I would handle warning my users.

Describe alternatives you've considered

I don't really know, I could just skip all the notes in my app that cannot be fully converted to markdown, but skipping a huge note just for one underlined word is a shame 😕

@amantoux
Copy link
Member

@maelchiotti Do you want to propose a PR for this?
I can take a look otherwise

@maelchiotti
Copy link
Contributor Author

I can make a PR if you think my proposal is good? Something like adding a encodeUnsupportedAttributesAsPlainText parameter to the encode() function.

@amantoux
Copy link
Member

Yes I find it a bit harsh to fail when something is not supported
Regarding the opt-in parameter maybe something simpler like strict that defaults to false?

@amantoux
Copy link
Member

amantoux commented Aug 14, 2024

Also, we need to decide on a way to handle embeds, maybe simply convert them to object, WDYT?

@maelchiotti
Copy link
Contributor Author

What do you mean about "converting them to object"?

@amantoux
Copy link
Member

amantoux commented Aug 14, 2024

I mean when the codec finds an embed, it replaces the embed by the string 'object' or '[object]'

This PR could be interesting to support embeds later on #371

@maelchiotti
Copy link
Contributor Author

Oh yeah I see. [object] makes sense I think. Also, horizontal rules could be supported.

@maelchiotti
Copy link
Contributor Author

Hi @amantoux, I did some work in #418.

I added support for horizontal lines.

I added the strict parameter. I just don't really know how to detect when to set the close parameter to true in _writeAttribute() in order to put a </u> after the text and not a <u> again?

However I didn't handle objects because I can't test that easily. But I guess in convert(), instead of returning when I see a block embed, that's when I should write [object] to the buffer?

void handleLine(LineNode node) {
  if (node.hasBlockEmbed) {
    if (node.embedNode.value == BlockEmbed.horizontalRule) {
      _writeHorizontalLineTag(buffer);
    } else {
      buffer.write('[object]');
    }
  }

  ...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants