I think this approach is more common than the hype for actual work. I do something similar, many back and forth, then settle on something often with now known tradeoffs, written by hand to spot issues as a final guard/ keep consistent naming etc.

Not a textedit fork, but I am building a minimal text editor with niceties based on scintilla. So performance wise on par with Notepad++ et al.

> Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more.

It's still true. There's no way around it, web views will always be slower.

Hackerman Text editor.

595 days and counting.

ᕙ(⇀‸↼‶)ᕗ

> actively reject multiple safety warnings

Is this like a popup? which most people actively accept without blinking

I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.

It's not one pop-up. To fully replicate the concept you have to agree on three separate screens (and these are not in quick succession):

1. exit restricted mode to allow third-party plugins

2. trust the author of the vault that's being shared with you

3. trust the plugins being shared with you via sync

The pop-ups and "social engineering" in question are things that any users in HN likely already accepted, which is to enable community plugins. These community plugins are the backbone of Obsidian and where a lot of the meat is behind its fame come from.

There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.

I'm gonna push back against the "backbone of Obsidian" part. I'll argue that vanilla Obsidian is plenty powerful enough.

I know many people swore / swear by the datatables plugin, but now that Bases in core, you can get pretty far without it, no?

I agree with you that vanilla Obsidian is plenty powerful, but it's exactly like Vim's case. It's good enough on its own, but there's always more.

There's countless articles and videos about various community plugins and even curated selections of them depending on your use case for Obsidian.

I can't do without the livesync plugin. And also copilot (connected to a locally hosted LLM of course) and readitlater.

As someone who doesn't use shared vaults - would the warning popup, 'to enable the "Installed community plugins" synchronization feature', not be on a per shared vault basis? Is trusting a single shared vault for plugin sync going to mean I sync my plugins for every shared vault?

IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.

This. Make it like a vim mode, input “I know what I’m doing” or even require some basic fizz buzz.

> “But Local Models Aren’t As Smart”

This is what makes me continuously doubt and rewrite the local-first approach to inline chat in my editor. Next edit/ code complete makes more sense due to latency advantage. But chat is hard.

It's fast and feels good to run locally, but output quality is just not ChatGPT etal.

> How does anyone at Microsoft/Github thinks this is ok?

Their whole marketing department probably.

> .. webview ..

That would make it an web app tho. Not sure if that's what OP wants when making Swift apps.

I recently tested input latency on Mac Mini M2 Pro, keypress to visible pixel (p95 value).

- Zed 36.8ms (26.3 avg) - Sublime 33.5ms (25.9 avg) - VSCode 31.7ms (20.6 avg) - Hackerman Text 15.3ms (12.5 avg)

All editors tested as stripped down as possible, minimal UI etc., empty file, no syntax highlighting. Mostly surprised by VSCode tbh.

Testing on sqlite3.c (with syntax highlighting): Zed 60.5ms, Sublime 37.1ms, VSCode 22.0ms, and Hackerman Text 18.4ms.

That's a useful metric to track. Could you explain how you measured those numbers?

And soon™, https://hackerman.ai/