Urtext /ˈʊrtekst/ is an open-source library for plaintext writing, research, documentation, knowledge bases, journaling, Zettelkasten, project/personal organization, note taking, a lightweight database substitute, or any other writing or information management that can be done in text format. With some Python knowledge you can practically run your entire life from Urtext.
We have had trouble with package control, unfortunately. The package control bot was down for over two months without any notification to developers, and we did not know why the small pool of test users were unable to pull updates during this time. As a result, the package at https://packagecontrol.io/search/urtext is now an installer only. See the readme at https://github.com/nbeversl/urtext_sublime_installer.
It installs another package control channel and pulls the latest from there. Obviously this is not ideal. We tried to solve it with Package Control maintainers to no avail.
If you have time to test and give feedback on any problems, it is always appreciated.
Can you elaborate on how you use it? I tried googling any mention of it and failed (all reddit posts were deleted). I installed it into sublime but it didn't seem to do anything
Correct that it needs an editor, but it need not be GUI. Everything can be done in text buffers only. The library is newly presented and there is not an implementation in VIM, but it would be a good choice and would not take long to implement. I will make a note that there is interest.
100%. This seems like something the Neovim crowd would get behind. They can be a helpful bunch too - it might be worth just starting a branch and asking for contribution assistance.
That's my main objection to this urtext thing - it's yet another text format, i.e., not really plaintext.
I'm sure you could use it to run your life, but should you, probably not. Better to stick with more standard formats. You can even script those with Python, too...
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.
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.
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”.
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).
Then, goes on to present a convoluted node-based system for managing content. Why call it "plaintext" when it clearly has nothing to do with it? Perhaps describing it as some kind of a Markdown alternative, i.e. a markup-language would make more sense?
What is the utility of such a definition? As far as I am concerned, anything I can read with my editor is plain text. That definition is trivially useful on a daily basis. I don't see any point in calling markdown something other than plain text. Because it's just plain text.
And of course, I intend deep disrespect that you had the gall to claim correctness for such obviously arbitrary definitions.
Both definitions are correct and are regularly used.
Personally, I find 'human readable' to be a better term for your definition and use 'plaintext' to mean either unformatted text (except perhaps with whitespace), or the non-markup text within a marked up document.
Wiktionary suggests that the divide is contextual, with your definition being the 'file format' definition and GP's definition being the 'computing' definition.[0]
To me it's something like "the target language does not differ from the expressing language"?
A .txt file for notes is plaintext, because the language I'm using doesn't have to be compiled for my goal. Programming languages are not, because the expressed language is compiled into some other target language (machine code).
Markdown is not, because it's compiled into HTML.
A .txt undergoes no transformations from my writing, to its storage, to my later usage of it.
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.
When I follow the instructions on https://urtext.co/setup/sublime-text/ (did it several times with a clean slate each time) there is always only "Urtext" available for package install, never "UrtextSublime".
This is on Linux with Sublime 4 (and 2, didn't try v3).
Thank you for the feedback, very helpful. We are trying to solve this to make something close to a single-step install. The package at https://packagecontrol.io/search/urtext is now an installer only. See the readme at https://github.com/nbeversl/urtext_sublime_installer for information. It installs another package control channel and pulls the latest from there. Obviously this is not ideal, but it is the best we can do at the moment, unless you want to use Git and do it manually. Glad to hear any problems you run into.
I think I'm too dumb for this. I have only installed Sublime Text 4 because of Urtext, and I have no prior experience with the editor. At all.
It is unclear to me what I should do with the `sublime_urtext_installer.py` file, so I jumped to the “run these steps manually” steps instead. This seems to be exactly what I did before with no luck, and this time is no different. Having followed the steps, the last step always only offer me to install “Urtext”, not “UrtextSublime” and if I do that there will be zero entries with “Urtext“ in the command palette afterwards.
I will be happy to try the `sublime_urtext_installer.py` road, but I simply don't know what to do with that file.
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/
Glad it worked out, thanks for the persistence. Glad to receive any feedback or questions either here or via the support form on urtext.co if you prefer.
looks like quite bad / incoherent for me personally. For something that is competing in a "make your information easy to handle, read, and manage" market, it takes too much effort to try figure out where the creators want me to look, or where valuable information exists. This doesn't leave one feeling confident on what is being offered. For example I load in to a massive animation that flicks around at a fast pace. So the first impression is "fuck you, you don't need to know what is going on"
I then scroll down to try find something to read/look at that makes sense. I am met with two bits of information
"just download it to get started"
and
"it's a plain text editor that does stuff many tools you already have do"
So far, things aren't great. Lets look at the demo project, maybe that has some screenshots that really highight it's potential.
"Download the software and just import the demo project"
So, over all, the impression one is left me with is a "just trust me bro, please bro, it's really useful bro, just install it, I swear" kind of message. Personally, I am not just unconvinced by actively wary of this project.
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.
i think having examples at all is much more important than worrying about syntax highlighting. example projects on github or anywhere else would also be great. the format would probably even lend itself to use the explanations as your example text.
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.
If you interpret the contents of a "plain text file" through anything more complex than a Unicode text encoding, then you now have "a special format". (And if you don't, you still at least need some encoding, even if it's an implicit ASCII encoding. "There ain't no such thing as plain text", as they say.)
There are also plenty of "special formats" out there that are really just zipping up a directory tree of something simpler.
76 comments
[ 3.3 ms ] story [ 122 ms ] threadSimply the ability to place, edit, and sort by timestamps sets it apart from other notes/knowledge systems.
Requires some familiarity with Sublime Text and ST’s quirks, and eventually an ST license is basically a necessity.
If you have time to test and give feedback on any problems, it is always appreciated.
-- https://leo-editor.github.io/leo-editor/
Than all this code+program+data could be decoupled.
That's my main objection to this urtext thing - it's yet another text format, i.e., not really plaintext.
I'm sure you could use it to run your life, but should you, probably not. Better to stick with more standard formats. You can even script those with Python, too...
Sort of like comparing plain HTML to PHP. Appear in similar places, with completely different guarantees.
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.
I am not and never have been an emacs user, yet I still know of org-mode.
That’s a very strange priority. Why would non-technical users would be interested in a file format and a Python library ?
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.
Edit: damn spell checkers. It typed “the movie of that guy” instead of “the movie of that GUI”.
Then, goes on to present a convoluted node-based system for managing content. Why call it "plaintext" when it clearly has nothing to do with it? Perhaps describing it as some kind of a Markdown alternative, i.e. a markup-language would make more sense?
https://news.ycombinator.com/item?id=28105868
What is the utility of such a definition? As far as I am concerned, anything I can read with my editor is plain text. That definition is trivially useful on a daily basis. I don't see any point in calling markdown something other than plain text. Because it's just plain text.
And of course, I intend deep disrespect that you had the gall to claim correctness for such obviously arbitrary definitions.
If I can open your file in a notepad and effectively edit it without the format changing or getting corrupted at saving its plain text.
Not plain text: Attempting to edit an .exe file in notepad.
Unfriendly plain text: Minimized javascript where the entire file exists on one line and the human readable elements jumbled together.
Plain text: Your average source code file/html file that attempts to adhere to something around 80-120 columns of text.
Personally, I find 'human readable' to be a better term for your definition and use 'plaintext' to mean either unformatted text (except perhaps with whitespace), or the non-markup text within a marked up document.
Wiktionary suggests that the divide is contextual, with your definition being the 'file format' definition and GP's definition being the 'computing' definition.[0]
[0] - https://en.wiktionary.org/wiki/plain_text
A .txt file for notes is plaintext, because the language I'm using doesn't have to be compiled for my goal. Programming languages are not, because the expressed language is compiled into some other target language (machine code).
Markdown is not, because it's compiled into HTML.
A .txt undergoes no transformations from my writing, to its storage, to my later usage of it.
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.
This is on Linux with Sublime 4 (and 2, didn't try v3).
I think I'm too dumb for this. I have only installed Sublime Text 4 because of Urtext, and I have no prior experience with the editor. At all.
It is unclear to me what I should do with the `sublime_urtext_installer.py` file, so I jumped to the “run these steps manually” steps instead. This seems to be exactly what I did before with no luck, and this time is no different. Having followed the steps, the last step always only offer me to install “Urtext”, not “UrtextSublime” and if I do that there will be zero entries with “Urtext“ in the command palette afterwards.
I will be happy to try the `sublime_urtext_installer.py` road, but I simply don't know what to do with that file.
Cheers.
See, _that_ solution was much better! Unzip, restart, command palette — and there it is! Thanks!
I then scroll down to try find something to read/look at that makes sense. I am met with two bits of information
"just download it to get started"
and
"it's a plain text editor that does stuff many tools you already have do"
So far, things aren't great. Lets look at the demo project, maybe that has some screenshots that really highight it's potential.
"Download the software and just import the demo project"
So, over all, the impression one is left me with is a "just trust me bro, please bro, it's really useful bro, just install it, I swear" kind of message. Personally, I am not just unconvinced by actively wary of this project.
it must be obvious for its creators, but presents quite a wall of features for others to join in.
We can make some more example projects available, will do it shortly. Thanks for the suggestion.
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.
Why not a directory tree of plain text files?
One tool which did this is Tombo:
https://openhub.net/p/p_7697
(unfortunately, the actual page for this is down --- did it make it to Github?)
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.
I enjoy and appreciate projects like this, I _WANT_ to like and understand it, but as it stands the information simply isn't there.
This is not a markup format, like markdown proper is, not likr org-mode-as-a-lib with a text format to match.
There are also plenty of "special formats" out there that are really just zipping up a directory tree of something simpler.