In abab0ed, I added the base editor styles. It is basically highlight styles (nothing custom yet) and seems to look okay for now. Colours will be modified later since majority of them are copied from the nord theme I used to get started.

For example, if you wrote heading syntax (i.e, #) it will increase the font size for the corresponding heading level on that line

It's a good start and already makes the editor feel more lively. Having a hybrid between plain-text Markdown and WYSIWYG is not a typical combination but I think it can work well. That means custom inline parsing and whatnot, which CodeMirror/Lezer do enable support for.

While this is only the start of the new editor, I hope I'll be able to reach my goals for it.

Here are some example screenshots. It looks like a mixture of an IDE + plain-text Markdown + WYSIWYG:

Updated the active file styles so it is more visible. Slightly cleaner looking without the orange accent.

Planning on removing the folder file count for now. It's not very useful and the code behind it is quite buggy. I can give an in depth reason if necessary.

Planning on removing the folder file count for now. It's not very useful and the code behind it is quite buggy. I can give an in depth reason if necessary.

Removed in 7086f92.

Without the folder file count, this is what the file directory looks like:

Tweaked some styles so it looks a little better.

Tweaked some styles again. I'm trying to do minuscule changes if possible since the UI isn't the main focus right now.

File operations are quite buggy at the moment and I will work on them after the file directory part is completed.

I'm trying to do minuscule changes if possible since the UI isn't the main focus right now.

That's subjective though. Areas like the file directory parts will also undergo a UI overhaul but the styling will be fairly minimal for now.

Fixed editor reinitialize destroy logic in 3e62cc9.

When the app loads reading mode on startup and then the user switches to markdown (advanced) mode, CMEditorView.reinitializeEditor() destroys the editor instance regardless if .cm-content node is in the DOM. Removing the else statement logic solves the issue.

Decided to add back Electron-ESM-Vite and removed vite-plugin-electron in f78a3aa.

I disabled Vite's HMR and fully went with Electron-ESM-Vite.

There were some issues where the Electron window wasn't reloading on file change but instead opened an external browser tab instead. Unintended behaviour that was frustrating and decided to roll with my own implementation again.

This is only dev related, so production build isn't affected.

Updated cli.js to Electron-ESM-Vite v1.0.3 (4d78924)

For now, I'm thinking of only showing a small subset of Markdown syntax in the editor instead of all marks/nodes that can be expressed with the styling.

The editing experience feels clunky with all the unnecessary syntax around the marks/nodes, especially nested ones.

I do want to lean more towards WYSIWYG if possible in the hybrid editor, so less pure Markdown would be better for user experience.

Done in (a3b9f41, 548305a)

Didn't realize I made duplicate commits but that's fine. Note they don't have the same changes.

Sample of changes. Looks cleaner now with showing only the heading and code block syntax:

I found a nice looking icon set that I'm planning on using for some parts of the UI:

Flowbite Icons

Since the icon set is in Figma, it makes it easier for me to modify each individual icon to my liking; similar to what I did with the app icon.

In regards to preserving whitespace, I feel that this should be a toggle in the settings instead of a forced default.

Some users might prefer having no whitespace preserved in their document so that the raw file is close to pure Markdown. Having a bunch of obscure characters makes it problematic for portability as well, so by default that should be off.

Since HTML blocks are not added to the parser, users cannot use <br> yet. That will help with sticking close to typical Markdown syntax. Ultimately, once HTML blocks are supported I will remove the non-breaking space character method.

That being said, preserved whitespace will be a default for now until it gets added to settings.

This isn't the same as preserving whitespace like tab behaviour which was fixed in this commit of the modified markdown-it parser. Preserving whitespace in this context is the ability to create empty paragraphs, saving them in the actual Markdown file, and rendering them in the editor.

In a future release, I may add back CodeMirror for pure Markdown editing and also reading mode as extra toggles. Not confirmed yet.

For now, they are removed so I can focus on the ProseMirror WYSIWYG editor.

If development goes well, it might be part of v0.3.0-dev.1.

In regards to preserving whitespace, I feel that this should be a toggle in the settings instead of a forced default.

Some users might prefer having no whitespace preserved in their document so that the raw file is close to pure Markdown. Having a bunch of obscure characters makes it problematic for portability as well, so by default that should be off.

Since HTML blocks are not added to the parser, users cannot use <br> yet. That will help with sticking close to typical Markdown syntax. Ultimately, once HTML blocks are supported I will remove the non-breaking space character method.

That being said, preserved whitespace will be a default for now until it gets added to settings.

This isn't the same as preserving whitespace like tab behaviour which was fixed in this commit of the modified markdown-it parser. Preserving whitespace in this context is the ability to create empty paragraphs, saving them in the actual Markdown file, and rendering them in the editor.

First, I do want to allow tab behaviour by default so that won't go away. However, I'm starting to think that whitespace characters all over the document when preserving is a huge negative for UX inside the editor.

I'll do some more planning in the next few months. Once I start working on Iris a bit more again I'll hopefully get some clear answers to whatever questions and concerns I have.

Before working on the file directory and other parts, I plan on rewriting and building the UI from the ground up.

A proper layout, modern design, responsive, and overall fluid is what I'm aiming for.

By tackling the UI first, this will make it easier to plug things in without creating too many issues like I have now. Once the UI is set, I don't want to make too many big changes afterward.

Rewriting the bigger, crucial parts when necessary instead of salvaging current implementations is better in the long-term.

At the end of the mess that v0.3.0-dev.1 will go through, I'm hoping the app will become more stable and somewhat realistically usable for users.

Yes, it will take much longer to develop this version than anticipated but that's okay. I want to streamline development and pushing the app further after this massive update.

After getting the UI settled down, I will need to figure if I'm truly satisfied with the editor portion.

I understand that the previous decision to revert back to ProseMirror was made. While the current progress is good, I'm a little concerned going this route in the long-term.

I still want to experiment with the classic Markdown editing using CodeMirror but add in some WYSIWYG features inline within the editor. Basically replicating the uneditable syntax using CSS in ProseMirror but everything is editable and visible.

Initial reasoning as follows:

• Editing experience is more fluid for Markdown specifically
• Less fighting with a chain of libraries and parser abstractions
• Easier to add on Markdown extensions
• Room for customization
• Not locked to specific libraries
• Integrates better with Markdown
• Being able to write Markdown without limitations (HTML, table, diagram, etc)

I do want to make everything as simple as possible moving forward after the UI, especially concerning the editor.

Once this decision is made, I will not change the editor again (I promise).

v0.3.0-dev.1 is the last version of any remaining experimentation outside of streamline changes.

Progress for developing the UI will begin roughly around end of July to early August. Once that's done, I'll take it as a starting point for further progression.

I created a super simple mock layout in Figma. It's a bit rough but I feel like it could work out okay in practice:

It does look editor-like at first glance.

The directory area is where things get a bit uncertain. I'm not sure if I want a recursive tree structure or a "one-folder containing multiple files structure". Both are good but it really depends what the goal is for Iris. If I had to choose, a recursive tree structure would be ideal because it mirrors how the notes are displayed locally on a users' file system.

Settings should be a pop-up window (not sure if this is the right term?) so that it gives that native feel instead of being a modal window in-app.

Majority of the current in-app modal windows will be moved to a pop-up dialog/window to give off the native feel.

Product website will also go under a revamp.

Planning to archive the current website and start a new one from scratch before v0.3.0-dev.1 releases. Archive won't happen for another few months at the earliest.

Due to big changes happening in the timeline for Iris, I might as well make the website better too.

In regards to the source code (roughly speaking):

• Electron parts should most likely stay as is with some optimal tweaks. Build steps will be cleaned up and also adding the ability for auto updates from GitHub releases.
• Front-end parts (UI, events, ipc, etc) will drastically change and rewritten entirely. I want to keep this simple and maintainable. This will feel as if I wrote the entire app from scratch so to speak. It will feel like I lost a lot of progress but it will be for the best.
• Back-end parts will go through some changes but mostly decisional ones to keep the code the least complex as possible.

In regards to the source code (roughly speaking):

• Electron parts should most likely stay as is with some optimal tweaks. Build steps will be cleaned up and also adding the ability for auto updates from GitHub releases.
• Front-end parts (UI, events, ipc, etc) will drastically change and rewritten entirely. I want to keep this simple and maintainable. This will feel as if I wrote the entire app from scratch so to speak. It will feel like I lost a lot of progress but it will be for the best.
• Back-end parts will go through some changes but mostly decisional ones to keep the code the least complex as possible.

More on the front-end:

Since I am building the UI from scratch, I will be deleting basically everything (current styles, elements, etc). That includes any events, therefore making the app unusable at that state.

I can consider it as a rewrite but not 100% entirely, as there will be some existing code.

Roughly this is the timeline:

1. UI
2. Editor
3. File directory and its related operations
4. Settings
5. Other things

It's going to be both fun and sad to see some of the current progress all gone but I am preparing this for the future of Iris.

After getting the UI settled down, I will need to figure if I'm truly satisfied with the editor portion.

I understand that the previous decision to revert back to ProseMirror was made. While the current progress is good, I'm a little concerned going this route in the long-term.

I still want to experiment with the classic Markdown editing using CodeMirror but add in some WYSIWYG features inline within the editor. Basically replicating the uneditable syntax using CSS in ProseMirror but everything is editable and visible.

Initial reasoning as follows:

• Editing experience is more fluid for Markdown specifically
• Less fighting with a chain of libraries and parser abstractions
• Easier to add on Markdown extensions
• Room for customization
• Not locked to specific libraries
• Integrates better with Markdown
• Being able to write Markdown without limitations (HTML, table, diagram, etc)

I do want to make everything as simple as possible moving forward after the UI, especially concerning the editor.

Once this decision is made, I will not change the editor again (I promise).

v0.3.0-dev.1 is the last version of any remaining experimentation outside of streamline changes.

A little more on the editor:

While I personally like WYSIWYG for its visual effects, it's hard to work with a system that makes adding features rather difficult and abstracted away in many layers.

If I wanted more freedom in building a Markdown editor suitable for note-taking, I'm imagining CodeMirror is best for it because of it's strengths as a code editor and integration with Lezer.

This again leads to my previous thoughts: hybrid editor. Yes, this is something I talked about already. But I'm seriously thinking that this is really the best fit for Iris as opposed to a pure WYSIWYG solution.

That being said:

1. It's harder to add pure Markdown functions to a fully WYSIWYG editor.

2. But it's easier to add WYSIWYG to a pure Markdown editor.

My opinions are reasoned below:

• ProseMirror has the ability for Markdown-like functions, as you map schema's, keys/shortcuts, parsing between document types (PM -> MD and vice versa) but becomes limited if you truly intend to use it like a pure Markdown editor.
• Latest CodeMirror 6 is more friendly for building a Markdown editor with some WYSIWYG capabilities as adding decorations and whatnot are more streamlined into the core. Obviously there's so much more.
• Adding WYSIWYG-like capabilities to CodeMirror is most likely easier than trying to add pre-existing Markdown functions to ProseMirror, which is already a huge annoyance.
• CodeMirror after all, is a code editor that can be rather powerful when you engineer a unique solution for your use case; like Monaco editor.
• ProseMirror can also be powerful as well but you have to have a proper use case for strictly WYSIWYG. If you're fighting for pure Markdown features, it might actually be the wrong editor for your use case.

Furthermore:

Styling and customization from my experience is also much more streamlined with CodeMirror. I feel like this is also another step of importance if we care a lot about comfort. Theming is easier compared to ProseMirror since CodeMirror is intended for such things. If I wanted to add more advanced features down the line, CodeMirror is the way to go.

Question

Does this affect my intention of what Iris was meant to be?

That is very difficult to answer but not really.

If I go with a CodeMirror editor that is developed as a hybrid editor with both pure Markdown and WYSIWYG capabilities, I get the best of both worlds. A powerful Markdown editor that has some immediate visuals.

While I may have been incredibly indecisive with the editor (as you have seen), I have to seriously nail this down after the UI because it will determine a lot of how the app will grow in the future.

If I wanted to be really honest, I do want a powerful Markdown editor that is visual, simple, and has robust features (but not bloated with useless ones!).

Creating a Markdown app, especially one that is for note-taking, is incredibly challenging. Decision-making for the app is no joke. We all make mistakes along the way but that's how we learn, adapt, and make things better. Iris isn't just something that is developed and done with, no. It's my playground for improvement and making something nice that myself and others can benefit from in their daily lives.

Doing things right means making a million mistakes along the way. Doing things terribly means more room for improvement. Making indecisive/poor decisions makes room for optimizing those decisions for the future.

Because Iris isn't necessarily a specific type of Markdown note-taking app, I feel that it can standout with a hybrid editor. Now I know that these do exist in this day and time. However, I promise that there will be some uniqueness, whether that's in the styling or just overall UX.

Would it be worth all this hassle?

Sure. But first, planning and experimenting a bit before truly committing.

After getting the UI settled down, I will need to figure if I'm truly satisfied with the editor portion.
I understand that the previous decision to revert back to ProseMirror was made. While the current progress is good, I'm a little concerned going this route in the long-term.
I still want to experiment with the classic Markdown editing using CodeMirror but add in some WYSIWYG features inline within the editor. Basically replicating the uneditable syntax using CSS in ProseMirror but everything is editable and visible.
Initial reasoning as follows:

• Editing experience is more fluid for Markdown specifically
• Less fighting with a chain of libraries and parser abstractions
• Easier to add on Markdown extensions
• Room for customization
• Not locked to specific libraries
• Integrates better with Markdown
• Being able to write Markdown without limitations (HTML, table, diagram, etc)

I do want to make everything as simple as possible moving forward after the UI, especially concerning the editor.
Once this decision is made, I will not change the editor again (I promise).
v0.3.0-dev.1 is the last version of any remaining experimentation outside of streamline changes.

A little more on the editor:

While I personally like WYSIWYG for its visual effects, it's hard to work with a system that makes adding features rather difficult and abstracted away in many layers.

If I wanted more freedom in building a Markdown editor suitable for note-taking, I'm imagining CodeMirror is best for it because of it's strengths as a code editor and integration with Lezer.

This again leads to my previous thoughts: hybrid editor. Yes, this is something I talked about already. But I'm seriously thinking that this is really the best fit for Iris as opposed to a pure WYSIWYG solution.

That being said:

1. It's harder to add pure Markdown functions to a fully WYSIWYG editor.
2. But it's easier to add WYSIWYG to a pure Markdown editor.

My opinions are reasoned below:

• ProseMirror has the ability for Markdown-like functions, as you map schema's, keys/shortcuts, parsing between document types (PM -> MD and vice versa) but becomes limited if you truly intend to use it like a pure Markdown editor.
• Latest CodeMirror 6 is more friendly for building a Markdown editor with some WYSIWYG capabilities as adding decorations and whatnot are more streamlined into the core. Obviously there's so much more.
• Adding WYSIWYG-like capabilities to CodeMirror is most likely easier than trying to add pre-existing Markdown functions to ProseMirror, which is already a huge annoyance.
• CodeMirror after all, is a code editor that can be rather powerful when you engineer a unique solution for your use case; like Monaco editor.
• ProseMirror can also be powerful as well but you have to have a proper use case for strictly WYSIWYG. If you're fighting for pure Markdown features, it might actually be the wrong editor for your use case.

Furthermore:

Styling and customization from my experience is also much more streamlined with CodeMirror. I feel like this is also another step of importance if we care a lot about comfort. Theming is easier compared to ProseMirror since CodeMirror is intended for such things. If I wanted to add more advanced features down the line, CodeMirror is the way to go.

Question

Does this affect my intention of what Iris was meant to be?

That is very difficult to answer but not really.

If I go with a CodeMirror editor that is developed as a hybrid editor with both pure Markdown and WYSIWYG capabilities, I get the best of both worlds. A powerful Markdown editor that has some immediate visuals.

While I may have been incredibly indecisive with the editor (as you have seen), I have to seriously nail this down after the UI because it will determine a lot of how the app will grow in the future.

If I wanted to be really honest, I do want a powerful Markdown editor that is visual, simple, and has robust features (but not bloated with useless ones!).

Creating a Markdown app, especially one that is for note-taking, is incredibly challenging. Decision-making for the app is no joke. We all make mistakes along the way but that's how we learn, adapt, and make things better. Iris isn't just something that is developed and done with, no. It's my playground for improvement and making something nice that myself and others can benefit from in their daily lives.

Doing things right means making a million mistakes along the way. Doing things terribly means more room for improvement. Making indecisive/poor decisions makes room for optimizing those decisions for the future.

Because Iris isn't necessarily a specific type of Markdown note-taking app, I feel that it can standout with a hybrid editor. Now I know that these do exist in this day and time. However, I promise that there will be some uniqueness, whether that's in the styling or just overall UX.

Would it be worth all this hassle?

Sure. But first, planning and experimenting a bit before truly committing.

In addition, I want to compare both CodeMirror and Monaco Editor and see which one fits best. Both are strong libraries but I'm not sure what would work best for Iris. I feel that CodeMirror might be better if my intentions are to build an editor for a note-taking app.

Once I reach the editor step of the rewrite, I will evaluate. For now, just going to brainstorm and plan out things.