PKM-er obsidian-editing-toolbar for a Word-Like Obsidian Editor

PKM-er editing-toolbar solves command-heavy Obsidian markup

PKM-er/obsidian-editing-toolbar addresses a specific friction point in Obsidian: useful formatting operations exist, but finding their Markdown syntax or remembering their keyboard shortcuts can interrupt writing. The README describes the intended user as a note-taker who wants a simple text editor for marking up notes without configuring many hotkeys or memorizing complex Markdown commands.

The project presents its interface as similar to Microsoft Word rather than as a separate Markdown editor. Obsidian remains the host application. The plugin adds controls to the editing environment instead of replacing the vault or changing the note storage model. According to the privacy documentation, toolbar settings, custom commands, and icon configurations are stored locally in `.obsidian/plugins/editing-toolbar/data.json`.

This approach is most relevant to users who format notes through headings, lists, colors, separators, alignment, or repeated editor operations. It can reduce the need to open Obsidian's command palette for actions exposed as buttons. It is less relevant to users who already have a keyboard-driven Markdown workflow and want a minimal interface. The plugin exchanges screen space and configuration effort for visible access to commands, making it a workflow preference rather than a universal improvement.

Editing-toolbar placement and built-in commands

The documented toolbar has multiple placement options, including a top toolbar and a cursor-following toolbar. The README also identifies a `tiny` toolbar style. These choices place editing controls inside the active writing area rather than limiting them to a settings screen. Cursor-following placement is relevant to users who want commands near the current text while editing long notes.

The visible command set includes font and background color controls, list indentation and outdentation, editor undo and redo, a horizontal rule, text alignment, two focus modes, heading levels 1 through 6, custom command icons, command renaming, submenus, menu dragging and sorting, and formatting-brush functions for font and background colors. The horizontal-rule command inserts `---`. The alignment commands insert HTML such as `<p align="justify">..... </p>` or `<center>..... </center>`.

The two focus commands have different scopes. `fullscreen-focus` makes the note page full screen and has a documented default binding of `Ctrl+shift+F11`. `workplace-fullscreen-focus` hides the left and right sidebar panels and has a documented default binding of `Ctrl+F11`. According to the README, pressing `ESC` or executing the fullscreen command again exits fullscreen mode. Users should still check these bindings against existing Obsidian shortcuts.

The formatting brush applies built-in font-color or background-color formatting. The README states that the middle mouse button or a right click can cancel it. Custom icons, renamed commands, submenus, and drag ordering allow the toolbar to reflect a personal command vocabulary. Based on the repository layout, the implementation is TypeScript under `src/`, with Rollup build configuration, `styles.css`, and Obsidian integration code.

Installing PKM-er editing-toolbar in Obsidian

The README does not provide a self-contained installation command or a copy-and-paste release installation procedure. It directs users to the linked How to install Obsidian Plugins FAQ for the basic process. It also points to Discussion #217, titled Editing Toolbar Plugin Advanced Guide, for advanced usage. The repository contains `manifest.json`, `main.js`, `styles.css`, and TypeScript sources, but the README does not describe a manual vault installation path line by line.

For a first real use, follow the README's installation link to the standard Obsidian plugin process. After enabling the plugin, open its settings and review toolbar style, toolbar position, command icons, command names, submenus, and menu order. These are interface settings rather than documented shell commands, so the article does not invent an unsupported installation command.

Begin with the built-in heading, list, color, undo, redo, and horizontal-rule controls. Add, rename, or reorganize commands after checking whether the existing controls match the intended writing process. The README says the plugin supports multi-window and multi-tab operation for Obsidian 0.14 and later. Verify the toolbar in the window and tab layouts used by the vault rather than assuming every layout behaves identically.

The first behavioral check should remain narrow: select ordinary note text, apply one documented heading command, then undo the change. This confirms that the toolbar reaches the active editor without introducing unrelated Markdown or HTML. The README does not document a CLI installer, a migration command, or an automated first-use test.

Editing-toolbar storage, AI requests, and PKMer sync

The plugin has a documented local configuration boundary. Toolbar settings, custom commands, and icon configurations are stored in `.obsidian/plugins/editing-toolbar/data.json`. The README states that the plugin does not transmit vault contents, filenames, or personal data to a server controlled by the plugin author.

Network access is documented for AI assist, rewrite, inline completion, and optional PKMer sync. AI features can send selected note text, a custom prompt, and frontmatter properties to a user-configured AI API endpoint. The listed service types include OpenAI, DeepSeek, Gemini, and Ollama. Requests go to the endpoint selected by the user, so the relevant trust boundary is the configured provider rather than an endpoint operated by the plugin author.

