Folding: Design Criteria, draft

[Randy Kramer]

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.)