Joachim, Thanks for the response!
On Thursday 06 March 2008 06:06 am, Joachim Lous wrote: > Some of those were indeed treated in the original brief, and some more > in the previous reply. But some remain, and some can use more detail. > Here are some random outstanding questions to illustrate: Wonderful--I'm going to try to answer them. ;-) ---< reordered >--- > I have no problems at all with designating some other well-liked editor > as our official reference on any or all issues like these, but in that case > that should be made explicit, or else we need explicit decisions on these > kinds of things. I'm reluctant to do that, partially because I'd suggest some arbitrary combination of features I'm familiar with from MS Word and kate. Plus, others have different experiences and should be heard. As we identify the questions, let's try to develop answers. ---< back to the original order >--- > * can you place the cursor within the single viisble line of a folded block? > If so, what does that 'mean', and what can you do there? I want to be careful here--I can imagine the single visible line referring to either the remaining (unfolded) text, like in HTML folding, the header for a section or to the (optional?) horizontal line marking the end of a folded section. 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). If you place the cursor in that horizontal line, my first reaction is that we shouldn't allow that (because, unless I'm misremembering, that's been my experience), but if others feel it should do something like automatically expand (or expand after an additional click or keystroke), I don't immediately see a problem with that. (I mean, if that created a conflict with something else I wanted more strongly, then I'd want to consider it more carefully.) > * OK, so you can't place the cursor within a folded block with the keyboard > or mouse. But what if a macro tries to move the cursor to a buffer > position inside > the block? We must probabaly allow it, but should it auto-expand the block? Some of my macros move the cursor to a lot of intermediate positions (or make intermediate selections) before the macro is complete. I have no need (unless I'm debugging) to see what goes on there until the macro is complete and the cursor is in its final location. So, I guess I'd say that if the final location of the cursor (or selection) is within a folded region, I guess it should auto expand, and otherwise not. > Same with selection from macros. I think I covered that above, unless I missed a point. > * How do we make sure that folding a block does not change the highlighting of > anything outside it? > Does the highlighting engine treat each 'edge' of a folded block just like the > visible window boundaries today? This is a tougher area for me--I'll think about it, maybe someone else can chime in. Just as a tentative answer, I don't think the highlighting should change just because an area is folded. > * What happens if, before folding away a block, there is already a > selection spanning only one of its boundaries? I'm glad you asked that question, because there are, no doubt, a lot more similar to that one that will need to be addressed. (IMHO, kate does some wrong things with things like this.) Hmm, a selection--what are the options: * You could leave the selection selected, and make sure the cursor remains (or is moved to) a visible portion of the text * You could cancel the selection * You could truncate the selection to exclude the hidden portion I don't think there's any real reason not to leave the selection intact but make sure the cursor is visible? (And I'm not 100% sure about leaving the cursor visible--see next item.) Did you ask, but what about the similar situation for a selection totally within a folded area? Again, I don't think there's a real reason not to leave the selection intact, hmm, but what about the cursor? (I just confirmed for myself that, normally at least, if the cursor is moved the selection is cancelled.) I'm going to get too tangled up here, and the other thing to consider simultaneously is the "scrolled position of the document". My position is this--these things can and should be worked out "logically" on a case by case basis when the time is right. If some of them have to be resolved before we can agree on, for example, the backend storage for folding, then we'll have to resolve them "now", otherwise we can wait. It's good to think about these things now to see which if any do have to be resolved now. > * Normal selections that completely include one or more folds are easy > to imagine. > But what about rectangular selections? And dragging them? Maybe just > disallow it? I would be tempted to disallow them unless someone (perhaps even myself) comes up with a good use case. (But, again, this requires some subconscious, if not conscious, thought (i.e., some sleeping on it).) > * If 'find' can hit something inside a fold, I suppose it should also > auto-expand it. I agree. I tried to cover that somewhere in one of the documents I wrote. I also think that if you do a "Find Next" to go to the next occurrence, the auto-expanded area should be recollapsed. How long to continue to allow that might be an interesting question. > But how about 'replace all'? IMHO (which I guess I should say everytime I say something on these subjects), for a replace all you have no need to see what's going on--don't autoexpand anything--hmm, except what if the final replace is in a folded area? I guess that's where nedit leaves the cursor today? (I'd have to test)--If so, I guess I'd say autoexpand the area around the final location of the cursor, but maybe have someway to autocollapse it again easily. > * If using multiple panes, folding state is per-pane, right? Interesting question. Certainly folding state is per document. Before answering this question, I'd be tempted to find out if NEdits back end can easily support a folding state on a per-pane basis. But wait, that could be considered a conflict with a persistent folding state unless we adopt some philosophy like "last to save wins" (which I'm not sure is my preference at this time). I guess another choice is to some how persist the folding condition for both (or all) open panes on a file, as well as persisting that number of open panes (so that when you reopened that file, you got all the panes you previously had in their last folded state). ATM, that would not be high on my priority list. I guess during the design we can try to think about whether any decision we make is likely to preclude or make that especially difficult sometime in the future. IIRC, when I've opened the same document in multiple panes, the 2nd pane has been opened on a temporary basis, maybe to check or copy something elsewhere in the document, so again, I don't see that as a high priority. After we have folding, and I'm using it constantly, I'll probably change my mind ;-) > * What happens if the cursor is at the first posisble position after a folded > block and I press backspace? Another good question, and I won't even attempt to answer it now, but instead, just ask, must we resolve this now or can it wait? (And try to keep it in my subconscious, or maybe better on a list, in tune with my penultimate paragraph, below.) > Some of these things are probably trivial things that can be worked out as > part of implementation and possibly tweaked later. > But I suspect there are others that will turn out to have a real bearing on the > fundamental design decisions. Yes, and I guess we need to try to identify those which do have a real bearing. I don't know how you might go about that. My general approach is to keep thinking about things (including the details you mention, as well as others you haven't mentioned), especially as we move toward a design, and hope that my subconscious mind (or somebody else's subconscious mind), having some of these questions and situations planted in it, gives us some kind of warning before we move in a wrong direction. Better approaches and suggestions welcomed! regards, Randy Kramer (And, obviously, sooner or later, I (and/or) others should integrate details and questions like these into the design criteria--trying to maintain a hierarchy so we can continue to see the forest.) -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
