I want to create a WYSIWYG editor for markdown, and I want it to be keyboard-driven with vim editing philosophy.

I want the editor to have rich formatting, rather than the equally spaced cells of characters in the terminal. This would enable rows having different text sizes, usage of non-monospaced fonts, editing RTL languages such as arabic or hebrew, and bypass other terminal limitations.

Embedding neovim would be nice in theory, enabling all compatible vim features. But it seems to come with great difficulties, since I am forgoing the entire rendering philosophy that neovim depends on (equally spaced cells of the terminal).

SO I am thinking it would be better to emulate the vim features I want, starting with basic keybindings and motions, and go from there. But I am worried that I might end up regret this choice? It seems that embedding neovim is too monumental of a task for what I want to do. Am I mistaken?

  • sloppy_diffuser@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    5
    ·
    4 days ago

    You probably don’t want the entire terminal rendered in your UI for the reason you gave that it is intended for monospace.

    Rather, you want the buffer which is markdown and contextual info like cursor position.

    You might hit some challenges like how to handle style elements. For example:

    <cursor>*bold*
    

    Moving the cursor to the right of the b will take two key presses in nvim but would typically be one key press in a WYSIWYG editor.

    There are probably many ways to handle this in nvim through the plugin system, but both paths of embedding vs emulating nvim has a good chunk of dev work to be completed.

    Emulating will likely be more rewarding at the start as you can get incremental improvements pretty quickly.

    Embedding is a cool idea, but likely a ton of upfront work to get your first tangible results.

    You might be interested in reviewing https://github.com/MeanderingProgrammer/render-markdown.nvim which attempts to render Markdown in the terminal. They have logic for rendering things like the bold example in bold while hiding the markup.

    I personally just use https://github.com/iamcco/markdown-preview.nvim to render in a different window when render-markdown.nvim isn’t enough.

    • matcha_addictOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 days ago

      Thanks for the pointers!

      You might hit some challenges like how to handle style elements. For example:

      <cursor>*bold*
      

      Moving the cursor to the right of the b will take two key presses in nvim but would typically be one key press in a WYSIWYG editor.

      I’ve thought about this actually, and Youre right it will require some handling. In the first version of the editor, I will still include the special characters, such as the * for bolding. But I will also style it and what’s after as bold.

      I really like the render-markdown plugin, but my deal breaker was RTL language, since Arabic is a native language to me that I wish to write in vim.

      • sloppy_diffuser@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 days ago

        Best of luck! Sounds like a cool project.

        Not sure if NeoVim uses tree-sitter as the default syntax highlighter, but it will give you Abstract Syntax Tree info if you can jack into it for the document so you don’t have to parse the markdown. Your WYSIWYG view just has to translate the AST which may help with removing style symbols.

        One of many ways to tackle I’m sure.