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!)
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:
Another text editor that treats text as having no grammatical structure (it doesn't even do syntax highlighting), but nevertheless attempts to give the user some really snazzy shortcuts--not keyboard shortcuts, but mouse shortcuts--is Acme[1].
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.
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.
I'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 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).
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.
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.
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:
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.
One 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.
First off, this is a really interesting project. However, I'm trying to get my head around how much this would help me. Has anyone used text folding in production?
Isn't this a standard feature in most text editors / IDEs? I use SHIFT+ALT+CMD+ARROW-LEFT (I think that's the one (muscle memory)) every day in Xcode. And Sublime can fold methods etc also.
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.
Eclipse user here. The Java editor does have folding but I find it's much easier to navigate by doing a incremental find (Ctrl-S in emacs mode) or jumping to declarations or uses of a particular symbol. Looking through source by reading words is too slow; even the outline sidebar with method names is not that useful.
The last time I used folding and actually liked it was with GFA Basic on Atari ST :-)
Brilliant! When I am dealing with refactoring or modifying existing code, finding my way around is the hardest, most time consuming part. This seems a huge timesaver.
http://tibleiz.net/copper
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!)