Discussion: Expanded editing capabilities, hotkeys, Jetbrains features

[Jackman3005]

Hi, this is more of a discussion item I'd say. I have been a long time Jetbrains products fan. I know, I must be in the minority now-a-days...

In the recent age of AI and agents, I have stopped using the IDE for nearly all prior coding needs. I keep an IDE open now for only 2 reasons:

1. Search/read files (the need for this is dwindling more and more)
2. General Text Scratchpad (no formatting or commonly markdown formatted, sometimes code-language formatted)
   1. Take notes
   2. Todo lists
   3. Communications drafts
   4. Prep env vars for prod
   5. Fix poorly aligned/formatted AI agent text
   6. Prep SQL report queries to run and paste results back
   7. etc. etc.

Why I write in the IDE

After years of mastering the product I find it really smooth and powerful even for simple plain text or markdown.

• Multi-cursor mode (both across consecutive lines and via search string) 2x Option + up/down or Ctrl + g when text is selected.
  • Ctrl + Cmd + g adds a cursor/selection for all matching text in the document, super handy!
• Word jump (plus opposite-camel-case word jump <3). Also word jump with selection. Option + Left/Right or Option + Shift + Left/Right, I usually hotkeyed opposite camel-case mode to Option + Ctrl + Left/Right
• Jump to typos/errors/warnings F2
• Move to new line below Shift + Enter to start a new line below without splitting current line at cursor.
• Similarly Push to new line below Cmd + Enter to push content after cursor onto line below and keep cursor where it is.
• Powerful find and replace with all modes/config hotkeyed, including case-insenstivity, regex, etc.
• Join lines (select two or more lines and in one stroke it removes all newline characters within). Helpful when agent output always splits across lines when there shouldn't be a line split.
• One key-stroke line/selection duplication Cmd + d (selection duplication can be really nice, sometimes within a short string or if you want to duplicate multiple lines, who needs a clipboard?)
• Column edit mode (all characters monospaced, you can hold shift to select text across multiple lines without selecting all the characters on each line, just those in a column of the selection. Super useful when editing markdown table contents or when many similar lines need an identical change, although multi-cursor mode is often easier in those cases). Cmd + Shift + 8/F8?
• Extend/Shrink Selection Option + Up/Down (this is more used in code than text as the extend/shrink is "smart" and tends to jump the selection to the next scope boundary, can be super cool at times)

The list goes on, but that's all I can remember off the top of my head. Yes, some of these are available in other editors, but not all of these from what I've found. Also it's worth mentioning that there are some other non-hotkey features that are nice here, markdown rendering, table formatting, typo detection, grammar help, file-path completion, etc.

Why change what works?

I really love Omarchy and I know that despite being a Jetbrains fanboy, I'll likely need to stop renewing my subscription soon as I don't get the value I once did from it. It's really this text editing experience that I think I'm holding on to the most though. Also Jetbrains isn't light on resources and holding on to 4GB of RAM just for scratchpad purposes throughout the day doesn't make sense on its own. Especially since it's not fast enough to open for quick one-off things so you need to keep the IDE open all the time to get the value I want from it (focus it, open new scratchpad, paste + make edits, copy results).

Omawrite to save the day?

I wouldn't want to bloat Omawrite, but I feel like a number of these things are easily advanced features that can be made available and ignored by beginners while allowing for power users to thrive. I think similarly to Jetbrains it can be a learning curve resulting in masterful text manipulation without the need to climb the curve at all if not desired.

I'm interested to contribute to Omawrite to get the experience I'm aiming for if it's something that would be well received here.

Am I in the wrong place? Should I just suck it up and learn nvim deeply and add whatever is missing to my own custom config (assuming that's possible)?

Thanks for getting this far. I would love to hear from the community on this, maybe I'm off base and just ranting into the ether. Again, I'm happy to help contribute if what I want is in general alignment with what others want for Omawrite.

Cheers,
Jack

[Vyrnexis]

Great ideas, but keep in mind that Omawrite is designed first and foremost to be a lightweight, focused Markdown editor ("the essence of writing"), not a full-fledged IDE.

That said, you can definitely extend it to fit your workflow! I ended up creating my own fork (Vyrnexis/Omawrite-Standalone) to make it run completely standalone and added several features I wanted, such as:

• Fenced Markdown code blocks with syntax highlighting

• Keyboard font zoom (Ctrl+= / Ctrl+-) with a visual zoom level overlay

• A few other quality-of-life adjustments

I’d strongly recommend forking the repo and building the IDE features you’re looking for. If you keep your changes clean and make one commit per feature, it leaves the door open for upstream to easily review and cherry-pick anything that aligns with Omawrite's core vision—while you still get every feature you want without pushing the base app into mini-IDE territory.

//Edit
P.s if you do decided to "suck it up" and you haven't gone down the nvim rabbit hole yet, I suggest Helix editor, you have pretty much everything you need out of the box, easy config and a whole less footprint and overheads than nvim

[Jackman3005]

Thanks @Vyrnexis I'll check it out. I know the basics of nvim and I'm not afraid of driving from the keyboard alone, but I still feel like the process of learning neovim and vim in general has been a long slow one... likely I need to sink some time in it...

I'm waiting for quattro to settle down a little before I upgrade my main machine. When I do I might fork and see if I can get omawrite to be what I'm hoping for. Let's see!

[Somnius]

Omawrite handles basic Markdown beautifully, but its rendering stops short of some very common constructs. Notably fenced code blocks and similar extended syntax.

A lot of real-world .md files (READMEs, documentation, technical notes) rely on these, so opening them often means reaching for a second application.

My Suggestion

Extend Omawrite

• Add rendering support for fenced code blocks (basic syntax highlighting would be a bonus) and other common extended Markdown.
• This keeps the default footprint lean — no second editor needed at all.

[omarchybot]

Triage read the new comment about fenced code blocks and extended Markdown, checking one thing only: whether it describes a defect in what Omawrite already does, as opposed to asking for something new. It does not, and here is what current master actually does, so the scope discussion has the facts.

MarkdownHighlighter keeps no state across blocks (src/markdownhighlighter.cpp:106), so a line inside a ``` fence is styled as prose: a # at column zero becomes a heading (`markdownhighlighter.cpp:140`), and `x` or `x` becomes emphasis with the markers painted in the background colour at zero width, which makes those characters invisible (`markdownhighlighter.cpp:63`). Caret movement skips the same hidden markers inside a fence, because it reuses the same fence-unaware span list (`src/backend.cpp:364`). All of that is display only. The editor is `TextEdit.PlainText` (`src/Main.qml:540`) and saving writes `toPlainText()` (`src/backend.cpp:466`), so nothing changes the bytes on disk, and the file you opened is the file you save. Not everything is fence-blind either: Return already counts fences and inserts a single newline inside one instead of continuing a list (`src/Main.qml:601`).

The README documents no fenced-code or extended-Markdown styling, so this is a gap rather than something documented that stopped working, and that is why it stays a feature request rather than a bug split out of this thread. Part of it is already in flight: PR #2 makes the highlighter fence-aware and reads inline code literally, which covers the "code read as prose" half. Syntax highlighting inside a block, tables, and other extended syntax are not in that PR and are not anywhere else today.

Whether Omawrite should grow any of this is a scope decision, and it belongs to the maintainer rather than to triage. This thread is waiting on that, not on further detail from anyone here.

Reviewed by Opus 5, with a second opinion from Codex at xhigh reasoning, which agreed there is no defect and contributed the caret-movement finding above. Both reviews were of the source, not a running build.