Pretty cool. Some gripes though:
* How do I teach it new comment syntax?
* How can I change fonts?
Code Browser – A Folding Text Editor
21–29 of 29 posts
Re: Code Browser – A Folding Text Editor
#22Wish there was a mac version.
What I thought when I saw "Windows and Linux". So this is what it feels like, huh? Looks cool though, gunna give it a whirl on my Windows box.
Not long ago all the software one wanted to run[1] was only available on Windows. Then the Internet happened, then[2] the open source movement, then Apple's return from the brink of death. One doesn't need to be very old to know what it feels like.
[1] to a first approximation of "all"
[2] to a first approximation of "then"
Re: Code Browser – A Folding Text Editor
#23I've been trying it out. Here are my suggestions for improvement: There should be a simple mouse way to exit a section (the opposite of double-click to enter a section)... perhaps an X button to click on. Right now you have to hit Alt-Left, Go->Parent_Section or Right-click menu-> parent. You can navigate quickly when a list-view is open, but this would allow it even if there is no list-view. The editor should rememb…
Storing text in a named file, folding a block of text within a file into a named "fold", and opening multiple views of the same file (with each view potentially being a different subset of that file), are all really just the same idea: that of a hierarchical filesystem. This could easily be achieved by writing a synthetic filesystem for Plan 9, and used with Acme.
The only difference between the semantics in this kind of filesystem is that there are no directories. Rather than associating each file with a directory, we instead want to create the filesystem hierarchy directly out of named subsets of the files themselves.
I might not have been completely clear about it toward the end, but my reply (currently a leaf) to my own thread on this page tries to describe how the mechanics for this might work.
Re: Code Browser – A Folding Text Editor
#24One issue with using a tool like this to browse a project which was not already folded: you waste a lot of time just adding folds (akin to "properly" indenting someone else's code). On the other hand, that might not be a bad exercise as you try to comprehend a new project.
Re: Code Browser – A Folding Text Editor
#25I've been trying it out. Here are my suggestions for improvement: There should be a simple mouse way to exit a section (the opposite of double-click to enter a section)... perhaps an X button to click on. Right now you have to hit Alt-Left, Go->Parent_Section or Right-click menu-> parent. You can navigate quickly when a list-view is open, but this would allow it even if there is no list-view. The editor should rememb…
Storing text in a named file, folding a block of text within a file into a named "fold", and opening multiple views of the same file (with each view potentially being a different subset of that file), are all really just the same idea: that of a hierarchical filesystem. This could easily be achieved by writing a synthetic filesystem for Plan 9, and used with Acme. The only difference between the semantics in this kin…
Well it does not exactly match filesystem semantics- I mean a directory/file has both content and directory entries, and they are ordered. You would have to define what 'ls' does in this context.
This made me wonder what code-browser did with xml files. It's nothing special, but it could have treated the elements as folds.
Re: Code Browser – A Folding Text Editor
#26Earlier quoted context omitted.
Storing text in a named file, folding a block of text within a file into a named "fold", and opening multiple views of the same file (with each view potentially being a different subset of that file), are all really just the same idea: that of a hierarchical filesystem. This could easily be achieved by writing a synthetic filesystem for Plan 9, and used with Acme. The only difference between the semantics in this kin…
Well it does not exactly match filesystem semantics- I mean a directory/file has both content and directory entries, and they are ordered. You would have to define what 'ls' does in this context. This made me wonder what code-browser did with xml files. It's nothing special, but it could have treated the elements as folds.
Yes, good point about the differences in semantics with conventional filesystems.
To the extent that they are similar, though, a synthetic filesystem could try to expose the folds as a Plan 9 filesystem interface. Plan 9 filesystems may or may not act like conventional filesystems, sometimes also require talking to a control file in some special-purpose protocol.
Presumable, one could write a Plan 9 filesystem to handle folds in a way that a text editor can exploit (some small modifications to Acme, mostly related to mouse input--and a few rc scripts to talk to the filesystem--would probably be more than enough). But, by doing things the Plan 9 way, you get more flexibility and interoperability; for example, the ability to control folds (perhaps without even opening the text editor, although this raises the issue of how persistent folds should be) from the other scripts, or just to do things like access the contents of a fold with programs like cp, diff, ftp, etc.
Good point as well about XML, a file format that is crying out to be treated along with the folds in a more unified way.
Re: Code Browser – A Folding Text Editor
#27One issue with using a tool like this to browse a project which was not already folded: you waste a lot of time just adding folds (akin to "properly" indenting someone else's code). On the other hand, that might not be a bad exercise as you try to comprehend a new project.
Folding could be partially automated based on language grammar. It could also try to learn from your own manual folds.
Re: Code Browser – A Folding Text Editor
#28Earlier quoted context omitted.
Well it does not exactly match filesystem semantics- I mean a directory/file has both content and directory entries, and they are ordered. You would have to define what 'ls' does in this context. This made me wonder what code-browser did with xml files. It's nothing special, but it could have treated the elements as folds.
Yes, good point about the differences in semantics with conventional filesystems. To the extent that they are similar, though, a synthetic filesystem could try to expose the folds as a Plan 9 filesystem interface. Plan 9 filesystems may or may not act like conventional filesystems, sometimes also require talking to a control file in some special-purpose protocol. Presumable, one could write a Plan 9 filesystem to han…
Yeah, the OS should already treat any archive-type file as a filesystem automatically. So you can "cd" into a .zip, .tar or .ext4 file (no mount -o loop necessary). Applications have some support for this (MC and emacs in UNIX or Windows Explorer), but it should really be in the OS.
Re: Code Browser – A Folding Text Editor
#29Earlier quoted context omitted.
Yes, good point about the differences in semantics with conventional filesystems. To the extent that they are similar, though, a synthetic filesystem could try to expose the folds as a Plan 9 filesystem interface. Plan 9 filesystems may or may not act like conventional filesystems, sometimes also require talking to a control file in some special-purpose protocol. Presumable, one could write a Plan 9 filesystem to han…
Yeah, the OS should already treat any archive-type file as a filesystem automatically. So you can "cd" into a .zip, .tar or .ext4 file (no mount -o loop necessary). Applications have some support for this (MC and emacs in UNIX or Windows Explorer), but it should really be in the OS.
That would be very interesting indeed. Even Plan 9 requires you to mount tar files with a special command instead of simply typing "cd file.tar".
The Plan 9 developers were conservative about preserving the semantics of commands like "cd", so that the system did not diverge too greatly from Unix. Instead, the equivalent of double-clicking on a file in Windows Explorer is handled by right clicking on a file in Acme. Acme sends the filename to something called the "Plumber", which then uses rules to decide what to do with the file: