Randy Kramer <[EMAIL PROTECTED]> writes: > Joachim, > > Thanks for the response! > > On Thursday 06 March 2008 06:06 am, Joachim Lous wrote: > >> 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.
I agree. It is hard to pick out an arbitrary editor as a baseline because I think there are just too many to consider. For example, I mostly think in terms of Emacs' folding and narrowing as well as BBEdit's folding. > ---< 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. As much as possible I would like to get rid of the idea of folds being line oriented. Rather, I think a fold, for purposes of interaction with the user ought to be considered a discrete unit. >> * 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 > > 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. I think that a macro that goes into something should not be able to end with the cursor in that block of text, though it should be able to enter into that block of text if necessary. I'd be interested to see if anyone had any reason that a macro should end in the selection when it is folded. Basically, I don't like the philosophy of expanding a fold that an user specifically left folded. I kind of think that a fold should always remain folded unless the user specifically wants that fold unfolded, which should not be the case if an automatic macro is occuring. >> * 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. Folding in principle is just the removal of visual data to the end user, and that's all it should be. It should not actually "Change" the way the editor deals with that data as far as its existance or not. Therefore, I think that highlighting should be consistent with and without folding. >> * 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.) I think that BBEdit has a logical, though perhaps---some may say---undesirable way of handling this. Just myself thinking about it, I think that the following selection method is probably a good one to think seriously about for a few reasons. First, I think that when we speak of selection, they are an interface element. They should represent something meaningful for the user, and they should always be clear for the user. Second, the user should not be surprised by the results, at least, in the bad way of surprising. Taking these into consideration, I think it's the wrong thing to keep the selection exactly as it is, because this leave no reasonable way to display to the user what is actually going on. Selections should be visually intuitive, and having a selection that goes through part of a fold and not the rest, is not visually intuitive, as if you use a succinct folded object to represent it, there is no way to indicate the ending point of the selection. I think that we should also strive to "stay with" the user's original selection as much as possible. To that end, I think there are only two reasonable ways of handling this, 1) exclude the fold from the selection, or 2) extend the selection to incorporate the entire fold. BBEdit does the latter, and in my mind, I could make a case for either. I think I would prefer 2 on my own, simply because if you already have a part selected, you most likely expect the whole to be selected if the part shrinks. However, this may be a case where we want to remain consistent with other editors. I think BBEdit's way of handling this is at least consistent. >> * 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 nto 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).) I doubt that we should allow it, but maybe just make it so that selecting the folded object would represent selecting the entire block of text, and then treat it as a column selection that extends out in this way? >> * 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. I agree that the fold should be re-collapsed, but maybe do it so that if any data is changed inside that fold, the recollapsing will not happen, but if a search is issued when the folded contents are not changed, then don't alter the results. >> 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. Probably just treat it like a normal find entry, and don't consider the replace as having changed anything. This should be the same with normal replace. It should expand to show the replaced text, but when someone goes on to the next replace without altering anymore data within the fold, it should be recollapsed, unless not possible because of the replaced text. >> * 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. To give a reference example, BBEdit does the folding on a per-document, and not a per-pane basis, and I think this is a reasonable thing to do. The per-pane folding may introduct too much complexity without any real benefit. We should avoid useless feature creep. >> * 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.) Well, I'll take a stab at answering this. I think that this is easily answered if and when we consider the folded code to be a single discrete entity (like a character) inside of the code. When this is done, then deleting on a folded section *definitely* should delete the entire folded object. I think if we do it this way then the action is intuitive. My general philosophy is that the editing actions should occur on the superficial level of the text as displayed by the editor to the user, rather than trying to do something "smart" with the underlying text. As such, if an user folds the code, chances are he wants to deal with things in a block form, and deletion on a block level is a natural extention of this. The problem would come if we represent a fold as a whole line, because then the single delete key doesn't seem as intuitive. -- 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
