The documentation should be made clearer in that case. A priority was to make setup and trial easy for non-technical users. It seems now that to technical users it is unclear what is offered.

From your list it is first and mostly:

1. a plaintext file format (.urtext) - specifically, a syntax

2. a Python library to parse & manipulate said file format (syntax)

These in turn require some implementation within an editor. Sublime Text was chosen for its built-in Python interpreter, its package install system, and its GUI features that together comprise a low barrier to entry.

Thanks for the feedback, we will try to make this clearer.

> A priority was to make setup and trial easy for non-technical users

That’s a very strange priority. Why would non-technical users would be interested in a file format and a Python library ?

Seems like a very concise pitch would be "org-mode for Sublime" and that would explain it adequately for most emacs users.

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.

I've heard of it many times, but have basically no conception of what it actually is.

It's a file format / markup language (think Markdown but more feature-rich) with excellent editor support in Emacs.

That's like describing a swiss army knife as a "beer opener"

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.

Is it 'org-mode'?

Similar, thanks for asking. Org-mode was one of many inspirations.

I think you really need a separate pitch and documentation for "technical" and "non-technical" users. The editor system (GUI + Sublime Text integration) is effectively a separate project from the underlying format + library.

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).

i searched for examples but could not find any. i found the syntax page which describes the elements, but it doesn't tell me what i can do with them or why i would use them. each element links to a separate page with more details, but even there i feel questions are left unanswered.

you explain the syntax but not the semantics.

i suppose that maybe if i had tried some alternatives then i would not need the semantics because i'd be already familiar with them.

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.

Funny maybe, but when I opened the site and the movie of that GUI opened and started to play I got very confused, tried to click on things and even maybe got a bit motion sick because it was going along independently of what i clicked :)

Edit: damn spell checkers. It typed “the movie of that guy” instead of “the movie of that GUI”.

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

Is urltext a bit like what tiddlywiki was back in the day?

It was inspired by that and similar wiki-like tools.