-
-
Notifications
You must be signed in to change notification settings - Fork 390
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
[Feature] Always display markdown syntax of block at cursor position #645
Comments
It will be added in the future, in a progressive way. |
@Saul-Mirone, may I ask where this enhancement sits on the roadmap? |
Maybe make it as an option? |
Closing this since we'll track the plan at #819. |
@Saul-Mirone Sorry to bother you, i see this has been done, but can't find a way to use it |
@Saul-Mirone Bump. I have the same problem as @s524797336. |
@s524797336 @darkuranium |
@Saul-Mirone @darkuranium After few month, i made this happend. |
@s524797336 I had my own work on this, it's mostly non-buggy (sans a few unimplemented features), but: I'm strongly considering making a "proper" editor out of this (or at least a ProseMirror component). Note that it focuses on inline only, as I intend to use BlockNote or similar for the block components. It also uses a special dialect of Markdown, with some features disabled, and others (e.g. The fact that I'm doing inline-only does simplify a few things, though — for example, I'm free to simply re-parse the whole text on every change (because inline parts, e.g. paragraphs, tend to be relatively short). Then I use ProseMirror's decorations to change how things are displayed. Indeed, this means that internally, inline text is simple plaintext/Markdown (which is what makes it more robust!). I also recently found out about Rino, but haven't had a chance to test it properly. At least on paper, it seems like a legitimately great candidate for a "pure" markdown editor (as opposed to the hybrid "high-level blocks + Markdown inline" that I'm pursuing). |
@darkuranium I tried the example link, it's buggy for me. |
@s524797336 |
@darkuranium You can compare to the Typora to see the differences, which is perfect markdown editor to me. |
Yeah, I totally agree. The secret behind Typora is that it use markdown string as single source of truth and use it to decide a lot of things such as selection, that's how it solves a lot of edge cases. But there're always trade offs, for example, in Typora you cannot mix html with markdown. I really respect Typora because of that If you want to build something just like typora in web, it's nearly impossible to use any rich text frameworks. In rich text based editors, something like |
I've just tried it, and Typora behaves exactly the same on the Note that because of my approach, any MD-related bugs you find are bugs in the Markdown parser itself, not the editor per se. I'm very confident on this, because every single change throws away all the decoration and does a full re-parse. There might be bugs in some unrelated components; this is just a proof-of-concept, at the end of the day. And the parser is an ad-hoc PEG one, of basically haphazardly translating the (relevant for me) inline rules from peg-markdown to PEG.js syntax. Furthermore, I (purposefully, for my use-case) don't support all of Markdown. That's more a design choice for my own uses, than a limitation of this approach. What I'm trying to say is: a Typora experience is 100% possible already, at least at the inline level (block level should be possible, but it'll take more work). It's only a matter of using the same MD parser as Typora, plus a few quality-of-life features (e.g. the way images are edited, and you may have noticed Typora has a ~0.5s delay between a cursor stopping on an element, and it displaying markup).
That's exactly the approach in my editor/prototype, too. It simply re-parses all the contents as Markdown on every change, using ProseMirror decorators to highlight the code. The plugin itself simply looks for an
Ultimately, I'd like to see an editor component that does exactly that. Basically, high-level blocks, but Markdown-level text editing; kind of like what Typora does, though not necessarily with a 1:1 mapping to Markdown (I have no need for such on the block level, but I 100% agree that there are good reasons to have that, too). It's what this issue was about, more or less. |
Sounds that milkdown's inline sync plugin has a similar approach with your editor. It also passes user input into markdown parser and render the ast with prosemirror. The hard part is that you'll lose user's original input as markdown because of the parse and serialize transform steps. But typora won't. |
@darkuranium Maybe i misleading you with my poor English. |
I think you're misunderstanding me. There is no step, ever, that converts the AST back into Markdown. ProseMirror decorations are 100% view-only (they do not exist in the actual document model), as opposed to e.g. marks (which do). Basically, the editing itself is 100% plaintext-based. All changes are based on the base (Markdown) plaintext. Said plaintext is then decorated (only!) in the view (exclusively!). It's basically a really fancy syntax highlighter.
Okay, I see the confusion: your browser behaves differently from mine1!. That's really strange. In my case, only the Footnotes |
@darkuranium How do you use ProseMirror without transform ProseMirror ast to markdown? |
@s524797336 Look into ProseMirror's decorators, that I've mentioned a few times. They're work very similar to marks, but they're 100% in the view. Here's a (truncated/simplified) snippet of what I'm doing; I'm happy to release this project (once I clean it up), but I'll need to figure out what to do for block-level. I'm thinking I'll look into maybe using some ProseMirror defaults, but replace inline only? import { Node } from 'prosemirror-model';
import { EditorState, Plugin, PluginView, Transaction } from 'prosemirror-state';
import { Decoration, DecorationSet, EditorView } from 'prosemirror-view';
import * as parser from './grammar.pegjs';
export default function markdownInline(): Plugin
{
const decorateText = (view: EditorView, state: EditorState, node: Node, npos: number): Decoration[] => {
const decorations: Decoration[] = [];
const p = parser.parse(node.text!) as D.MDNode;
p.walk((node, pos) => {
...
if(node instanceof D.Markup) // Markup is what's ultimately going to be shown or hidden depending on cursor position
{
decorations.push(Decoration.inline(pos, end, {class: 'md-mark'}));
return false;
}
if(node instanceof D.Emph)
{
decorations.push(Decoration.inline(pos, end, {class: 'md-emph'}));
return true;
}
if(node instanceof D.Strong)
{
decorations.push(Decoration.inline(pos, end, {class: 'md-strong'}));
return true;
}
if(node instanceof D.Strike)
{
decorations.push(Decoration.inline(pos, end, {class: 'md-strike'}));
return true;
}
...
});
...
decorations.push(...handleNodesWithinCursor(state)); // basically just adds the 'active' class all relevant nodes within the cursor
...
return decorations;
};
return new Plugin({
...
});
} |
Brilliant idea, I get it. You're not using prosemirror marks. The input will always be a pure text and you'll use decorators to render them into different elements. I think maybe I can give it a try to implement something similar in milkdown. |
@darkuranium Hi, did you solved the bug we discussed earlier, the chrome one? I'm currently continuing with milkdown and implementing my own version of this. I had the same problem, i solved it by not set md-mark |
The trade off of this solution is that it cannot leverage the ability of prosemirror's mark feature. It makes it hard to reuse some abilities in prosemirror's eco system. But it's still a good idea. I'll try to find out that if it's possible to use it with prosemirror mark. |
If we can somehow attach the user origin input on every inline container, like paragraph and heading, we can go back use our old solution.
What do you think? I'll try this with my old solution |
What is the current situation here? Is this possible with markdown? I saw #819 is marked as complete but there seems to be no documentation to enable this feature |
Provide way to always show the markdown syntax for the block at the cursor position, similar to Typora/Obsidian/Vditor/etc.
The text was updated successfully, but these errors were encountered: