[HN Gopher] Urtext: The Python plaintext library for people who'...
___________________________________________________________________
Urtext: The Python plaintext library for people who've tried
everything else
Author : nbeversluis
Score : 94 points
Date : 2025-05-01 09:27 UTC (4 days ago)
(HTM) web link (urtext.co)
(TXT) w3m dump (urtext.co)
| nbeversluis wrote:
| Urtext /'Urtekst/ 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.
| pvonmalt wrote:
| I've been using urtext as a "Second Brain" for several years now
| and love it. Miles beyond any other personal knowledge and notes
| system.
|
| Simply 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.
| bomewish wrote:
| Odd they don't use the sublime package system, given that it is
| a sublime plugin. Can't figure that one out.
| junipertea wrote:
| 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
| lynx97 wrote:
| Just took a very quick look... Am I right that this plaintext
| system requires a GUI editor to be used at all? No Emacs/VIM
| support?
| nbeversluis wrote:
| 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.
| digdugdirk wrote:
| 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.
| _ZeD_ wrote:
| Isn't this like leo[0]?
|
| -- https://leo-editor.github.io/leo-editor/
| deknos wrote:
| i just wish, somebody would ratify something like asciidoc+zim-
| wiki as a document format .. and include proper citing (like in
| emails).
|
| Than all this code+program+data could be decoupled.
| smaudet wrote:
| I use zim/markdown too, asciidoc is nice(r).
|
| 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...
| wangii wrote:
| could anyone give one sentence pitch why it's better than
| markdown files?
| shakna wrote:
| It's not quite in the same realm of use. The urtext files are
| more aware of other files, but they're also self-modifying.
|
| Sort of like comparing plain HTML to PHP. Appear in similar
| places, with completely different guarantees.
| codethief wrote:
| Took me a while to understand what this is about - the website
| calls it a "library" but shows a GUI(?!) As far as I understand
| it is: - a plaintext file format (.urtext),
| - a Python library to parse & manipulate said file format,
| - a SublimeText plugin, - a GUI for visualization.
| nbeversluis wrote:
| 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.
| nathan_compton wrote:
| Seems like a very concise pitch would be "org-mode for
| Sublime" and that would explain it adequately for most emacs
| users.
| cbarrick wrote:
| 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.
| zahlman wrote:
| I've heard of it many times, but have basically no
| conception of what it actually _is_.
| codethief wrote:
| It's a file format / markup language (think Markdown but
| more feature-rich) with excellent editor support in
| Emacs.
| coldtea wrote:
| That's like describing a swiss army knife as a "beer
| opener"
| slooonz wrote:
| > 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 ?
| em-bee wrote:
| 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.
| nottorp wrote:
| 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".
| zahlman wrote:
| 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.
| nobodywillobsrv wrote:
| Is urltext a bit like what tiddlywiki was back in the day?
| alpaca128 wrote:
| What makes this so special for people who've tried everything
| else?
| kookamamie wrote:
| > The Python plaintext library
|
| 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?
| MitPitt wrote:
| markdown and markup languages are plaintext
| Retr0id wrote:
| By that logic, aren't almost all languages plaintext?
| bmn__ wrote:
| Yes, this is nonsensical or contradictory because GP is not
| aware of the correct definition.
|
| https://news.ycombinator.com/item?id=28105868
| betterThanTexas wrote:
| > Plain text: text without mark-up
|
| 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.
| pixl97 wrote:
| Yep, I call it the notepad/nano rule.
|
| 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.
| cgriswald wrote:
| 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]
|
| [0] - https://en.wiktionary.org/wiki/plain_text
| PhunkyPhil wrote:
| 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.
| jerf wrote:
| 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.
| betterThanTexas wrote:
| As opposed to what? A pdf?
| labrador wrote:
| "There are only two hard things in Computer Science: cache
| invalidation and naming things"
| detaro wrote:
| "... and off-by-one errors"
| greensh wrote:
| thats just off by one
| kseistrup wrote:
| 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).
| briffid wrote:
| The website frustratingly assumes 4K display?
| bmn__ wrote:
| What gives you the idea? Works fine in width 422px.
| wizzard0 wrote:
| this is all very cool, but what it does sorely miss is usage
| examples.
|
| it must be obvious for its creators, but presents quite a wall of
| features for others to join in.
| nbeversluis wrote:
| There is a "starter project" with self-documenting examples
| that can be created from the Sublime Text command palette:
| https://urtext.co/setup/starter-project/
|
| We can make some more example projects available, will do it
| shortly. Thanks for the suggestion.
| em-bee wrote:
| i'd like to see examples before i install something.
| skeledrew wrote:
| This sounds like an editor for org-mode with native Python block
| execution support. Is it?
| WillAdams wrote:
| Why a special format?
|
| 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?)
| DocTomoe wrote:
| Why not markdown? What does urtext bring to the table markdown
| doesn't?
| coldtea wrote:
| All the things shown in the intro page
| zahlman wrote:
| 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.
___________________________________________________________________
(page generated 2025-05-05 23:01 UTC)