Richer rendering in editor, such as showing link text only (hiding destination) while not under cursor

[koenlek]

Proposal

Side by side editing/rendering has its limitations. It costs much screen real estate and its not very convenient for real-time editing (you can't watch at your cursor in the editor and the renderer at the same time).

For that reason, I prefer doing everything in the editor without opening a renderer next to it. But that leaves some things in the editor a bit annoying. My most common issues is with long links having a very negative effect on the readability in the raw editor. But same can hold for images and equations for people who use those a lot.

I personally like it to make raw what's under cursor, but render it as soon as it's not under cursor. That's what a mardkown editor like Zettlr does.

See this example of how Zettlr handles links:

It would be great if we can support such rendering (as an opt-in setting?) in this plugin!

References

Zettlr.

For more details, see my original VS Code request here: microsoft/vscode#119897

I used to think this kind of rendering wasn't possible for extensions to do in a normal editor pane, as I thought extensions can't edit a plain text window apart from decorating character positions (changing things like color/bold/italic). But the answer on that VS Code issue seems to suggest that this is already possible. If it's actually not possible, then we should follow up on microsoft/vscode#119897 to clarify that this is an actual limitation... Would be great if the author of this plug-in could weigh in on that discussion is needed.

[Lemmingh]

Implementing a WYSIWYG editor in VS Code's normal text editor is indeed not possible.

Such support requires at least a CustomTextEditorProvider. There are technically lots of difficulties.

Webview is confusingly weird sometimes:
microsoft/vscode#83188
microsoft/vscode#114083

Not to mention complex text layout and event handling.

[Lemmingh]

We have received a great number of similar requests. Usually, we recommend that you turn to an existing solution like Typora and Caret.

Zettlr that you mentioned above gives us a new understanding of this issue. Thank you.

---

For now, we are working hard to improve editor decoration and semantic tokenization to mimic such things.

#185
#547
#897

[koenlek]

Maybe we could upvote/reopen my ticket here: microsoft/vscode#119897
Or open one or two tickets that are more accurately titled and described (from an extension author's technical need perspective, rather than my current ticket which is from an end user perspective)

We should ask for supporting richer rendering in the plain editor window, including:

1. Replacing X characters with Y characters while not under cursor (this can shorten links).

2. Support replacing a set of character with a drawable container (e.g. to show an image or equation) while not under cursor.

3. seems more straightforward and should be easier to convince VS Code engs of supporting. 2. is a bolder move, but will definitely be very useful for large groups of user too.

[Lemmingh]

Support replacing a set of character with a drawable container

Sounds good. Should be related to:
microsoft/vscode#50840
microsoft/vscode#85682
microsoft/vscode#36002

[yzhang-gh]

Found https://marketplace.visualstudio.com/items?itemName=TobiasTao.vscode-md several weeks ago, which embeds a Markdown editor in the Webview.

The only question is: why bother using VS Code 🤣. (In this way it loses all features from VS Code)

[Lemmingh]

Happened to discover a demo: Markdown Notebook (ms-vscode.vscode-markdown-notebook) from microsoft/vscode-markdown-notebook

This implies that it's possible to merge editor and preview into one view via the Notebook API to have a pseudo-WYSIWYG editor. 😂

The approach requires lots of tedious work, but might be slightly easier than adding more crazy things to the normal text editor.

---

To make the best of the Notebook, IMO, we have to restrict Markdown syntax to ensure isolation so that each block can be edited independently.

Here are a few thoughts.

The following structures should be disallowed. If a document contains any of them, the notebook should refuse to open it. If a user tries to insert any of them, the notebook should refuse the input.

• Indented code block
• HTML block, except comment (type 2)
• Raw HTML
• Link reference definition
• Reference link

Serialization should enforce normalization on structures in the document root.

• Remove optional leading spaces for each block. For example, from

     > a

  to

  > a

• Insert "a blank line, followed by a comment, followed by a blank line" between consecutive lists.

  <!-- -->
  

  For other blocks, insert a blank line.

I haven't come up with an idea to handle comments robustly.