The optional PKMer sync feature sends toolbar settings JSON to `api.pkmer.cn`. The README states that this request includes an OAuth token described as a base64url-encoded JWT for authentication. It also says `btoa()` and base64url encoding are used for JWT authentication token construction when PKMer sync is enabled, not to encode note content for transmission.

This separation makes local toolbar configuration inspectable and keeps network-dependent functions optional. It does not make enabled AI or sync behavior equivalent to local operation. A privacy-sensitive user should review the selected AI endpoint, the kinds of note data listed above, and whether PKMer synchronization is necessary before enabling either feature.

Editing-toolbar limitations around HTML and screen space

The toolbar's main benefit is visible access to common editing operations. Its main trade-off is interface density. A top toolbar consumes editor space, while a cursor-following toolbar places controls near the insertion point. The README documents adaptive shrinkage of toolbar icon width, but it does not explain how icons behave in very narrow panes, how labels wrap, or what happens when commands cannot fit.

The alignment commands also reveal a design choice. They insert HTML wrappers around text rather than using a pure Markdown alignment representation. That may fit notes rendered with Obsidian's HTML handling, but the README does not explain how generated HTML behaves during export, how it interacts with other Markdown inside the paragraph, or whether every theme renders it consistently. Users who need portable Markdown should inspect the resulting note syntax before adopting these commands as a vault-wide convention.

Customization adds control but also creates configuration ownership. Custom icons, command names, submenus, drag ordering, and formatting brushes can improve the toolbar after deliberate setup. The README does not document defaults for every menu item, a reset command, or recovery steps for a damaged configuration. The documented `data.json` path identifies what to inspect, but the README does not provide a repair or migration example.

The focus commands also alter the workspace. `fullscreen-focus` presents the note in full screen, while `workplace-fullscreen-focus` hides the sidebars. That difference is useful for focused writing, but workspace mode is not identical to a full note-page mode. Users who depend on sidebars for navigation should test that command before assigning it a permanent shortcut.

Editing-toolbar versus cmenu and keyboard-only editing

The README explicitly identifies cmenu as the source of inspiration and describes a relationship with that Obsidian context-menu plugin. The documented difference is the additional toolbar experience and command set in editing-toolbar. It adds top and cursor-following positions, a `tiny` style, support for multi-window and multi-tab layouts in Obsidian 0.14 and later, built-in commands, custom icons and names, submenus, drag ordering, formatting brushes, and adaptive icon-width shrinkage.

A user who primarily wants a compact context menu around selected text may find cmenu's approach closer to the required interaction. A user who wants persistent formatting controls for headings, colors, alignment, lists, or focus modes has a specific reason to evaluate editing-toolbar. The README does not provide a complete feature comparison with cmenu, so adopters should inspect both plugins rather than infer every difference from this project's description.

Keyboard-only Obsidian editing is another practical alternative. It avoids an extra toolbar and its `data.json` configuration, but it requires users to remember commands or discover them through Obsidian's existing interfaces. Editing-toolbar is the better fit when visible command access matters more than minimizing interface additions. It is the wrong choice when persistent controls consume too much space, generated HTML is unacceptable, or maintaining a customized menu is an unnecessary burden.

Editing-toolbar releases, upgrades, and license conflict

The repository is not archived, and its last push was on 2026-10-09. Releases include `4.1.10` on 2026-10-09, `4.1.9` on 2026-10-07, and `4.1.8` on 2026-10-07. These dates show recent repository activity, but the README does not define a release schedule, automated test coverage, compatibility policy, or configuration migration procedure.

The repository description identifies `MPL-2.0` as the license. In contrast, `package.json` contains `"license": "MIT"`. The contents of `LICENSE` are not reproduced in the repository listing, so this article cannot resolve which declaration governs the version a user intends to use. Before redistributing modified code or incorporating it into another project, check `LICENSE`, `package.json`, and the repository's current license notices. This identifies the conflicting metadata without offering a legal conclusion.

Upgrade behavior is also not documented in the README. The repository includes `CHANGELOG.md` and `versions.json`, and their contents should be reviewed before changing an installed version. The known settings location, `.obsidian/plugins/editing-toolbar/data.json`, gives users a concrete file to preserve. The README does not say whether settings migrate automatically, whether command IDs remain stable, or how to roll back. A safe upgrade starts by comparing the intended release in `CHANGELOG.md` and retaining the current settings file.

Editorial conclusion

Obsidian users who prefer visible editing controls should evaluate this plugin, especially if the MS Word-style workflow fits their notes. Users who require an unambiguous license or tightly controlled network behavior should first inspect `LICENSE`, `package.json`, `.obsidian/plugins/editing-toolbar/data.json`, and the AI and PKMer sync settings. The first concrete adoption check is whether its toolbar, generated HTML, and local configuration model suit the intended vault.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. PKM-er/obsidian-editing-toolbar on GitHub
4. README
5. Releases