Aaron, Thanks for the response! I have added some comments interspersed below.
As a general comment, I guess (and I think someone else said the same thing) that some of the GUI interface stuff might get decided later, after we (somebody) gets a basic folding implementation in place. At that point we can consider (again) what makes the most sense, and/or consider user options. And: * some of this will take a little while to sink in * (and, of course, I'm not the final arbiter anyway) On Wednesday 05 March 2008 03:54 pm, Aaron Hsu wrote: > 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 I've seen an interface using the carets and the ... but I can't remember where. It didn't seem too bad at the time (but was outside my normal range of experience, so I didn't instantly embrace it)--I'd like to find whatever had that interface again and try playing with it. I guess it wasn't Emacs. Maybe it was TED (??) or one of the other folding editors I tried out (however briefly) in Linux--or maybe it's something I remember from the Windows world. > 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). I've always been an advocate of accessibility, and for that reason would be pushing for some keyboard based approach to do anything that can be done with the mouse. > 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. ;-) No argument there. > 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. Sounds like a reasonable approach, but I need to sleep on it some. If I'd need a few extra menu options, I could create those myself as long as we had the macro interface. > I also notice that you seem to think that folds on a per line basis are > more common? That has been my experience. It has some relevance when we go to the next step (discussing the back end storage to support folding) because one option that has been suggested to me might only support folding on a per line basis. We'll have to discuss it more at that point if that is a viable option. > 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. Thanks--a good start for that discussion! > I think the whole goal should be to strive to do complex things simply, > and simple things trivially. I like that better than the way I tried to say the similar thing. > It shouldn't get crazy, or hard to use. Absolutely! Thanks, Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
