Love this game. It taught me to look for a move like g4.
Also it was probably not objectively the best move (and definitely not Spassky's best game) but Tim Krabbé made a list of 110 most fantastic moves ever played, and he put Spassky's 16...Nc6 against Averbakh as no. 1 (certainly an unorthodox choice):
Well if you don't do that, you would only have a lowest common denominator system with none of the advanced features, and the world has enough of those.
If I wanted to emulate a fraction of org-mode features I use daily in markdown, I would have to use Obsidian with a bunch of plugins, and we would end up in same boat.
I don't know the exact spec situation, but I know that comprehensive parsing libraries in modern non-elisp languages exist. An org-mode contributor has one in Julia[1], another in Dart[2] that powers a Flutter app, and there are many tree-sitter grammar based tools that are useable from neovim (e.g. [3]). The basic org2html or org2pdf CLI needs are already addressed by Pandoc.
The format/spec isn't really the problem. It's just that parsing and rendering Org Mode files is like parsing and rendering .PSD files - getting your app to open and write PSDs alone does not turn your app into Photoshop; you're still missing 99% of the features.
Right but if you implement the rest of the features, you become an org-mode IDE anyway. I don't mean that's a bad thing, syntax is just bare minimum, most usefulness comes from interactive developer experience anyway. I was just addressing the point parent raised that marrying markup with IDE is a bad idea, and that when it comes to syntax org-mode is hardly underspecified compared to other markup languages.
Would it be neat to have an alternate complete implementation of org-mode elsewhere? Sure. But unlike say Photoshop, Emacs is already open and extremely hackable. That mitigates most of the reasons you would want to.
I use it to write long running little scripts. It's better than shell, and imo more useful out of the box than Lua. They are basically for I/O (often using sqlite which it has great integration with, or using expect which is also great) so I don't care about performance, but I like that it requires much less memory compared to say Python for that kind of little things (there is also jimtcl which is also neat in this regard).
So far an API has been less of a priority than focusing on the user-facing product. But it seems there's a reasonable amount of demand for it, which we'll consider.
I consider AIs without API access even as non existent. Not everybody wants a web interface and waste time on copy&paste all the time. APIs can hook the filesystem directly with an AI, make complicated prompt engineering and multi file changes a non-issue. And they should also help you to make more money (don't undersell the API access and you're fine).
Without an API the community can also not compare Phind-405B to other models easily.
Would be great to have access to your model in a LLM gateway like https://openrouter.ai/
You should also consider the ecosystem value that might be created for your product. There’s a prior example.
ChatGPT amazed people but its UI didn’t. A bunch of better UI’s showed up building on the OpenAI API and ChatGPT own. They helped people accomplish more which further marketed the product.
You can get this benefit with few downsides if you make the API simple with few promises about feature. “This is provided AS IS for your convenience and experimentation.”
I think an API would be fantastic for use cases like Aider / SWE agents. The primary issue besides fully understanding the code base is having up-to-date knowledge on libraries and packages. Perplexity has "online" models. And phind with Claude, GTP-4o, Phind 70 + search / rag would be awesome.
Similar feeling here. I found that simple full-text search goes a long way to scale without needing to impose structures (and things like backlinks). It will probably not be enough for prolific note takers but I think it's enough for people with say <1000 files.
(although I use Xeft[1] which is spiritually the same but I find the UI cleaner and snappier because it uses Xapian rather than elisp for full-text search).
I actually switched from Deft -> Xeft -> Howm as my main UI for searching and creating notes :).
Xeft is indeed great, and I still keep it around for more involved searches (like “+key1 -key2” and “key1 NEAR key2”). But most of my searches now go through Howm, which supports fulltext as-you-type searching (can be invoked by pressing “g” for “grep” from its note list), and it can shell out to Ripgrep to speed it up.
I don't really care about evangelising anything, but this bit:
> Every now and then I would update a plugin in Neovim and everything would break, and I would have to spend time fixing it instead of getting work done.
Would be a problem anywhere there is a plugin system. Just don't go around updating kitchen sink without having the ability to rollback. Full on version controlling 3rd party plugins could be annoying (unless you use a plugin manager specifically with that support e.g. straight.el or elpaca in Emacs), but simply taking a dumb snapshot of plugin directory may also do the trick.
This is S tier software. I remember using this on a laptop with 2gb RAM years ago. The combo of mpv and youtube-dl could deal with large number of sites (not just youtube), when even the browser struggled.
yt-dlp[1] has now taken on that mantle. I think mpv nowadays just recognises yt-dlp as the de facto alternative, but if yours doesn't then you can just put this in your mpv.conf:
