Code Browser – A Folding Text Editor
tibleiz.net
tibleiz.net
My first reaction reading about the program was: since code folding (and other crutches intended to aid refactoring[1]) ought to be tightly coupled to the language (or even specific project) you're editing, you'd surely need the ability to write scripts, lest things begin to get clunky. Emacs immediately comes to mind, but inspecting the code revealed that the scripting language made available to the user is also a creation of the author.
I don't now much about how practical it is to develop a DSL using LLVM, but I would be fascinated to know how the process compares to Lisp in terms of productivity. Without having read the source code too carefully, one thing I'd be interested to know is whether or not the language written by the author (Copper) and the editor's scripting language are one and the same (as in Lisp). Is there an interpreter somewhere in the editor source? Or are plugins compiled or interpreted by Copper / LLVM at some point?
Of course, the author may also have his own motivations for choosing LLVM--for example, to learn.
All said, fascinating project!
[1] but hopefully not to merely make unwieldy code-bases navigable. (Yikes!)
http://tibleiz.net/code-browser/tips.html
Understanding existing source code
Code Browser can help you to understand existing source code.
There is a lot of tools dedicated to program understanding that will do the job better than Code Browser, but if the source code is written in a too obscure language or too old, it can be a cheap alternative.
Here is some tips to make more sense of a flat text file by extracting a structure and reducing its apparent complexity:
In fact, years ago, I'd contemplated adding text folding to Acme by adding another chord. I don't exactly remember what I had in mind, but one approach that immediately comes to mind now is to have the chord cut the selected text, and then insert in its place a shorter block of predefined text which starts with the name of an rc script to create a file[2] representing a new "fold" containing the cut text, and positioning the cursor immediately after the command. The user would immediately type a name for the fold, and middle click the whole string to execute the script with the name as its argument, thereby creating the fold. Finally, the selected command just executed should be replaced simply with the name of the fold, which should then be selected, so that the user would now be only a right click away from immediately unfolding the text.
I think the reason I never got around to doing it was that it seemed that this kind of feature really begs for acme to follow the names of the synthetic files representing the "folds" as files themselves to be opened (via right click, which always opens a file in acme), but at the same time, not literally open the file, instead unfolding it.
Writing this comment makes me think now that it wouldn't be so hard to get the semantics of the synthetic "folding" filesystem right, so that Acme remains simply a text editor with a few conventions for working with files, with the "fold" synthetic filesystem doing the work to preserve this simple worldview. What actually concerns me more is the kind of code that would require you to fold it! If need to fold a significant amount of code in order to make sense of your source code, perhaps you would be better if if actually reorganized your project's file structure, and not rely on fancy text editor features as a crutch.
[2] Of course this feature would use a filesystem to manage the code folds! It's a Plan 9 program, after all.
I've come to rely on Sublime Text's Cmd+R "Go To Symbol..." [1] (and Cmd+Shift+R "Go To Symbol in Project...") extremely strongly for code navigation. Instead of scrolling up or down to and _searching_ for a func I want, I just Cmd+R and go to it. Lookup, not search. It becomes second nature and so fast that other things become the bottleneck.
However, sometimes I notice its limitation of having just one scope, the top level symbol definitions. I wish there were other scopes accessible, like go to symbols within a function declaration. Or go to packages within my GOPATH (partially addressed by GoSublime's Cmd+.,Cmd+O "Browse Packages" [2]).
Basically, I think that being able to quickly select a scope and navigate to entries within it is very a powerful construct, and this Code Browser seems to address the multiple scopes aspect. That's why I think it's interesting.
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 remember the last cursor position within each section. So if I exit a section, then re-enter it, the cursor is restored to the last place.
It would be cool if the editor tried to hide the distinction between files within a project and sections. The project could provide the level of hierarchy above the file. I was surprised that there is no project file .cbp for the code-browser source code.
How can I close a project? It does not seem possible. The "add file to project" should allow me to select multiple files.
I know there are links.. but they don't act like sections. I can Alt-Right to follow a link, but I can't then hit Alt-Left to get back. BTW, when I edit a path for a link it should bring up a file browser, not just a text box.
EDIT: thinking more about this: the concept of tabbed file browsing should be replaced with tabbed views. I should be able to have multiple views into several sections of a project, ignoring all file boundaries.
I should be able to have several views on the screen at one time (even if they are in the same file).
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.
This made me wonder what code-browser did with xml files. It's nothing special, but it could have treated the elements as folds.
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.
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:
So this is what it feels like, huh?
Looks cool though, gunna give it a whirl on my Windows box.
[1] to a first approximation of "all"
[2] to a first approximation of "then"
The last time I used folding and actually liked it was with GFA Basic on Atari ST :-)
Am I missing something?
I do like the tree structure it gives you, something I'd really enjoy having for my notes as an overview. Too bad it's not for OSX.
* How do I teach it new comment syntax?
* How can I change fonts?