[HN Gopher] TextBundle
___________________________________________________________________
TextBundle
Author : Tomte
Score : 44 points
Date : 2024-08-23 13:06 UTC (9 hours ago)
(HTM) web link (textbundle.org)
(TXT) w3m dump (textbundle.org)
| simonw wrote:
| Something that isn't clear to me from this spec
| http://textbundle.org/spec/ is the exact format of Markdown that
| should be used here.
|
| I was under the impression that the Gruber original at
| https://daringfireball.net/projects/markdown/ wasn't well enough
| specified (unless you want to treat a 20 year old Perl script as
| a specification) to be interoperable - hence efforts like
| https://commonmark.org/
| ibash wrote:
| It's any text based format, you specify the type in info.json
| kemayo wrote:
| There's a "type" field in the spec, defined as: "The UTI of the
| text.* file. E.g. set to net.daringfireball.markdown for
| Markdown. This field should default to
| net.daringfireball.markdown to be backwards-compatible with
| version 1."
|
| So it's whatever you care to specify. Doesn't have to be
| Markdown at all. It looks like it'd be completely valid to use
| this as a way to bundle up a webpage with all associated images
| and scripts, for instance.
| simonw wrote:
| But what does "net.daringfireball.markdown" mean? Does it
| mean "parse it using the 1.0.1 Perl script from 2004 on
| https://daringfireball.net/projects/markdown/ "?
| jagged-chisel wrote:
| It just means "the description written by Gruber at his
| domain." The Perl script is just a convenience (if one can
| call Perl convenient...) for the curious.
|
| Anyone else's flavor of Markdown can be used by specifying
| its identifier, e.g. "com.github.markdown.v3" (I made that
| up, it's not a real thing AFAIK)
| simonw wrote:
| I don't think the Gruber definition is specific enough
| for a spec like TextBundle that's meant to be
| interoperable between different applications.
| pfix wrote:
| Coming from Linux where your Filesystem is your database and I
| use obsidian because I can pop it over a file tree and have my
| vault integrated into the rest of my system, something like
| textbundle seems like alien and missing the point.
|
| I like the general concept of sandboxing applications, but if it
| leads to this, it's more hindering than helping.
| ibash wrote:
| How do you handle attachments?
|
| In particular, if you attach a file to a note in obsidian then
| no other program can link to the right attachment, right?
| paxys wrote:
| There are no "attachments", just files and links.
|
| Your directory has note.md and image.jpg. The note has a link
| to the image. The client can then render the markdown and
| image as it wants.
|
| Any other application can also find and link to the
| attachment because...it's a file.
| vundercind wrote:
| Obsidian may avoid the problem well enough, but it's been
| my experience that connected pieces of information that
| aren't coupled _very_ tightly indeed have a way of
| eventually becoming separated and never re-united. Goes for
| information in computer systems and for physical records
| /photos/objects.
| ibash wrote:
| That's what I meant. My experience is that if I link notes
| in obsidian I can't read it in any other text editor. And
| the opposite.
|
| Most recently I tested this with obsidian, ia writer,
| obsidian.nvim, fsnotes, and a few others I forget the name
| of.
|
| Especially if you want to access your notes on mobile and
| have a good syncing experience... you're out of luck if you
| want a non-proprietary format. Only notion and apple notes
| had reliable syncing.
| xenodium wrote:
| Relying on markdown links to local images works well on my
| machine, but breaks as soon as I'd like to share that markdown
| file with someone else.
|
| Sure, I can zip everything and send them over, but it's not as
| friendly for recepient as receiving a document handled by
| popular viewers, specially if they have to modify it and send
| it back.
|
| With wide adoption of something like TextBundle, we get to have
| our cake (keep using plain text) and eat it too (send, view,
| and edit richer files).
| cspeterson wrote:
| I have in the past run markdown through an exporter that
| base64-encoded the images into the document before sharing
| with someone
|
| solves this one issue at least
| bityard wrote:
| Reading the site and spec, it sounds like TextBundle is
| specifically for exporting and importing your Markdown (or
| other documents) to and from various apps or other users. In
| particular, it's needed for software in the Apple ecosystem
| because there are (apparently) strict rules on how applications
| can communicate with each other.
|
| Personally, I was hoping TextBundle would be something like a
| standard format for inserting binary content into Markdown
| files. (Something better than just base64, anywho.) I could use
| such a thing for my home-grown wiki.
| qskousen wrote:
| If you don't mind, I'm curious what your use case is for
| inserting binary content into a Markdown file?
| Tomte wrote:
| Images are the usual use case.
| nicbou wrote:
| Not sure about the parent commenter, but I am still looking
| for a human-readable format to archive social media posts
| and online conversations.
| jen729w wrote:
| Notably created by Shiny Frog, authors of the very popular
| Bear editor for Apple platforms.
| zokier wrote:
| seems like poor mans odf
| eternityforest wrote:
| So is it just a folder layout that can optionally be zipped?
| What's the actual on disk format? Is it something SyncThing would
| be happy about?
| marcellus23 wrote:
| You can download a sample file. It's a standard macOS package (
| https://developer.apple.com/library/archive/documentation/Co...
| ).
| eternityforest wrote:
| I don't have a MacBook or know anything about how their
| packaging works, but it seems like it's pretty well
| documented, maybe even better than a lot of package formats
| amai wrote:
| Spread the word. Unfortunately Obsidian and Devonthink (and many
| other apps) don't yet support this format. But it solves a really
| important problem: How to exchange markdown documents that
| include attachments like images, video etc. in a standard way?
| rauhl wrote:
| > But it solves a really important problem: How to exchange
| markdown documents that include attachments like images, video
| etc. in a standard way?
|
| Oddly enough, I was recently thinking of using RFC 822 messages
| with CommonMark bodies and MIME attachments as a way to store
| blog entries on disk, so I was considering this exact problem
| earlier this week (small world!). RFC 2046 specifies multipart
| messages, RFC 2392 specifies URI schemes for linking from the
| body of the message to other parts; and RFC 7763 specifies the
| text/markdown MIME type. There's already a ton of tooling out
| there which deals with MIME, so one needn't reinvent the wheel.
| amai wrote:
| Interesting idea. Actually I wonder why we don't have
| Markdown in emails, yet. It seems to be an obvious idea.
| vunderba wrote:
| _TextBundle brings convenience back - by bundling the Markdown
| text and all referenced images into a single file_
|
| ... So basically a markdown version of the ePub format?
|
| Slightly related, but Typora offers an option that handles
| inlined media for a markdown note in a pretty sleek way. It
| creates a folder in the same location as the markdown note with
| following syntax (markdown-file-name.assets). Any time you
| drag/copy/etc a image/video/etc into the markdown editor it
| copies the file into the asset folder.
| w10-1 wrote:
| Unchanged since 2014?
|
| Surely with Pandoc and macOS/iOS progressing relentlessly, there
| would be some technical advances even in a basic file bundle.
| maliker wrote:
| I spent a lot of time investigating all the editors on this list
| because I want a rich text editor that works with single files
| and is as clean powerful as VS Code (or sublime, emacs, whatever
| you prefer). Didn't end up using any of them since nobody else
| uses this format. Went back to .docx. Sad.
___________________________________________________________________
(page generated 2024-08-23 23:01 UTC)