Better error reporting when loading invalid .ftml files.
Make ‘should’ a dependency so specs run when installing from Atom.io
Fixed bug that could sometimes make escape jump to search field when in text mode.
If you’ve installed using Atom’s UI it should be that you are automatically updated of this release next time you launch Atom, and can update with a single click! Much better then manual downloads the the command line like we used to have to do
Who needs another boring outliner? But I think, in a year or so you will again lose interest and start something completely new. Existing products? Customers? No matter. Good luck, but I finally switched to another solution
After a brief exploration I like what I’m seeing. And I must admit I was initially sceptical as I find Atom to be a very sluggish in comparison to BBedit or Sublime Text. However Atom seems the perfect platform for you to build your vision for FoldingText as a productivity tool. Many of the UX niceties that were taking up so much of your time whilst developing FT 1 & 2 is now taken care of by Atom so you can focus on the productivity features of FT itself.
What’s to like:
It’s simplicity & flexibility
The well documented search syntax
The fluid workflow between text and outline modes
What’s not to like:
It’s no longer plain text
Atom lacks an Applescript dictionary
Tasks don’t have notes at the moment
Default key bindings clash with many of my defaults
Your direction of travel will probably upset a good proportion of your existing customer base as many of them seemed to perceive FT as a Markdown editor with productivity features, whereas you were always designing a productivity tool that happened to make use of Markdown syntax.
The real question I ask myself is whether FT for Atom is something I actually need. I’ve pretty much returned to using TaskPaper formatted text files within BBedit & Sublime Text and am able to edit these using TaskMator and Editorial on IOS (plus I have a huge library of Applescripts for slicing & dicing my TaskPaper files). As I’ve stated many time before, roundtrip data portability (without the need for translation scripts) is essential for the way I work so the FTML data format is a concern at the moment. I’m aware that this is really just a variation on HTML but it’s still a heavier style of markup than TP or Markdown.
In saying all that I can see the potential of the Xpath based search syntax you’re developing, especially for interrogating FT data via scripting.
I look forward to seeing the platform develop in the coming months. And as a side-note, please maintain the already excellent documentation as you go along. This will help your potential customers understand the true value of your vision.
For the next release I’m going to try adding support for other formats, that should allow you to try FoldingText for Atom out without requiring you use it every time.
FTML will still be the “native” one, but I’m pretty sure I can read/write OPML without losing any data, and I can read/write TaskPaper files in a lossy fashion. Some things like unique ID’s will go away on save, but all normal TaskPaper data will be preserved.
This will definitely work for me as I use OmniOutliner on both OS X and IOS. And there are plenty of other low cost alternatives for OPML compliant outlining across all major platforms too so this would seem a great integration strategy, especially if everything remains lossless whilst round-tripping.
I agree with you. In fact, it was very depressed when I tried foldingtext for atom, completely different from when I first tried foldingtext 2.0. I have bought omnioutliner 4.0 but abandoned it and chose foldingtext 2.0 as my outline tool. Why I have to go back? Is foldingtext for atom superior to omnioutliner?
I love the foldingtext 2.0 because I love the freedom of markdown with the addon of outliner, not outliner itself.
Atom is very slow indeed and consumes too much resources because it’s based on Chromium.
When I open a blank page, maybe I just want write down something and reorganize later (or not). That’s why I prefer foldingtext 2.0 to omnioutliner. I can’t do it in foldingtext for Atom too.
I hate the special .ft or .ftml, you know why. Yes, I can transform it, but I hate having to do it.
The prefix in front of each line in foldingtext for Atom is very distracting when editing.
When editing in foldingtext 2.0 I could see what it’s look like without preview: header/indent/…
I love the freedom when edit in foldingtext 2.0. If I want to write something as note, I just write it down; If I want some blank area, I just leave one or two blank lines. I can’t do it in foldingtext for Atom.
Agreed. It would appear that we cannot even get a development version with the expiration notice removed, or get the last development version uploaded to the app store. However, you can still buy the dead-end FT 2.0 in the app store for $30.
As a very devoted FT 2.0 user, and with the gigantic caveat that I only discovered FT for Atom’s existence yesterday and have not had a chance to try it yet, my initial reaction to reading about it is similar to @kinghenry’s. I just want to put a stake down here, and I will definitely bring back some concrete feedback when I have tried the new version out, but:
One thing I love about FT2 is that I don’t have to know the full outline structure when I’m working. I can dump a paragraph or two of plain text into my document, breaking up the outline structure, and easily come back to it (its “unformattedness” makes it easy to find) to impose structure on it later. Flexibility like this has made FT basically my perfect tool for taking notes and for working out problems, and I’ve come to rely on that. So far it doesn’t sound like that’s going to be possible in FT for Atom.
Similarly, the native Markdown roots — plain text under the hood — have made it basically friction-free, both in loose stream-of-consciousness notetaking and in moving stuff in and out. Even with Markdown import/export, I think I’ll miss the loose structure.
Finally, I think the FT GUI is a gem. Its clarity for navigating and viewing files is unmatched. I hope it will be largely recreated in Atom but I don’t know if that will be possible.
Again, just my initial reaction. Will bring back more when I have time to look at the new build, but that may not be till after WWDC.
By the way, rather than be entirely the obnoxious user who reflexively hates change, let me add that I see some exciting developments here as well — the filtering by status and tag looks like a vehicle for some really nifty workflow improvements. I am looking forward to trying those out and seeing what else is new.
I agree this is an issue that needs to be improved and I see it improving in two ways.
First Atom is continuing to get faster, it’s much faster then when I started using it. And it’s got a big company behind it who very much wants to make it faster still.
Second once FoldingText for Atom gets to a point (could take some time) where it’s ready for general consumption I expect to pull it out into its own app. I will still offer the FoldingText for Atom version for hackers and tinkerers, but I’ll also offer a standalone “FoldingText” version.
I think this standalone version can be made quite a bit faster as I’ll be able to take out many Atom features that I’m not using and can optimize how files are loaded because I wont need to support the dynamic package environment that Atom supports.
I’m not sure I understand. This is exactly the way that I use FoldingText for Atom. I write a bunch of random thoughts without any organization, then I go back and create some structure as needed. Maybe you mean that the “oultine look” makes you feel like you are supposed to be creating a fully formatted outline to start with?
For the next 0.2.0 release I’m making an API so that file formats are pluggable. My goal is to support OPML, but I’ll also try to support saving/reading simple plain text (.txt) outlines.
I think showing those triangles is a good default. It allows new users to discover how to expand and collapse items and it makes it easy to drag and drop items. But once you know how those things work you can hide those triangle in a number of ways using your Atom > Open Your Stylesheet
In this case I’ve hidden the triangles except for items that have children. If you wanted to go further you could hide for all items except those that have children and are collapsed. Or hide them all together and indicate that there are collapsed children through some other means, such as bolding the text of headings that have children.
I’m not sure I understand what you mean in this case.
I’m pretty sure you can get this seem feel in FoldingText for Atom, with maybe a few more changes on my end. I think the above style rules will help some? I guess try them and then let me know what other aspects feel constraining.
I think the only fundamental/irreversible change that FoldingText for Atom makes is that it doesn’t create structure based on syntax highlighting. So to add a link or bold some text you’ll need to use a keyboard shortcut instead of type in syntax.
Besides that change I don’t think there’s any FoldingText 2.0 behavior that can’t be replicated (with maybe some extra coding on my part) in FoldingText for Atom. In the end it’s all just a bunch of keybindings and an outline structure, same as FoldingText 2.0.
Is it possible to quantify specific cases where FoldingText 2.0 feels more flexible? Ie this is how it worked in 2.0 but it doesn’t work like that in the new version and this is the exact behavior that causes the problem?
Again it’s hard for me to quantify “loose structure” but maybe these are some examples of what you mean?
In a plain text editor you can hit tab and indent a line as many times as you want. In most outliners you can’t “over indent” this way because it breaks out of the outline structure.
In a plain text editor when you move a line up it doesn’t bring “child” lines with it. But in an outliner it does.
If those are the types of things that are problematic I think they could be addressed. Maybe in text editing mode the move commands work like a plain text editor… only moving the current line of text. But in outline mode it would work like it works now, effecting the entire outline structure?
One of the biggest issues that I have with FoldingText 2.0 (and markdown in general) is how unclear the basic document structure is… especially when you get 4 or 5 levels deep the syntax for all the “####” makes those items stand out more then top level headers. For my use FoldingText for Atom’s plain outline structure is much better for this.
As far as the other UI aspects of FoldingText 2.0 I think they can be pretty easily reproduced. Things like the jump to heading menu, etc. Again if you can give specific differences that always helps.
Thanks to both your and @kinghenry for this feedback and hopefully more in the future. FoldingText for Atom isn’t 1.0 yet because it’s still a work in progress. Maybe it’s not the solution that you want in the end, but I think it’s actually a lot closer to FoldingText 2.0 then you might think. You feedback now will determine where it ends up.
What I gather is that a vocal part of the user base is very fond of the markdown capabilities of FT 2.0. I am personally also very keen on a workflow that allows me to outline and to use a ‘make’ and ‘pandoc’ workflow where needed. However, I did have some issues with FT 2.0 regarding the actual outlining/nesting performance. I absolutely think that FT4Atom is far clearer in many aspects in this.
I’m not sure how far you should try to make FT4A resemble FT 2.0, but I do think that a good (commonmark or pandoc) markdown implementation in a package would placate many. The ability to read and write to .md or .txt and easily switch between markdown formatting and ‘nothing’ would be very useful.
Although I can understand that implementation might become horrible again as soon as you want to make it even remotely ‘smart’ One thing that would be enormously useful is if in the markdown package a second level header would automatically be demoted. so
# header 1
# header 2
# header 1
## header 2
I’d consider a paragraph to be the child of the title preceding it so a second level heading would be a sibling to the preceding paragraph
# header 1
## header 2 (sibling)
One way I think FT4A shows much improvement is that I can easily indicate whether text belongs to the previous bullet point or not.
Also I am very trained in the FT2.0 way of doing this. so I keep trying to move lines upward and downward with the familiar keystrokes. There doesn’t seem a clear way of doing this in FT4A except for cutting and pasting. Maybe bindings are clashing again because I can’t seem to make the ‘atom way’ work. Am I missing something?
It’s not yet a solution (and right now I’m spending most of my time on the core outliner), but you can try it out to see how I think markdown will fit into FoldingText for Atom.
If I understand your correctly that’s how the foldingtext-markdown package now works. To get a better idea install that package and then use the command “FoldingText Markdown: Paste Markdown” to paste this text into an outline:
# Hello world
Look _it_ **has** `formatting` and [links](http://www.foldingtext.com)!
## Bullet lists
## Ordered lists
## Code Blocks
## Block Quotes
Note that in the styling for that package the leading triangles are currently hidden. So when you paste in you’ll see only the top level heading… expand that (and the other headings) with keyboard shortcut (or just click space to the left where triangle would normally show) to see contents.
This should be working, but the keyboard shortcuts are different, I’m using Atom’s same shortcut for moving lines of text up and down.
Command-Control-Up - Move items up
Command-Control-Down - Move items down
Command-Control-Left - Move items left
Command-Control-Right - Move items right
In Atom you can find/discover keyboard shortcuts by:
Looking in the Command Pallet (Command-Shift-P to show it)
Go into Atom > Preferences and click the “Keybindings” panel for a comprehensive list.
Jesse: Thanks for taking my feedback (and @kinghenry’s) seriously even though (in my case) it’s premature! I’m definitely looking forward to trying out the new version and I’m very willing to be convinced. Your points about the weaknesses of Markdown structure are spot on, of course; the looseness I referred to was mostly about the ability to drop out of outlining “mode” (or mindset, if you prefer) into plain text paragraphs when needed, either to get a bunch of unorganized stuff down quickly (to be organized later) or to annotate things.
In any case, I’m encouraged by your responses. I’ll hold any further feedback until I’ve seen the thing and can be more specific. Thank you, both for the dialogue and for FoldingText in the first place. It’s become one of my most fundamental tools for getting my work done, and it’s had an almost transformative effect for me.
I just tried FoldingText for Atom (and Atom editor itself). I must say that wow, Jesse, this is exactly what I personally need. At home, I use Macs and all this productivity related stuff - nvALT, Markdown, OmniFocus and so on. However, unfortunately I have to use Windows at work which is where I spend most of my days at doing any productive work. I’ve tried to replicate some of my Mac workflows with Sublime Text and some of its plugins, such PlainTasks plugin, Markdown plugin, etc.
I also have the original Folding Text on my Mac. I like many ideas in it, but in the end I felt it didn’t work well enough for the ease of outlining compared to OmniOutliner. I have bought OmniOutliner and I like very much how you can intend/outdent with tabs, drag topics around and so on. Unfortunately I don’t have much of a change to use it because I need to work in Windows most of the time. I also don’t like OPML or proprietary data formats so much.
So, after just a short time of playing with it, it seems that for me the approach of this new FoldingText for Atom is just what I need. It’s multiplatform and it has much of the functionality of OmniOutliner that I want, and that without the clutter. After a short while playing with Atom and FoldingText, I’m already considering switching entirely from Sublime Text to Atom.
Thank you for your patient reply. but I won’t try it again. I’ve spent much energy and time to learning how to handle ft 2.0. After I think I can use it as one of my main tools in my workflow, ft 2.0 is abandoned and I have to learn another “new” tool if I continue. I’ve reconmend my friends to try ft but I’ll not do it again. It’s stupid investment to learn a little hard tool (for me) just for using it for one year.
Looking at those “successful” tools: Devonthink or Omnifocus. I even find some useful script written in 2009 for Devonthink. How many devoted scripters like Rob could you find? How long will you expect them continue to devote? These are the real treasury of a great tool, not the tool itself. This treasury should grow as time rather than be abandoned.
I will only devoted my time and energy to those tools I think I could use a little longer. It’s an investment, not just for fun.
I would simply say use software that works for you, I have found good things in FT, TP and also Omnioutliner, no need to jump to Atom, it is easy enough to transfer your data in and out. It is too easy to get hung up on a specific piece of software and try and get it to do everything, an impossible dream. Text editors have been around for a long time and aren’t going to be suddenly useless when a developer wants to try something else.
I don’t seem to understand the new FT4A completely;
Typing an Markdown # Header, ## Second Level Header, Lists, etc, and getting the styling converted “on the fly” was THE Foldingtext experience for me.
It doesn’t seem to work anymore …
Other than that I love that You build on Atom now, but … please someone help me,
is there a way to get “on the fly” styling back … by just typing