FoldingText next steps, looking for feedback

1

Continuing the discussion from TaskPaper vs. Folding Text vs. FoldingText Atom:

So far my plan had been for FoldingText for Atom to eventually replace the current FoldingText 2.0. But most of the feedback from existing FoldingText 2.0 customers has been similar to yours and so I’ve been trying to come up with a solution.

The original goal for FoldingText (the current 2.0 version) is “plain text productivity”. And outline of plain text on which specialized behavior can be hung: timers, todo lists, etc.

As discussed elsewhere I’m not longer convinced that it’s an achievable goal, at least not achievable in a way that I’d like. Todo lists work pretty well, the timer mode is interesting and solves a particular problem that I had, but I’m not certain how generally useful it is. Encoding dates and times got messy quickly and so I sorta ran into a wall. In general I think the plain text constraint is adding more complexity to the environment then it’s solving.

If I decide to continue the current FoldingText 2.0 plain text direction where do you think it should head in the future? Is the primary value in clean Markdown editing and folding or something else?

2

Given the existing appetite (expressed in this forum) for things like cross-file (or project folder) search and perspectives, my personal guess would be to enable a fully-functioning FT2/Markdown mode of FT3, transparently opening and saving as MD files.

I think that should enable FT2 MD users to continue existing workflows and tagging idioms without disruption, while also enjoying the benefits of Atom’s Tree View, and of any perspectives (and other plugins) developed for the platform.

It might also provide an enhanced but secure and familiar base from which to venture into and explore additional capacities and applications as they emerge in FT3.

Rob

3

I use Folding Text 2.0 customers for my “context” for the current programming task that I’m working on. This means that it ends up being an ad-hoc set of todos (“now”, “eventually”, etc.), as well as local reference info I need, like:

  • http links to specific pages
  • snippets of shell commands I’m using often
  • copy/paste of code snippets relevant to my current task.

If Folding Text 2.0 went away, I think I’d switch to writing Markdown files with vim. What I like about Folding Text 2.0 over that approach is:

  • inline Markdown formatting of headers, hyperlinks, bullets, code
  • todo syntax (I use the ⌘' shortcut to mark things as done)
  • header folding
4

Sounds interesting – but I’m being slow … tell me more about what you mean by ‘customers’ in line 1 ?

Quick thoughts:

  • The [headers, hyperlinks, bullets, code] and the saving and reading of .md files are all there in the more format-agnostic FT 3
  • todo, done and header-folding also.
  • What the use of editable HTML outlines as the native format adds to this begins today with live and durable links both within and between documents at the granularity of individual lines …

Jesse has just released the very first first build that does this, and I’m finding it quite extraordinary … Suddenly my folders of text notes and outlines are linking line to line, across file and folder borders, and beginning to look, at the very least, like a wiki …

( and the links are made by simple drag and drop, and in an absolutely standard existing text format, which is quickly editable and interchangeable, when required, with all the other note and outline formats … )

5

As long as I can not sync via Dropbox and Editorial (or any other text editor - and NOT a special opml-thing I don’t need - it’s useless for me

6

You do seem very confused. I bought into the plain text productivity thing and enjoy the UI - markdown editing with instant rendering (rather than the side-by-side approach of other md editors) is nice - more of it would be nicer.

I use atom for coding, but I’m not sure what folding text is doing in there or why I’d want it and I don’t want to have to pay yet again (I used to use TaskPaper)

moving between OSx and iOS is essential for me - having lost the iOS version of task paper I now use Listacular which is a great replacement and works with TP files as does Folding Text, mostly.

Less can be more - it could be that you need to decide what product you are developing and do that one thing with full dedication and talk about it clearly and concistently.

7

I’m just very casually trying FTA out from time to time and I admit I haven’t looked into this a lot, but how does this work without the copying and pasting markdown commands? I can’t see where I can export an outline to plain text/markdown, and regular .md text files open in regular Atom.

8

That’s right – the current, quite early, draft of Markdown mode uses the copy/paste interface, but file Save/Open for each mode is part of the format-agnostic model, and will clearly be there in later builds.

( For the moment I have sketched my own versions )

9

Alright, thank you for the reply.

10

Jesse, thanks for your ongoing work.

I use FoldingText as my to-do list. I might be able to do it with TaskPaper, but I’m not sure TP has the filtering specificity I need. The ability to hide all unstarted tasks and their children, only show items due this week, etc. is killer. I love it.

The other thing I really like about FT & TP is the power of plain text. It’s greppable, linkable, totally navigable by keyboard, and a cinch to automate. My FoldingText setup is just as powerful as Omnifocus and about 10% as complex.

I would hate to use any other system. I don’t totally understand the FoldingText debates here and the de/merits of Atom, but I hope that wherever you take these projects, the plain-text productivity features (with due dates and filtering) live on in either TP or FT.

11

It’s greppable, linkable, totally navigable by keyboard, and a cinch to automate.

Absolutely, and perhaps we do all confuse ourselves just a little bit with this term plain text – Markdown is useful precisely because it isn’t plain – it’s very usefully marked up to indicate quotes, comments, heading bullets, links and all the rest of it.

Jesse’s editable HTML text files are:

  • still text files,
  • and still greppable
$ grep -A 1 waiting *.ftml

( and Atom ⌘⇧ F Project Find does the same with helpful UI and links back to the files )

  • in addition, they are even more filterable (all the standard XQuery and XPath tools work directly with their outline structure)
  • and much more powerfully linkable (permanent line ids, even after edits)

We’ve always quietly used HTML files at a certain stage of our nominally ‘plain’ text workflows, but in the past they weren’t editable or foldably outline structured. Now they are …

I think the FT3 HTML editing is really excellent core technology, and one which can support not only Markdown Mode, but OPML Mode and really any other text markup mode that we want.

Above all, it allows durable and edit-resistant wiki-like links within and across all our note folders, and much better linking back from automatically filtering perspectives.

I personally think it’s a huge step forward.

12

Whew! I’m relieved—and excited to see how it shapes up!

13

Regarding plain text, while I’m attached to the idea and in theory like the notion of “usable anywhere”, in practice I didn’t find using TP or FT with other apps very useful unless they were designed to process and display the syntax properly (Editorial for iOS or Sublime Text with PlainTasks, for example).

So FoldingText moving to a markup syntax (while technically still being a plain text file, just with tags) won’t really impact me and it looks like there will be other benefits to gain with this move.

Right now I’m not using FT3 (or FTA…however we’re calling it) in the same way I used FT2. FT2 was basically a text editor for me that I could insert lists and tasks if needed (I only used the hashmarks as tags for folding…rarely did I use them as an outlining component). FT3 I’m using much more as an outliner and project management/planning.

Technically I think I can do a lot of what I was using FT2 for in FT3, however the display and interface in FT2 feels better for general writing. Maybe they should be considered separate products? One a Markdown editor with folding and some basic plugin capabilities and FT3 being much more focused on productivity and management?

14

I’m using folding text as a combination markdown editor and task list (it could almost be replaced with think github markdown but I think Folding text’s style is a bit easier to use ). I was using TaskPaper in roughly the same way but FoldingText has allowed me to do much more of the notes side of things. So FoldingText was a great natural fit.

Since i need this cross platform (OSX, Linux, Android possibly Windows) the roughly standardized Markdown/CommonMark is a great win since I can find an alternative editor when I’m not on my Mac. If FoldingText went to a more proprietary format I would probably have to find a new editor :(.

15

I don’t think you need worry too much about that – FT3 (like iOS Editorial) will have various modes, including CommonMark. It’s native format is just a standard HTML5 unordered outline – about as far from proprietary as you can get : - )

(You can even open and edit an .ftml file in MS Word, if you really want to – more than you can do with CommonMark.

(unless you want to manually fiddle with converting all of CommonMark’s particular hashes, asterisk emphases, and various link representation conventions )

16

But, the whole point is IMO that while Markdown is a markup language, it’s still human-readable in its …plain text form and thus bomb-proof, which you can’t say about something like OPML.

(Case in point: because of a hardware malfunction I was recently forced to use my old 32-bit laptop which runs Snow Leopard at best and for which compatible software is hard to find.)

Of course, because, as you’ve said, FT3 will read and save Markdown without having to import/export, that is not an obstacle, because it’s besides the point for me what happens behind the scenes.

17

the whole point is IMO that while Markdown is a markup language, it’s still human-readable in its …plain text form and thus bomb-proof, which you can’t say about something like OPML.

Of course, that’s fair enough and viewing OPML does need a specialised editor to make it cleanly viewable (tho its not entirely unreadable to the human eye, and as a an XML markup, its very quickly converted into other forms by universally available tools, for example in browsers).

<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
  <head>
    <title>Untitled</title>
    <expansionState>0</expansionState>
  </head>
  <body>
    <outline text="HTML outlines work better than OPML">
      <outline text="OPML requires a specialised editor"/>
      <outline text="It does not encode bold, italic or underline at all"/>
      <outline text="HTML outlines, on the other hand, can be displayed any browser, and with any inline formatting supported by HTML5"/>
    </outline>
  </body>
</opml>

FT3’s HTML, however, can be viewed clearly and directly, without markup noise, on any platform by any browser.

You can also open it directly and edit the outline in anything like MS Word and its various Open Office counterparts.

FT3 file opened in Word:

Followed by equivalent MD file opened in Word (no underline, and some MD clutter to be dealt with).

(And, of course, on OS X, you can instatly preview a standard HTML outline (as used by FT3) with Quicklook)

And finally, like OPML, FT3’s HTML can use all of the standard and universally available tools which read and transform XML-type markups.

Perhaps worth reading Brett Terpstra’s overview of differing levels of markup in plain text – he tends to spend most his time in Markdown or Mindmaps at the moment, but he also likes Day One’s XML markup, and his comment on variable levels of markup in plain text is:

XML and OPML are (to me) perfectly valid ways to make plain text into something easier to work with programatically.

Standard HTML outlines have these advantages, but also all those of standard browser technology too. FT3 makes them directly editable, while also allowing for modes in which you work with CommonMark, OPML or whatever other plain text markup happens to suit your work, aesthetics and exchanges with others.

18

It’s the outlining that is at issue from my point of view, it’s nice to demonstrate readability of OPML, but this is not the sort of data-structure I had in mind. I currently use Folding Text as a sort of project planning tool, the tagging and check-boxes are important to me, but so are the ability to add @notes, bold headings and only slightly rearrange items. I am moving away from markdown approaches for managing tasks themselves, mainly the problem with cross-platform syncing, I won’t go into that.

As you say cross-document links have not worked very well with the markdown approach so I never really tried using them. I generally have a phobia of my file-system being used in this way, you need highly tuned search skills to be able to make it work, something I have not had the time to build-up.

19

Early days and an early beta, especially of the Markdown mode. Probably best to let it evolve a bit before deciding to what extent it might or might not help your workflows.

( Personally not sure that I really feel that drag and drop links do require very highly-tuned search skills to make use of – but mileage does vary, and choosing the best tool for the job is usually better than the converse : - )

20

Sorry, I replied to the other thread, not realizing that it continued here. I’m going to post again here:

I’ve bought WriteRoom, Taskpaper, and FoldingText. I really like the current dev version (741) of folding text and would rather see this release continue. I especially like the various modes and use all three (todo, schedule and calc). I get the whole HTML discussion, but I feel more comfortable with plain text. Now I guess if Jesse could give me a writeroom experience (I miss session counters a lot) so that I could organize, brainstorm and write in a single app, that would be interesting.