This was great feedback, thank you. One of us in the development group is looking at NeoVim now as another possible implementation.

It would also explain it for non-emacs users.

I am not and never have been an emacs user, yet I still know of org-mode.

Is it 'org-mode'?

It was inspired partly by org-mode, but org-mode can be quite difficult for non LISP-users. This project has the priority of low barrier to entry, with a lot of the Python-specific functionality coming out-of-the-box, and abstracted away underneath the syntax of "frames and calls." Even those are can be used only as desired; as another poster mentioned, the project has wiki-like functionality without going any deeper than the basic syntax.

This was helpful, thank you. We have replaced the home page video with inline examples of the syntax instead, and will be adding some real-world use examples in addition.

This was helpful feedback, thank you. Removed the video and added examples instead, and will be adding more.

This is helpful feedback, thank you. We are working on this possibility, and explaining a clearer separation between, as another poster mentioned, the Python library (which is headless) and a specific implementation (which requires some sort of text view that may have GUI features).

Yes, this is nonsensical or contradictory because GP is not aware of the correct definition.

https://news.ycombinator.com/item?id=28105868

You can even go a step farther; arguably, in a Unicode era, there is no such thing as "plain text" anymore. Nominally "plain text" has always had markup in it, such as newlines, tabs, and so forth, but ok, sure, we can incorporate those things into what may be slightly misnamed but is a "simplest possible format" that had a lot of useful characteristics, like, it mostly fit into a grid (except tabs), it naturally fit with a monospace font, it could be dumped to terminal, it often had only 7-bit ASCII characters in it and if it was 8-bit the encoding was externally specified somehow, it is monochrome, etc. etc. There are some ways this strains the concept of "plain text" but when it wasn't a moving target for a couple of decades (modulo perhaps some 8-bit encoding issues) at least English speakers could pretty much agree on what "plain text" meant.

But even "plain text" unicode now breaks a huge number of those assumptions. A number of Unicode characters have defined widths, like all the spaces. Kanji is broadly defined to be twice the width of an English character in a monospaced font, and that's subject to a number of exceptions too. There are markup characters like Right-To-Left, Left-To-Right, and the Arabic Letter Mark. Emoji are not exactly intrinscally non-monochrome, but aren't exactly intrinsically monochrome either (your users may have some objections). Zero-width joiners have complicated semantics that go well beyond just "a zero-width space". You have to handle composite characters e + acute in addition to the e-acute itself, and you have to render arbitrary numbers of them to even remotely properly handle Zalgo text. You have to worry about font glyph support in a way that you didn't in a 256-character world.

Even text with no markup has mandatory markups in it now; they may not be "bold" or "italic" markup but if you want to even remotely properly render them the minimal code necessary to do so is rather more complicated than a minimal bold/italic support. Unicode doesn't really have that "we all agree on the defaults so we can just dump it to the screen and do the simplest possible render and we'll all agree that's what it should look like" anymore.

As opposed to what? A pdf?

thats just off by one

If you have the patience to try again, we are eliminating any package control channel from the process, it is now a .ZIP file download. See if these steps are any more successful: https://urtext.co/setup/sublime-text/

This was helpful, thank you. We replaced the video on the homepage with some inline examples of at least syntax, and will soon post some examples of "real world" use.

Curious, how important would it be to you that the examples be readable with syntax highlighting and full tabbing/formatting in the browser? It is somewhat complicated to accomplish this and; present examples are mostly using manual inline styling.

Would examples projects on Github be helpful? It presents the same problem for syntax highlighting.

My question was honest:

What urtext - to someone who moved from org-mode to Obsidian - seems to do is

* chain you to a proprietary text editor that does some python interpreting. I wonder which use cases would want me to have my document change itself (or even change its own changing logic).

* highlights 'features' that really do not live in the document itself but rather in the editor's logic (like timestamp handling)

* introduces a complex structure to express 'nodes', which appear to be essentially text anchors.

But anything else, the editing, the easy-UI-free syntax, markdown has done ten years ago.

So it is not a text format, because it lives in a very specific editor. It is not a fully-fledged software package either. It sounds a lot like some sort of macro language which woke up one day and decided to rather be a text repository.

If you (speaking of a general you, not you specifically) wanted to convince people to make the switch, a list of barely described features is insufficient. You need to sell a solution, not a product.

Your answer contributes nothing, which is just shy of what the intro pages offers in relation the question. Everything urtext claims, is readily achievable through markdown + some collection of tools of your choice, for which many exist, some being all in one solutions. Obsidian with a few community plugins is a clear example.

I enjoy and appreciate projects like this, I _WANT_ to like and understand it, but as it stands the information simply isn't there.