Wishes for a folding editor

Designer's notes #11 - Home - Prev - Next
Řyvind Teig, Trondheim,  Norway (http://www.teigfam.net/oyvind/
Please comment at the blogspot [5].

More out of token-based folding

My programmer's folding editor, Winf is getting older. Even so, I use it every day. There are other editors which fold, in different ways - but I have found none as elegant as Winf. The version I have is from 2000, and the Windows executable is only 144 KB.

Basically, the editor is a tool to handle nested linked lists of folds. A fold is zero to any number of lines and/or folds (recursively defined). Winf uses token-based folding which means that the user explicitly defines a fold. A fold is not automatically the non-commented, collapsable, outlined, syntactic {blocks of code} - like in Visual Studio (see below). It's hand made structuring with required heading [3].

To me, a folding editor has folding as its basic editing paradigm. Folding is first rate, not add on. However, these days I'd like more functionality in a folding editor. 

I think their basic problem is that they plug into non first rate folding editors.

I do not list the obvious wishes for a new folding editor. Any developer these days would include them. Like copy/paste available in macros. Like, yes, the Visual Studio's collapsable blocks, which certainly is a nice - and orthogonal concept. And, I don't think there is anything in Winf I would not miss. Except, of course: it runs on Windows only. So, ours should be in Java I presume (like jEdit, see later). Goodbye to 144 KB.

General comments

The tag to define each wish, should be in the fold bottom crease, as a standard, readable text comment. The user should easily view the state of a fold when the state is in scope (by colour, status line or left margin vertical line). The command to enter states could be as buttons on the fold crease or clickable text. 

A file with all these new tags should be backwards compatible and readable by Winf (i.e. display tag as comment or not visible). 

And Winf should not destroy the tags. It would be a good backup editor as long as Windows runs exe files. (It should really be made available.)

My ideas stand without rationale. There is more stuff in note 10 and the article linked initially.

Contact info etc.

If you plan to use any of this, or like what you read, please help yourself. I think I copyleft these ideas, meaning I would appreciate being credited in a byline. Should any of the ideas not be new here, it is without my knowledge. Any feedback certainly is welcomed. Especially if I have invented something impossible!

The wish list: page 2


The wish list

1. Fold access rights

I would like a fold to have an access right attach to it. The only I need would be 1) all access allowed and 2) read only. [1]

2. Fold visibility to the compiler

Instead of commenting all text in a fold, a "comment fold" should be available.

3. Fold versioning / date

A fold should have a version tag. This should be a unique tag. It could be milliseconds since 1 January 1970, often called UTC. A new value should replace a previous every time the fold is modified in any way. But not when it is moved. Only the fold at this level should be updated.

4. Modified folds list

Every time a file is saved, a list of modifed folds should be presented. This means that the editor must know the lowest possible new UTC at start-up. There should be separate "save / don't save" checkboxes in each lines of the modified folds list. And a common commit button. The list should be as short as possible (linked list matter to think of here). The top level often is not folded, it should have a default fold name. Perhaps this functionality should be available any time?

5. Fold diff & merge

There should be a new diff & merge facility, which is able to handle folded files, unlike tools like WinMerge. The diff tools I know about are not able to detect a moved fold. This is good for version control & track tools, like StarTeam from Borland (diff may be user defined). There is no reason to flag a moved fold as both removed and added text. The version tag should be used by the diff & merge tool to avoid running o*n2 (or whatever) complexity in the search pattern matching. The tool should also have a semantic understanding of a fold, and make sure that manual merge never breaks a fold.

Also see [13] for more wishes for diff & merge. There, track tags (a variant of a fold) are introduced. These could also be understood by the new folding editor.

6. Fold restoration

A folded file may have been edited by a programmer with just about any programmer's editor. Even if fold start and end creases are easily recognizable in any editor, it's easy to mess them up. Finding intelligent ways to let the user interactively fix a fold is a challenge. Remember that with token-based hand made folding it's not possible to automatically fix a broken folded file.

7. Other fold functions

A: Flatten a fold and keep the fold single-liner without having to copy/paste it.

Winf and others

Since Winf is my reference par excellence. It was based on the INMOS D700 Transputer Development System (TDS) text editor which was called just "f" (or "F"). At some time the "f" editor was released as a separate tool, I think. Finally INMOS took it out of the tool package. Winf is © TLM Software, according to the About screen. However, the author has allowed me to publish all his material, which he kindly has sent me [4]

There also was a very similar folding editor to Winf, called Origami

Also, jEdit folds ok, it's GPL and runs on all platforms. I, alias aclassifier, presented this page to jEdit Feature Requests Forum 15.Sept.07. 

Some, not mentioned in the Wikipedia list,  are Michael Haardt's Fe, where both the editor and sources are available - and  FoldMaster

Appendix: page 3

12Sept07 (initial)
26Sept07, 18May09, 3July09, 24Jan2013

Other publications at http://www.teigfam.net/oyvind/pub/pub.html

[1] - Folds v. files
A reader pointed out that the INMOS TDS also had "filed folds". (I had forgotten.) My suggestion here could be implemented as a system of filed folds, he wrote, somewhat like in the TDS. Some of the things I want could then be pulled right out of the hat. These folds would be #include of the .c file (if C source).
My comments: #include of C often would disable me from source code debugging the system. Some debuggers will not understand breakpoint in an #include file. Having lots of small files does not make it easier for a version control system, even though a diff & merge could be easier. Not all languages could #include anything. And, an external diff & merge of external files would not make it easier to see that a fold has moved: it would be viewed out of context. No, I'd rather have something more like zip: a container with flat, connected text.
[2] - Preprocessor directives
Some readers have pointed out that the C preprocessor directives must tart with # in char pos 0 (leftmost). This is not so, what is required is that it should be the first non white character. So, it could easily be indented to code level. In my opionion, folding fails if preprocessor directives clutter the structure. They must be indented to code level.
[3] - Fold tags as part of code line or in separate lines
The Fe editor (see above) keeps fold start and end within comments anywhere on a line - also if code line. With Winf, start and end crease lines exclude code, and take only tag and a one-line comment. The compiler sees them as comment lines, never commented code lines. With Winf the one-liner is really required, else the fold would be seen as anonymous. Personally I would prefer Winf's solution. I also think it matches my suggestions here well.
[4] - Winf / winf32 uploaded files
On 17. May 09 they were uploaded to ../../extern/winf32_folding_editor/index.html
[5] - Wishes for a folding editor (2)
That page also includes how to run winf32 on Apple OSX on the free WineApp (Wine) emulator, using free X11 (XQuartz), rendering Parallels and Windows not necessary (added january 2013)

To top