Randy Kramer <[EMAIL PROTECTED]> writes: > On Wednesday 05 March 2008 06:57 am, Aaron Hsu wrote: > >> If all of you were to work towards some kind of code folding, I >> really like the code folding available in BBEdit from Bare Bones >> software. I find it simple, elegant, and useful. Maybe, you could >> take a look at that? > > * I guess BBEdit started as a Mac / Apple editor, and is not > free--do you run it under Linux by any chance? Is there a version for > Linux or Windows?
Heh, no. It is a Mac OS X only editor. I use Mac OS X pretty often. > * Do you know of any sites or reviews that discuss / describe the > outlining features? If you go to their website, they have a few reviews of the overall feature, but the manual provides more information. > * But better (easier for me ;-)--can you tell us what you see as being > useful features in BBEdit, and especially, which of those (if any) contrast > with the criteria we're starting to put together for nedit folding? I think the criteria you have given is fairly straightforward overall, but I'm more concerned that the "finish" of the editors folding works in simple, unobtrusive ways. For example, minimizing the change in UI would be nice. Instead of having lines blocking out the regions (which I think starts to clutter the interface) rather, I would think, have only carets (down and right arrows) on the left side and end markers. Have the actual marking of regions happen on a different set of things. For example, perhaps, to select a given foldable region (obviously this should be syntax dependent), maybe, I use the middle-click on the caret. Then, if I just want to see the folded code, and not select it explicitly, I could right click or some such, and it would show me what would be folded without actually folding it. Also, once folded, BBEdit uses a simple "(...)" looking object to denote the folded region, and I like that. There is another method, like Emacs, where you can actually hide any selection of code, but I don't think that's the way to do code folding in this case. I think the point I am trying to make is that more widgets on the screen would not be my solution, but rather a complete set of mousing actions instead. You should be able to drag and move and copy and work with a selected fold just like it was selected text. There should be some mouse action that is easy to perform that will let you open up a folded object (maybe automatically select it as well). One thing I like about NEdit is the amount of power you have in a nice, clean interface. I'd like to keep it that way. ;-) As for menu options, I don't like the idea of throwing in a bunch of them, but maybe just a few selected options. Folding based on a balance, and then maybe a command to fold the lowest unfolded foldable region that contains the cursor or selected text would be nice. Fold All, Expand All are musts, of course. Then maybe a "Fold at depth" command, and that should be all. Fold at depth would allow you to select how deep you wanted to fold your code. That is, if you select 2, then all the top-level folds that can happen will happen, followed by the second level folds. Maybe then, a "Fold at depth" would be nice as well. There might be a way to streamline these options so that they are not so many explicitly, but are just as general. I also notice that you seem to think that folds on a per line basis are more common? Well, most of my experience is with BBedit, and in that, folds are between any two arbitrary points in the code, and it should be possible to fold at any arbitrary selection, and have it turn into a little (...) object or some such. :-) As for saving of folded states, that should be pretty easy to do. A simple file could be maintained that has the following format: <filename>:<fold-start-line>,<fold-start-col>:<fold-start-char>:<fold-end-line>,<fold-end-col>:<fold-end-char>:... ... Basically, the idea is that it would keep track of where the folds are. The start and end characters are just something of my way of handling the possibility that the file was changed or altered between the time that the folding information was saved and the time that the file is recalled. That is, when getting persistent states, NEdit should recognize when the folding is no longer applicable because an area of the files that has to do with the folding was modified. The above solution doesn't work well, though, because you would reasonably expect folds to move even if you inserted something above or inside the fold, so I think a better method needs to be developed. I think the whole goal should be to strive to do complex things simply, and simple things trivially. It shouldn't get crazy, or hard to use. -- Aaron Hsu <[EMAIL PROTECTED]> | Jabber: [EMAIL PROTECTED] ``Government is the great fiction through which everybody endeavors to live at the expense of everybody else.'' - Frederic Bastiat -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
