Fully visual editor mode (WYSIWYG / WYSWYG)

Joplin has what is to me the perfect way to deal with markdown: a WYSIWYG mode that completely hides the syntax, and a dual view mode with pure markdown on one side and a preview on the other. This makes editing pure MD viable, without things jumping around every time you try to edit something, or, better yet, just edit directly the document.

I think that the current implementation of live preview is horrible, and the WYSIWYG table editor in live preview suffers with a mismatch of concepts that do not work. It makes no sense to have WYSIWYG tables and MD for everything else.

I believe the best experience for editing I’ve seen has been from blocknote, which is directly inspired by the Notion interface, and could be stored with markdown formatting.

The focus of Obsidian is knowledge managemente (it used to be announced as a Zettlekasten app), there shouldn’t be this turf war with regards to the interface (which can have many editing modes). And currently no other app on the market today has such a full set of features as obsidian, with decent offline mode.

Joplin’s WYSIWYG uses rich text, not markdown, and has a number of limitations acknowledged by its developer, including not working with their mobile app. I doubt Obsidian will ever have a rich text mode, as most Obsidian users chose it because we prefer markdown and plaintext to .rtf files or storage of notes in a database. If that’s what you want, you’d be better off looking for a rich text PKM app.

Obsidian’s live preview is true markdown and works exactly as it’s supposed to: the markdown is visible when you’re writing or editing it, but hidden otherwise. Most Obsidian users are happy with it (and were overjoyed when it was first released), and those who don’t like it generally use source mode instead.

You can open the same note side by side in source and reading modes in Obsidian, which is similar to Joplin’s dual view mode.

2 Likes

This thread is not intended as a feature request. It is more like a conceptual exploration/discussion of a potential feature request. I’d imagine it to have already been requested, but I don’t know how to name it and thus to search for it.

The idea

I would like a viewing mode in which I only see the “preview” – in this mode, I don’t ever see asterisks, hash symbols, and so on (at least, not the ones that are used for formatting).

I could press ctrl+i to italicize selected text, and while in the “hard preview” mode, I would only ever see the italicized text. Same with headings, and all other formatting. I could potentially also use asterisks, hash symbols, underscores, as part of my writing, without worrying about them messing with the formatting. I can blissfully use the asterisk in the conventional way, to signal that an idea will be returned to later in the text; the “hard preview” mode will automatically add to the underlying markdown whatever is necessary to prevent this from creating bold or italics.

The rationale for this suggestion is that it is often unhelpful and unintuitive for the view to jump around between the source view and the “preview”. For example, when I want to edit a heading, I click on it, and then the hash symbols reappear – thus, the text I’m trying to edit is jumping around on the screen. This is distracting. Similarly, if I want to use an asterisk to signpost something, I have to think “okay, how do I negate the bold/italics stuff”. Instead of thinking about my ideas, I’m thinking about formatting.

Stuff I’d like to discuss:

  • Whether this idea has already been suggested
  • Is the idea is even possible, or if it would take an insane amount of work
  • Or, perhaps the idea goes against the ethos of the app, so the devs would not be interested in making it, or Obsidian users just love markdown, so there would be no user support for it
  • Whether the idea would best be requested as a plugin, or a core feature request (perhaps a fully-fledged “hard preview” mode is just too complex to be implemented as a community plugin)

Yes, this FR already exists with plenty of discussion, and I’m going to merge your post there.


Bike Outliner is an interesting note-taking app. I believe it is rich-text formatting though. It hides any syntax characters, and he calls it “Typing Affinity”. When you are editing at the border of a format, it has a special caret that points left or right so you know which section of the formatting you are editing into.

screenshot_2024-03-03_11-26-34

screenshot_2024-03-03_11-28-25

1 Like

Suppose this feature, a WYSIWYG viewing mode, was implemented as a “core plugin” that you could choose to install if you wanted to.

Would that bother you?

I think lots of people would use the option, and would find it extremely helpful. Those people would get to enjoy Obsidian’s flexibility and its other functionality, without the downsides that they experience with the source/live-preview views.

