Joachim, Thanks very much for taking the time to read the document! (Some notes below.)
On Wednesday 05 March 2008 04:01 am, Joachim Lous wrote: > I've read the brief. Its a good stating point, but a bit heavy on the > GUI stuff and a > bit light on the hard parts of how a folded region actually bahaves. Fair enough--I'll start trying to flesh that out. Of course, anyone can help as well, either by responding here or editing the wiki page. (You will have to register on twiki.org but the requirements are minor, iirc, you pick a user name, specify where in the world you come from (what country), and, iirc, your email address.) Thinking out loud (just to get a start), I'm thinking of saying something along these lines (starting with a simple non-overlapping folding region): When a folding region is collapsed, the following happens: * the first line of the region remains visible, all other lines in the region are hidden (we may have to think about exactly what first line means--I think it is a "hard" line, that is up to the first \n, but, of course, with continuous wrapping mode that could be more than one line. On Microsoft Word, at least some of the early versions I used, you could choose to do either. I'm not sure that extra complication is worth it (without knowing how much extra complication that is). ;-) * optionally, some sort of marker is placed on the line after the one line of visible text--it marks the end of a folded region when folded--in many "outliners" this is a horizontal line or some variation thereof * in the fold mark gutter, change the boxed "-" that marks the first line of a folding region to a boxed "+", move the ending "L" shaped marker to the first line after the visible text (corresponding to the location of the (optional) horizontal line, and delete all vertical lines between the boxed "+" and the "L". Is that the kind of thing you're looking for? I could then expound on that to describe the similar process for overlapping fold regions (where the end of the fold region is marked by the modified "+" or "E") and for unfolding. After a few days for possible comments, I'll try moving this to the document on the wiki. > There can indeed be a myriad critereia for creating a foldable region (syntax, > manual selection, macro script, saved state, whatever), but they will > all use the > same basic interface to the text widget to actually create it, and > once that is made > and made well, we can experiment with sources, rendering and interaction styles. Agreed! > The complex parts include things like the interaction with > highlighting that you mention, Ahh, yes, I still (in the description I just wrote) missed one aspect of that that I already use in kate and nedit, I use highlighting as an (additional) way to mark headings (which are the primary fold points in askRhk documents). And yes, I did suggest that the definition of syntax based folding might be done by the same mechanism that defines syntax highlighting with no specifics at all. At first glance, I was hoping it might be kind of straightforward, the user might put in a regex (or whatever is done today in nedit) which, when recognized would mark the beginning or end of a fold. I'll go back and look at how it is done today in nedit (it's been a long time)--iirc, there were a few options (like specifiying beginning and ending markup in some cases but not others. > but I also miss more detail on how a folded region interacts with > navigation and selection, > (via mouse, keyboard, or macro), searching and replacing and backlighting. Again (have I said it before?), fair criticism. In fact, in this case, I think I even contradicted myself (or maybe just come close). The one thing I did say was that navigation in the folded condition should ignore the hidden (folded) text. There's probably a few things I mean by that, and an exception: * When you are in a folded condition the cursor (insertion point), should never be allowed to get into a region of folded text * When you switch between an unfolded and folded condition and the cursor is in the unfolded region before the switch, the cursor should be moved to the beginning of the remaining unhidden line of that region (the heading line of that region, in HTML). * More thinking required, but I'm thinking about the condition when the cursor is somewhere else in the document and you fold a region by (mouse) clicking on the boxed "-"--I think, similar to above, the cursor (insertion point) should move to the beginning of the remaining unhidden line of that region (the heading line of that region, in HTML). * Now, I'm trying to remember, but I'll have to go back and play some with kate--kate does a lousy job of repositioning the cursor--oh, and or the scrolled position of the document in these cases. So, we should also address the scrolled position of the document. After I have a little time to remind myself of the (aggravating) things that kate does in regard to the location of the cursor and/or the scrolled position of the document on folding or unfolding, I'll add some more stuff to this area. One thing (sort of a reminder to me), one of the cases that bothered me (not the most significant one) was that (iirc) when I unfolded an area, the cursor was always at the beginning of the now unfolded region. There were a fair number of times when I wanted to be at the end of the now unfolded region. IIRC, there was a straightforward way of choosing that in MS Word--I'll have to remind myself of that. Oh, as to how I contradicted myself--hmm, can I remember--I guess I did say that I'd like to have the option of having various editing actions affect just the visible (non-folded) portion of the document or affect the entire document. The two specifics that come to mind are things like search and search and replace. * If I do a search in the folded condition, my normal expectation (and the normal behavior on kate) is to find whatever I'm looking for in the document whether it is in a folded or unfolded region (or crosses one or more boundaries). Also, at that time, kate expands any folded regions containing the search target so that they are visible to the user. What kate doesn't have is a built-in automatic way to refold that area if you "Find Next"--that would be a nice feature. * Other times, though, I might want my search limited to just the currently visible (i.e., unfolded) portions of the document. I was going to describe search and replace similarly, but for now I'll just say it's analagous to the description for search. If you do a global search and replace (as opposed to a "Find Next" followed by an optional "Replace"), I don't think I'd want to see (and I don't think we see in nedit today) the context of each such replace. On the other hand, if the user does do a "Find Next" followed by an optional "Replace", he must see the context. Again, it would be nice if that area was automatically refolded (or maybe a better wasy to describe it is that it would never actually be "really" unfolded, but instead just made temporarily visible after the "Find Next". > Not a complaint, just a little input on TODOs for everyone. Absolutely--all help, comments, criticisms appreciated. I don't know how far / how quickly I'm going to go as far as getting the criteria for folding into perfect condition--the next topic I wanted to raise was how to deal with backend storage to support folding, questions like do we take hidden text out of the gapped buffer or do we leave it in. (And, an older question: can we avoid displaying a line by not including it in the lineStarts array?) I think we soon will have enough context (even without a perfect criteria document) to start considering questions like that. regards, Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
