On reflection I think this clearly opens up the best of both worlds.
In traditional plain text workflows, HTML has always been a decorative dead-end.
Editable HTML outlines, with full and fast round trip conversion of tag information and line types ⇄ Markdown outlines, gives us direct access not just to MD and plain text tools, but to XML querying and formatting tools as well.
Glad to hear you’re still going strong on the FoldingText project. I very much like the sound of the new direction you’re taking. While the Markdown-based model of the current version is conceptually interesting (and very useful), I do see how there were some very difficult problems inherent in that model. In any case, you’ve made a great effort of it!
Making the new document format valid HTML is a very smart idea. I’ve increasingly felt that HTML may be the format to centralize on for post-Microsoft-Word documents. RTF is messy; Markdown feels uncomfortable to many people as a “final” document format. HTML is pervasive: as you mention, it can be opened in a web browser, and posted directly to a web site. It’s very surprising to me that there aren’t very many simple HTML-based rich-text editors (aside from those CMS editing interfaces).
While I use the current version of FoldingText daily, I’ve been a bit hesitant to recommend it to less tech-savvy users. A rich-text editing interface would, I think, greatly expand the potential audience for the app.
Looking forward to hearing (and seeing) more about this new version!
Jesse, your new approach sounds both logical and very exciting. I look forward to using the next version of Foldingtext.
For those who are addicted to keeping all (or most) files as plain text (not necessarily Markdown), do you have any plans to keep Taskpaper (which I use every day and still love) alive?
Regards.
m
Yes… often when I say “FoldingText” I really mean the bigger idea (and the underlying text editing engine) that I’ve been working on since TaskPaper. I’ve always intended to use the FoldingText engine in the next version of TaskPaper, so all changes mentioned here also apply to TaskPaper.
And for TaskPaper in particular I do think some sort of easy plain text round tripping is important since lots of other apps rely on TaskPaper plain text.
If I understand this correctly, the plan is to move away not only from Markdown, but also to move away from storing things in and parsing plain text?
I don’t care about Markdown specifically that much, but personally, I’m not interested in a program for note taking and basic writing where I have to export files to make them readable in any text editor.
Of course, as you say, even if it’s plain text, certain features may be »locked« to the program, but I think the chances are higher that those features will be picked up by others if it’s just plain text.
For example, Editorial on iOS has supported highlighting plain text lists saved as *.taskpaper via tags for a while, whereas a mobile FoldingText app seems to be way off in the future.
Programs come and go, and it’s why I will never again use a note taking app that uses a complicated file format, proprietary or not. Eventually, they all get abandoned and die. 
Hey Daniel— like you, my workflow benefits greatly from syncing plain text files between devices via Dropbox, and if I thought that would be compromised in any way, I’d be a little worried. But Jesse’s post above gives me hope that the experience of using plain text with the new update will (eventually?) be pretty much seamless:
Thanks JSLR – I guess I’ll just see what time brings.
I wouldn’t worry too much on that score – there’s actually a continuous spectrum of text file formats, without any real and clear breaks, and while Markdown is less marked than HTML, it’s (fortunately) not really unmarked ‘plain’ text and it would be much less useful if it were : - )
Jesse’s small shift along the text file spectrum towards slightly more marked text files preserves human legibility and wide usability, and is much more fit for the purposes of text outlining, text tagging and text linking.
Unlike OPML it’s directly displayable by any browser, and I have already drafted a couple of scripts to experiment with converting MD ⇆ Jesse’s very simple HTML outline format . Easy to write and fast to run – so fast that it would be possible to use the new version in a mode which transparently read from and wrote to MD – particularly if you didn’t want the advantages like permanent link targets and solid outlining, and can put up with the fiddle and ambiguity of alternating between hash levels and unordered list levels, and changing your mind about which is which, and what is a child or parent of what :- )
So I guess I really did misunderstand? Interested to see what will come. Thanks, Complexpoint.
I find it disappointing that FoldingText is taking this change of direction. The application as it stands fulfills a specific requirement of my daily routine as an excellent Markdown editor with programmatic extensibility.
My workflow syncs the FoldingText files I write to OwnCloud, where if need be, I can edit them online with a markdown plugin. Changing the native format so that the rich content/metadata is outside of what is visible negates this tool’s utility for me. Importing/Exporting may be possible, but it seems like specific filters would need to be written for import and export of any add-on tools that would write the metadata that make the tool useful to me. This seems tedious from a programming perspective, and fragile from a user perspective.
Supposing I have no power to persuade you to revert this course - since you’ve already been working on it for months without any mention of the intent to do so - what is the possibility of continued support of FoldingText as it stands as a separate, useful application? At the very least, finally release 2.0 out of dev and call it done forever?
Don’t forget that you will be able to use the new editor in a Markdown authoring mode if you choose to, and that the metadata will be visible, editable, and used by stylesheets.
Still MD in and MD out if you prefer, or whenever that works best.
The in-editor representation as an HTML unordered list does bring some advantages (full accessibility to OS X’s built in XPath and XQuery, persistent line ids etc) but you don’t have to use it as your default serialisation if you don’t need those.
In addition, the Atom platform brings advantages and depths of its own. Tree View and Search in Project, for example, are like having nvAlt quick search and archive built into the editor, which also has its own MD preview, and in which you can work with text files in any variety of markups.
[quote=“complexpoint, post:16, topic:676, full:true”]
Don’t forget that you will be able to use the new editor in a Markdown authoring mode if you choose to, and that the metadata will be visible, editable, and used by stylesheets.
Still MD in and MD out if you prefer, or whenever that works best.[/quote]
Supposing that a plugin exists to implement the current .todo functionality, would it not need to supply a means to convert the metadata stored in this HTML subset into the @done(date) and other markdown decorations? And also convert it back from that markdown text to the internal format? Would this also be the case for any other plugin - that they would not only have to implement the functionality within the constraints of the new internal structure, but also provide methods to translate bi-directionally between that structure and markdown? I can’t personally conceive of a serializer succeeding in doing this generically, but maybe it’s simpler than I think.
If it’s the case that plugins must include their own metadata serializers for markdown, then it seems unlikely that all plugins will be able to write markdown, meaning that I will be limited to a subset of functionality that supports conversion to markdown, leaving me wondering whether this is the markdown editor I wanted or another custom-format editor focusing on functionality I don’t really need. Ironically, the feature touted most often as FoldingText’s focus around here, folding/outlining, is the feature I find least personal use for.
My bottom line is merely this – I need an editor that:
If this new editor does that, then great. But I suspect it does not, and am curious about the possibility of locking in the current 2.0 featureset as-is so that I can at least maintain that functionality until I find a working replacement, whether it’s the next FoldingText or otherwise.
No – there’s no problem with meta data moving back and forth between HTML5 data- attributes and FT @tags and @key(value) pairs – it’s an automatic one to one mapping.
Take a look the quick scripts which I wrote for FT ⇄ BML (HTML UL) copy/paste and saving
(Jesse is already beginning to build this kind of functionality into the new editor itself).
FT line types and tag/values both automatically become <li> data- attributes, enabling round-tripping by default.
All three of your requirements there - you can opt to load and save in MD, mark a line as header | list | ordered | quote | code etc and see it automatically styled, have automatic behaviour based on key value pairs, entered, if you prefer, in @key(value) style, though the editor will offer faster | simpler routes.
I’m a bit confused. I was looking forward to the demo but I haven’t seen anything appear since the original status update. I did find some references to ‘Birch’ scattered over both here and Jesse’s github account. I haven’t been able to locate the software itself via Atom. How can I take a gander at it?
At the moment I’ve posted a very early version of Birch in a private category here. I’ve limited that catagory just to (level 2) Discourse users… not sure how Discourse calculates it, but means you’ve been here a long time and made lots of posts. Birch isn’t ready for real world use, and trying out the demo will likely use a lot more of your time then it saves. With that said if you have time and are used to using Terminal app and things like that send me a message and I’ll give you access to that category.
What exactly is Birch? Is it the new foundation for FT and TP going forward?
Yes, that’s the goal right now.
Hi Jessie,
Catching up on some of the new developments with Folding Text and Taskpaper direction. I don’t have the Discourse credits for access to Birch but I have the time and terminal experience to contribute if you wouldn’t mind some more input.
/ryan
I’m coming to this subject a little late but I’ve been a user of FT since the original beta of v1 and have at various points along the journey been both frustrated and delighted in equal measure. I used to be far more active on the old forum but since 2.02 have been happy with both FT’s stability and how FT fits into my personal workflow requirements (so I’ve been less active on this new forum).
With regards to Jesses’s announcement regarding the future direction of FT, I think the roadmap Jesses has set out makes sense and the move away from Markdown as a core component of the UX makes sense too. My main frustration with FT was that it promised to be a plain text outlining tool with superior task management features but it always failed to deliver a great outing experience. On that basis I fully back a move to a HTML driven ‘rich text’ core if it helps deliver a more solid outlining experience. To quote Jesse from the FT user guide “I didn’t start this project with the goal of building a Markdown editor. I like working in plain text and just wanted a better place to do that. My goal was plain text productivity!”
However, my biggest concern in this announcement is that there still appears to be no consideration of mobile integration. Many people I know still make use of TaskPaper syntax because applications such as Editorial on IOS work seamlessly with that syntax. It’s great to hear that the new tool will work across Linux and Windows too but mobile integration remains essential for many.
Like many in this forum (I’d hazard a guess), I’ve probably spent too much of my time over the years dabbling with plain text workflows/tools but through that exploration I feel that I now have a portfolio of interlinking tools that work well for me. On the desktop, all my writing start out in MultiMarkdown Composer (which has introduced folding/focus tools in the new v3 beta) but then goes into Ulysses for it’s superior organisation/export capabilities (amongst it’s many other delights). I use Editorial in concert with Ulysses on IOS in much the same manner. For task management, OmniFocus delivers the majority or my ‘macro’ requirements (across desktop and mobile) and this is backed up by individual FT project docs that contain a greater levels of granularity. My FT files are accessible through Editorial on IOS where even though I don’t get access to the focus/folding features of the FT desktop product it’s very easy for me to append/amend my FT files when I only have access to them through a mobile device.
My hope for the future version of FT is that it fits seamlessly into this current workflow approach. The missing link as I see it at the moment is that Editorial will no longer be able to work directly with FT files without some form of roundtrip translation as part of the process and this will be an unwanted complication. I’d suggest that Jesse works with Ole Zorn to enable the forthcoming version of Editorial to work directly with the forthcoming FT format.
In saying all that I’m perfectly happy with the current version of FT and as long as it doesn’t become abandonware (as many of Jesse’s previous products) and is maintained for the ever changing specifications/features of OS X then that’s a workable situation too.
I was editing some stuff again today in FoldingText and I keep forgetting how much I love it, I tried Typed from Real Mac Software but it just not as nice. So I thought I would check the status of FT updates now maybe its late but I am confused a bit with this post. I just need a app with decent word count engine (which can exclude quotes) and lets me write with markdown syntax (for later exporting in other apps (I used Marked2) in plain text format (aka portable / can open in Editorial ios app) etc
So will the new FT (Birch) do this ? I was a little confused with the post!? apologies
also I thought the engine was all being built around the web “app” you where also making ? (cant recall name)
Is there a screencast coming ? I am a long long time user of all hogbay apps and so would be happy to again contribute to testing beta Birch and helping with feedback but I don’t think I have enough Discourse credits ?(whatever they are!)