Too easy to accidentally delete folded text?

kerim's Avatar


25 Sep, 2012 03:25 AM

I don't know if I'm the only one with this problem or not, but I find it frustratingly easy to accidentally delete folded text. I can't exactly replicate the steps that I take, but it has happened to me several times now.

  1. 2 Posted by kerim on 25 Sep, 2012 04:14 AM

    kerim's Avatar

    I think part of the problem has to do with it not being clear when entering or deleting text affects the folded text. In my mind nothing should, but that doesn't seem to be the case. I've had both text inserted between a header and the folded text below as well as folded text which is deleted. I've also lost text on moving folded items, which seems to be a different problem.

  2. Support Staff 3 Posted by Jesse Grosjean on 01 Oct, 2012 04:49 PM

    Jesse Grosjean's Avatar

    I agree this needs work. It’s on our radar, but also a fairly complex issue.

  3. 4 Posted by Bruce on 16 Oct, 2012 05:37 PM

    Bruce's Avatar

    I had similar issues with Task Paper. A few times major chunks of text in Task Paper just disappeared - gone forever. So I switched back to OmniOutliner which is rock solid. Especially on mission critical ToDo Lists, my data is too important to be second guessing if something was arbitrarily deleted in Task Paper or Folding Text.

  4. 5 Posted by kerim on 17 Oct, 2012 05:40 AM

    kerim's Avatar

    One has to be very careful when inserting text or deleting blank lines next to folded text. With this in mind I'm able to use the app, but until it is fixed I am unwilling to recommend the app to my friends or students as I think it will cause them too much heartache.

  5. 6 Posted by ComplexPoint on 17 Oct, 2012 08:32 AM

    ComplexPoint's Avatar

    I think the problem is that the collapse mark collapse icon vanishes if you enter a return between it and the end of the parent line.
    The descendants are not in fact, lost, but their whereabouts (even existence) is immediately unclear to the user.

    Fix: deal with the collapse icon vanishes bug …

    I don't feel that FoldingText is actually any less solid than OmniOutliner, but I do think that OO3's disclosure triangles give greater clarity about where the child nodes really are at any moment.


    If you place a cursor between the collapse icon and the end of the parental text, hitting the enter key will make the collapse icon vanish.

    Let's collapse this:

    Now place your cursor just before the collapse icon, and hit enter

    The icon vanishes … where are the children ?
    Where are the children

    We enter more text, as if the children no longer existed
    Enter more text

    But in fact, if we use View > Expand, first the collapse icon will reappear, in an unexpected place
    Unexpected place

    and then, if we use View > Expand again, it turns out that the children have jumped ship …
    Jumped ship

    I think it would be fair to say that the vanishing collapse icon is a bug …
    (and that by creating confusion about where the folded data has gone, it could risk inadvertent data loss - if the child nodes have jumped ship, and the new effective parent shows no collapse icon, we might delete parents without appreciating the loss of those who sail in them).

  6. 7 Posted by kerim on 17 Oct, 2012 08:39 AM

    kerim's Avatar

    Thanks to ComplexPoint for explaining what is going on. I think preserving the icon would certainly help, but more than that, I would suggest that most users entering a carriage return right before the icon are not interested in moving the children. My suggestion would be leave the icon and children in place when a carriage return is entered without any text between the curser and the children icon. In short, nothing anyone does while text is folded should affect the folded text in any way unless the parent level item is itself moved, in which case the folded text should move with it. This is what I would expect to happen. If there was some reason someone would actually need to enter a carriage return in such a situation and move the folding text so it attaches to the next paragraph, I suggest this be accomplished with a key combination like command-return or option-return etc.

  7. 8 Posted by Fabian on 17 Oct, 2012 12:09 PM

    Fabian's Avatar

    Just to join in here, I agree with your analysis and suggestions. Filed a bug report for it a few days ago, before seeing this thread, with Jesse basically explaing what ComplexPoint stated above:

    I too had problems with disappearing text in Taskpaper and I’d say it would be crucial to get this behavior fixed in FT, in order to make it a solid base for work.

  8. 9 Posted by kerim on 02 Dec, 2012 02:07 PM

    kerim's Avatar

    Now working with the latest build -was 1.2, now renamed 1.1(595).

    This is much better, in that you can't accidentally delete, and the folding text marker is darker when you accidentally insert text before it. This behavior is still a little odd. I personally think it would be better to beep when hitting a carriage return before the folded text marker, just like deleting it results in a beep. However, if there is a reason you want it to work this way, it is still a bit buggy. For instance, if the folded item has nothing after it (after folding) the marker disappears when inserting text. Also, and no matter where the folding text appears, un-folding text after inserting text before the marker seems a bit buggy. In some cases I have to unfold, refold, and then unfold again before things display properly.

  9. Support Staff 10 Posted by Jesse Grosjean on 06 Dec, 2012 08:47 PM

    Jesse Grosjean's Avatar

    Kerim, I agree there are still some UI issues to figure out with filtering/folding. I've collected a number related bug reports and will try to come up with a coherent solution. Not there yet.

  10. 11 Posted by ComplexPoint on 20 Dec, 2012 12:53 AM

    ComplexPoint's Avatar

    FWIW for the moment, I have experimentally mapped return (for FoldingText) to a script which aims to create the new line after the subtree of a the selected line (if that selected line is folded).

    Not perfect, but moving towards something workable for me.

    (to break a line in the middle, I use Ctrl Return)

    on run
        tell application "FoldingText"
            tell front document
                set recSeln to (read selection)
                set strID to item -1 of (nodeIDs of recSeln)
                if (HTTP request URI "/view/collapsed.json") contains ("\\\"" & strID & "\\\"") then
                    set strID to |id| of item -1 of (read nodes at path ("//@id=" & strID & "/descendant::*"))
                    set recNew to item 1 of (create nodes it at id strID from text "" with relation "nextLine")
                    set recNew to item 1 of (create nodes at range (|textRange| of recSeln) from text "" with relation "nextLine")
                end if
                -- AND SELECT THE NEW NODE
                update selection with changes {|textRange|:{|length|:0, location:(textindex of recNew) as integer}}
            end tell
        end tell
    end run
  11. Support Staff 12 Posted by Jesse Grosjean on 20 Dec, 2012 08:21 PM

    Jesse Grosjean's Avatar

    Interesting. This might be a good end solution... though it breaks the mental model of (...) is just a substitute for hidden text. It also begins to change the editing rules around the (...).

  12. 13 Posted by ComplexPoint on 20 Dec, 2012 08:31 PM

    ComplexPoint's Avatar

    Interesting. This might be a good end solution... though it breaks the mental model of (...) is just a substitute for hidden text.

    I suppose a difficulty of that mental model is that if the folded tree is at the end of the document, it's not entirely clear how one starts to type beyond it (without unfolding).

  13. 14 Posted by ComplexPoint on 20 Dec, 2012 08:44 PM

    ComplexPoint's Avatar

    i.e. the condition in which the EOF is enclosed within the fold seems to resist simple logical definition.

    Does our mental model of the document end at the EOF, or at the outer edge of the enclosing fold ?

    Or to put it another way, does the editing buffer enclose the fold, or does the fold enclose the edge of the editing buffer ?

    The mental and the physical may diverge a bit at the point at which we try to type beyond this final fold and it turns out to be difficult.

  14. 15 Posted by kerim on 21 Dec, 2012 01:36 AM

    kerim's Avatar

    I think we shouldn't get caught up in semantics. I don't think any user expects any action they take on a document to edit the folded text in any way. The prevention of delete solves half of this, but something needs to be done from the other direction. "create the new line after the subtree" feels right to me. That's what I would expect to happen. The current approach, of moving the folding text defies the concept of having folded that text. If you want to edit the text and add a line before it, you unfold it first and then you can edit it. When it is folded, it should "belong" to the item it is folded into.

  15. 16 Posted by ComplexPoint on 21 Dec, 2012 08:04 AM

    ComplexPoint's Avatar

    Perhaps there is a confluence of two traditions here :

    • Outlining (MORE, MS Word's Outline View, OPML and OmniOutliner etc)
    • Code Folding (TextMate, Sublime Text, Vim and Emacs, org-mode)

    People who are currently using code editors may well be familiar with the trailing fold icon idiom, but for others it may be counterintuitive.

    Is FoldingText a plain text outliner or a code folder ? (Is is competing more with OmniOutliner or with Sublime Text ?) I personally use it as an outliner, and I am much less distracted by a return key which lands me in a new line after the collapsed sub-tree, rather than before it.

  16. 17 Posted by bayard.webb on 27 Dec, 2012 08:05 PM

    bayard.webb's Avatar

    I think the complex point raised by ComplexPoint is worth discussing. Here's my take.

    I bought FT for a Markdown editor with the ability to focus on one or two areas by hiding the rest. The idea that FT appears set to be a superset of TP didn't occur to me. For that matter, neither did it occur to me that people would put it up against OmniFocus, although in retrospect, that seems quite logical.

    Given that it's called "FoldingText," I think that's what it should do, and do well. Here are my current thoughts:

    • Dump the ellipsis character after the head of a folded section and instead, apply formatting to the hash symbols to indicate that there is hidden content. If that is deemed insufficient, and a symbol is used, it should be in front of the text, like other code-folding apps.
    • If you click in the header and make an edit, you edit that line
    • If you hit return anywhere in the header line, the remaining text in the line becomes a new line positioned after the entire block of hidden text. In other words, the tail of the header stays visible as the next line, but all the hidden text is still represented by the header line.
  17. 18 Posted by Steve Samuels on 07 Jan, 2013 04:23 AM

    Steve Samuels's Avatar

    I agree with Bayard on all three points. I have found FT non-inuuitive, indeed have not been using it, because the folding behavior has the split personality that ComplesPoint has described.

    I would also like to see the following capability, which goes beyond the outliner paradigm: the ability to fold any selection of text, not just text after header lines, but keep the first line of the selected region visible, whether header or not. Often when I'm writing. I'd like to fold or hide a selection and don't want to be forced to create a header just to fold.. Keeping the first line visible lets it act like a header without necessarily being one.

  18. Support Staff 19 Posted by Jesse Grosjean on 07 Jan, 2013 04:37 PM

    Jesse Grosjean's Avatar

    I've added "If you hit return anywhere in the header line, the remaining text in the line becomes a new line positioned after the entire block of hidden text" into my dev version and I like the behavior.

    the ability to fold any selection of text, not just text after header lines, but keep the first line of the selected region visible, whether header or not.

    The model already supports this, there's just no way to do it directly in the UI yet. But I expect it will be added eventually. Note that in the current dev release you can get a form of non hierarchical folding by adding tags to lines, and then click on the tag. The result is that only the tagged lines and their ancestors are shown. I've attached a screenshot where I've arbitrarily tagged some lines with @done in the users guide, and the filtered on that tag.

    Dump the ellipsis character after the head of a folded section and instead, apply formatting to the hash symbols to indicate that there is hidden content.

    That screenshot also shows some problems with the current ellipse method of indicating a fold... the results of arbitrary folding and using the ellipse indicator just look messy and scrunched. The problem is that we loose all empty whitespace lines. And the ellipse indicators start to look to dark and distracting.

    I think just moving the fold indicator the the front of the line won't really solve this case. Instead I've been thinking that we could move the fold indicator onto it's own line after

    I'm working on a rearrangement of the ellipse indicator that I hope will make things work a bit better. When we start folding arbitrary regions the big problem that I notice is that everything gets all squished up. For example (in current 1.2 dev version) if you tag some lines throughout your document, then click on the tags... your view is folded to show only those tags lines + their ancestors. But this generally means that all empty whitespace lines are removed, and the resulting view looks all bunched up.

    I think moving the fold indicator to the front of the line wont help this case. Instead what I'm considering is adding an extra line for any folded region. So instead of displaying the (...) at the end of the folded line, it (or some other symbol) will be displayed alone on a new line after the folded line. That should give us back our whitespace. Anyway still in thinking mode on this. I haven't actually tried to implement any of this, but I just did a quick photoshop mockup that's also attached.

    Thoughts and feedback are welcome!

  19. 20 Posted by bayard.webb on 08 Jan, 2013 06:01 PM

    bayard.webb's Avatar

    I like the idea of putting the ellipsis and white space after the header. Here are some more random thoughts and questions.

    • What if a user accidentally hits backspace or delete when the cursor is aimed at the ellipsis? It seems like you should not be allowed to delete the ellipsis, assuming that it represents the hidden text.
    • What happens if the user presses return when the cursor is at the front of the header? You'd end up with a blank header line, and the text that was your header now appears below the ellipsis. I hadn't thought of this when I made my previous suggestion.
      • The alternative would be to leave the text before the return above the header, and the text after the return would be the header.
      • This poses the opposite problem, if a user hits an additional return at the end of a header line. You again have a blank header line, but at least the text that was removed from the header line is above the hidden text, i.e., you haven't rearranged your content.

    Sorry for rambling, just trying to get all thoughts on the table so Jesse can make the best possible decision.


  20. 21 Posted by Jamie Kowalski on 12 Jan, 2013 06:10 PM

    Jamie Kowalski's Avatar

    I like that FoldingText does not allow the user to backspace over a folded section; but I think it should also prevent a forward delete into a folded section.

  21. Support Staff 22 Posted by Jesse Grosjean on 18 Feb, 2013 07:16 PM

    Jesse Grosjean's Avatar

    I think we are going to leave things are they are for 1.2, but going forward (in 1.3) I expect we will change the fold implementation to be more like Xcode... where the folded text is represented by a single selectable character. Then I think most of these issues go away.

  22. 23 Posted by kerim on 02 Mar, 2013 06:56 AM

    kerim's Avatar

    Just updated to 1.2 the new behavior seems to solve my problems.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac