Joachim, Thanks for your comments!
I tried answering some of this in detail, but it may just make sense to wait and resolve some or all of it after we have either a working folding implementation or at least a design that we can do thought experiments against. On Thursday 06 March 2008 03:31 pm, Joachim Lous wrote: > On Thu, Mar 6, 2008 at 4:09 PM, Randy Kramer <[EMAIL PROTECTED]> wrote: > > [many good thoughts, I won't comment the stuff I agree with :-) ] > > If you place the cursor within the remaining unfolded text (the header in > > HTML), it should behave "normally" (e.g., you should be able to edit that > > text). > > It would be nice, but if the criteria for possible folding blocks are > continuously reevaluated, > you might thereby remove the justification for the block. So you suddenly have a > folded block that does not follow the folding scheme (exploding it the > second the > mode no longer recognises it as foldable would certainly be > confusing). Not sure that > that is a problem, though. Good point. I guess in the cases I've dealt with, that hasn't been a problem, for either of two reasons: * in MS Word, the designation that a line is a heading is "out-of-band", and ordinary editing of the line cannot change its heading level nor from a heading to plain text (nor can ordinary editing cause it to switch from folded to unfolded (collapsed or uncollapsed in MS terminology) or vice versa) * in the TWiki markup that I use, the designation that a line is a header is in band (e.g., a line that starts with "---++ " is a level 2 heading (H2)). I guess here it's a matter of discipline--editing anything else on the line (the text after the "---++ ") can't (absent a bug) change the designation of a line, and if I edit the "---++ ", I expect potential weirdness (confusion) I suspect there is not a solution other than the user learning what to expect as a result of such editing. ?? > > I don't think there's any real reason not to leave the selection intact > > Well, you could easily get invisible state, which is always bad. E.g. > it would be > impossible to see what pressing 'delete' would actually do. True. It's hard for me to fully imagine this situation, I'll try to pay attention to how it works in kate, but again, user knowledge and discipline may be the key--don't do things like press delete unless you know (see) what is selected. > OTOH, it would be hopless for make correctly-working macros if the macro's own > selection keeps bouncing around as a side effect of its foldings. True. > Tough call. Maybe clean up (one way or the other) after user interaction and > after macro completion? I think so, and/or reconsider after some form of folding is implemented and we start to gain experience with the problems (not to say we can't learn from other programs that already fold (kate, emacs, Leo, MSWord, ...) > > Did you ask, but what about the similar situation for a selection totally > > within a folded area? > > No, but that's a good point. I would argue as above. > > > I'm going to get too tangled up here, and the other thing to consider > > simultaneously is the "scrolled position of the document". > > Many possiblilities, but I think that can be worked out afterwards. Yup, I think a lot of these things will have to be refined later. > It's just scrolling. > > > I would be tempted to disallow them unless someone (perhaps even myself) comes > > up with a good use case. > > I'd require a good use case _and_ a good, useable, policy. The latter > will be _very_ hard, > i'm guessing. > > > > * If using multiple panes, folding state is per-pane, right? > > > > Interesting question. Certainly folding state is per document. Oops, that seems like a mis-statement on my part. ;-) > Split-pane shares the same document. A particularly useful > application of folding > would be a collapsed overview mode in one pane and a "working" view in the > other. Yes! > Might even weigh more than folding persistence to some. > > > if NEdits back end can > > easily support a folding state on a per-pane basis. > > My guess it is probably the easiest way (folding state being part of the > text widget, not the buffer), if I remember correctly how highlighting is done. Interesting--that touches on some questions I've been trying to figure out. > > > * What happens if the cursor is at the first posisble position after a > > folded > > > block and I press backspace? > > > > just ask, must we resolve this now or can it wait? > > I suppose it doesn't have wide-reaching ramifications how it is solved. > Good luck moving forward; Thanks! I expect to need a lot of help to move forward. > it's really good to see some ambitious feature > thinking again. Yes, there is lots of tidying up to do, but we need some > creating dreaming too to keep the spirit up. regards, Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
