refactor, feat: support notationHightligh (close #50), feat: editing in live preview (close #19, about #44)

[LincZero]

There are currently some problems with this PR:

This PR works

en

• feat
  • allow editing in linve preview. close Enable direct editing of codeblocks #19 close Support line editing in live preview #44 close can't easily edit the codeblocks in live preview #1
  • support notaion hightlight / diff / errorLevel ... ([!code hl], [!code ++]). close Update shiki version and support notationHightligh #50
  • add min version. close [FR] Release a min version (new repo) #53 about Reduce startup time #41
  • show language type, edit language type live
  • new option: render mode
  • new option: render engine
• enhance
  • update shiki version: 1.24.0 -> 3.4.2

zh

• 功能
  • 允许实时编辑
  • 支持注释标注的高亮、差异化、错误等级等
  • 添加mini版本
  • 展示语言类型，并也允许实时编辑
  • 新的选项：渲染方式
  • 新的选项：渲染引擎
• 增强
  • 更新shiki版本：1.24.0 -> 3.4.2

TODO / Task

• enhance
  • Excessive compilation size (This problem exists after the shiki version upgrade, and use from 'shiki' replace from 'shiki.mjs') (Because of the problems with bun and npm)
  • It might be necessary to add a new switch option.
  • [-] (option) a short-key to switch the current code block to the original state.
• fix
  • editing in preview, should auto save
  • edit button z-index to low
  • meta highlight invalid
  • Fail to align when the last line is an blank line
  • black line zero height, influence background coloring
  • indent: match
  • indent: render, no treatment tabindex
  • edit: press tab key
• feat
  • [-] (option) new option: allow custom language-type (langAlias, like dateview, dateviewjs, ...)
  • There is no need to edit the line where languageType is located in real time. This requires creating an independent textarea, just like typora.
• docs
  • A website for choosing theme styles: https://textmate-grammars-themes.netlify.app/
  • Notation syntax
  • New feature warning: Confirm that your repository has a synchronization system (such as git)
• other
  • Just code2html directly, this might be a problem? (I'm not sure. At present, it seems that there aren't any problems. I'm not sure what the use is for those codes that I chose to jump out in advance and didn't use)

TODO / Task in nestVersion

• New strategy: editablePre. The principle does not use overlapping textare and pre. Rather, it's like my other project: https://linczero.github.io/obsidian-node-flow/
• Cursor moves up and down, it directly enters the textarea area instead of displaying the source code (like Typora)
• All types of languages are allowed
• style: p::selection {background-color; color} (Adaptive light and shade)
• (last) a short-key to switch the current code block to the original state.
• (last) new option: allow custom language-type (langAlias, like dateview, dateviewjs, ...)

[LincZero]

QQ2025520-133147.mp4

I referred to the textarea on the https://shiki.style/ page. The principle is to stack textarea and pre together.

Warning

This strategy has a drawback: it is very susceptible to the influence of themes/plugins/styles, etc. Because it is necessary to ensure that the textarea and pre overlap perfectly; otherwise, the editing experience will not be good.

It's still the same display:

[mProjectsCode]

Please explain more closely what you are doing and why you are doing it. Please keep to existing coding conventions used in the plugin, please use the set-up formatter, and please keep comments to english.

[LincZero]

I pressed the wrong… 😢 don't review for now.

[LincZero]

Review note

• Switching renderMode.codemirror in the Settings is the original behavior of the plugin. (If you merge, you can choose to modify this option back to the codemirror option)
• You can test the behavior of the min version. It's also very useful.
• I hope to create an organization and add a min sub-project to release the min version. If possible, add me to the organization members.

A review item I haven't modified: obsidian docuemnt api

Although I know that obsidian provides a more convenient document api, I used to like using him too. It was very convenient.

But I didn't use it here because I will encapsulate it into a universal module unrelated to obsidian later (for my use in other projects).

Yes, an editable textarea encapsulated based on shiki/prism component, should be independent of obsidian.