As for you, what would be the downside? I don’t think there would be any. Yes, “devs would spend time that they could be spending on better features.” I’m speculating, but I don’t think that’s why you oppose this idea – otherwise you would be vocally opposing all ideas that you don’t personally desire. Rather, I speculate that you oppose the idea because it goes against what you perceive to be the ethos of Obsidian.

Is that correct? And in any case, can you explain more why having this function would bother you so much?

I find the sentiment quite hard to relate to… “Please, for the love of God, do NOT add a table editor to this app. There are other apps that have table editors – people who want an app with a table editor should use one of those!”

3 Likes

It seems vanishingly unlikely, unless I’ve missed something.

WhiteNoise said they “don’t think we are gonna go down the path” of this feature request. I’ve scanned the thread, and couldn’t see any posts from the Obsidian team to suggest otherwise. Thus, 100% of the Obsidian team’s comments evaluating this idea have been along the lines of, “that’s not a direction we want to go with this app”.

If anyone from the Obsidian team has ever remarked that they find the idea potentially worth implementing, I’d love to know, as I would love to use this feature!

This feature request is open, so anything can happen. It’s not currently on the roadmap.

1 Like

Well… That’s probably one of the most requested things, you’ve instead worked on things not that much needed. For example a markdown editor didn’t need a canvas; I mean it was a great addon but not needed, there was already excalidraw plugin and I don’t see why a markdown editor should have one.
You’re doing a wonderful job with obsidian but I think you should expand the editor vertically and not horizontally, there are already apps that do a lot of things badly (…eg notion). Obsidian was an expandable markdown editor at it’s core, so I think removing friction between reading view and editing view should be on the top priority.

1 Like

I see. What do you think of the following pros and cons?

Pros

  • a considerable number of users think it would smoothen the process of writing down ideas; a smooth, effortless process of writing down ideas seems core to the ethos of Obsidian
  • it could make the software attractive to more “normie” types, who might also be scared of markdown but also of SyncThing (i.e., lots of people who might pay for Obsidian Sync)

Cons

  • Obsidian is an app that aims to preserve the “markdown feeling”; some users would find it objectionable for this feature to be added, as it goes against that spirit
  • this viewing mode might produce documents that are “messy at the source” (response: the mode is optional, and also, some care about tidying the source only after they have got their ideas down)

Do those capture the main downsides, in your view of the Obsidian team’s opinion?

1 Like

That’s not information you should necessarily expect the dev team to provide. You can check the roadmap for what they are planning.

Thanks for adding your thoughts to this thread, but a friendly reminder to please take it easy with “campaigning” for a feature request. That would be against our Code of Conduct.

1 Like

I’d like to show support to @Ham_n_pineapple’s request for a word editor interface and also commend him for his goodwill when elaborating his points in such a candid manner.

I’ve seen this feature frequently requested here on this forum and elsewhere (particularly reddit), and the reason people insist on it instead of just moving to an alternative is because there is no competitor to the full set of features obsidian that mantains a file-first approach.

Several people to whom I have recommended Obsidian also pointed out the editing experience as a reason they haven’t adhered to it, because they feel it makes it cumbersome, particularly with visual elements other than pure text, such as images, tables, callouts or link previews .

I love Obsidian and I think people who make this suggestion are trying to contribute to make it a better experience for everyone. Also, a lot more people would use Obsidian it if it was available, and this can only strengthen the community.

1 Like

You bet. And this FR is marked as “valuable”. My main point was don’t ping the developers, and avoid flooding the thread. Additional contributions to the discussion are absolutely welcome.

implementing the visual code with the WYSIWYG editing can enhance the usability of the editors, especially for the user who prefer natural editing.

1 Like

Huge +1 on this.

I’m trying Obsidian and love most of it compared to everything out there but the Preview mode is poorly designed and the jumpiness of the text makes for a bad time in the core editing experience. I want the ability use markdown to trigger the formatting using markdown but then I want it to disappear and stay gone unless I go into markdown editing mode. (Craft Docs does this well.) I am really not sure what the benefit is of it sticking around most of the time.

WYSIWYG and markdown feeling are not conflicting at all, I think what I need is:

  1. Maintain rendering while displaying format (highlight, bold, callout, etc.)
  2. A better animation, don’t always flicker (when clicking a certain format, the entire page of text will change, reducing attention
  3. Matching of reading mode and real-time preview (line height, list left padding)
  4. Bring back the custom cursor css. The obsidian team must have never used windowsOS. With the 1-pixel cursor and the layout changes of the entire page, I often can’t find my cursor (ninja cursor is very nice, but it also has some problems) (A good cursor animation will make typing a pleasure)
  5. Block dragging like logseq
  6. Fixed the problem of writing code blocks in lists and callouts
3 Likes

Just noticed this approach in Nota which I think could also help to improve the experience quite a bit. Still Markdown-first but reduces the jarring UX of the link always expanding.

Normal state
CleanShot 2024-04-12 at 11.53.54

When you click on the link text it shows the markdown but keeps the link collapsed behind a little link icon.
CleanShot 2024-04-12 at 11.52.07

Finally, if you click on the link icon it expands the full URL

Once you paste a URL it is more rare to be messing with it vs editing the link text itself, so I think this is a great middle ground.

2 Likes

My feelings when I intend to move the text cursor a few lines up a document using the cursor keys without running into exploding links:

https://i.pinimg.com/originals/30/0b/da/300bdabd38bca6fcc84549d47f6189f5.gif

Over the few years, I never settled into the Obsidian completely because of this =(

This is my favorite (synthetic) example: The Hobbit or There and Back Again.

2022-07-20-14-25-41

Usually the journey home seems faster, but in Obsidian it does not. Maybe there’s some kind of wormhole lurking here?

1 Like

If someone wants to simulate the WYSIWYNG editor in Obsidian, you can follow the codes below to put together your own editing behavior. You can also make your own combinations of multiple scc Snippets and easily turn them on or off as needed in Obsidnian settings if something goes wrong.

My experience

It’s not perfect, but you can get used to it…

The main thing to get used to is that when a character is turned off, don’t start rewriting the words completely at the beginning, because you might “miss” between the hidden character and the first letter. You just have to test it to see how you like it…

When forcing the lines carefully… I think it’s a problem to edit them afterwards…

If you turn off the # characters, beware of adding inline TAGS. I don’t use them, so this is not a problem for me…

These can be used quite well:

/* Hides asterisks used for bold and italics */
.cm-formatting-strong, .cm-formatting-em {
display: none;
}

/* Hides underscores used for bold and italics */
.cm-formatting-em.cm-em-1, .cm-formatting-strong.cm-strong-1 {
display: none;
}

/* Hides `#` used for headings */
.cm-formatting-header {
display: none;
}

/* Hides `==` characters used for highlighting */
.cm-formatting-highlight {
display: none;
}

/* Hides markdown symbols for strikethrough */
.cm-strikethrough {
display: none;
}

These can be used, but it’s probably better not to use them:

/* Hides characters for code blocks */
.cm-formatting-code-block, .cm-formatting-code {
display: none;
}

/* Hides characters for block quotes */
.cm-formatting-quote {
display: none;
}


I don’t use these - because they bug me:

… maybe it will suit you

/* Hides characters used for lists */
.cm-formatting-list {
display: none;
}

/* Hides characters used for links */
.cm-formatting-link, .cm-hmd-link-url {
display: none;
}

/* Hides markdown symbols for strikethrough - this has completely disappeared */
.cm-strikethrough {
display: none;
}

/* Hides HTML tags in the editor */
.cm-s-obsidian span.cm-tag,
.cm-s-obsidian span.cm-bracket {
display: none;
}

/* Hides markdown symbols for superscript */
.cm-formatting-superscript {
display: none;
}