On Wed, Mar 5, 2008 at 4:10 PM, Randy Kramer <[EMAIL PROTECTED]> wrote:
> [lots of good points]

First of all, although I feel people understood what I meant, let me correct
my bad wording for the sake of clarity:
I didn't really mean to contrast GUI vs anything else. Everything I'm
talking about is GUI-stuff.  I meant to separate the interfaces for causing
and indicating folds from all the implicit issues that arise from
the presence or appearance/disapearance of folded blocks.

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:

* 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?

* 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?
  Same with selection from macros.

* 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?

* What happens if, before folding away a block, there is already a
  selection spanning only one of its boundaries?

* 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?

* If 'find' can hit something inside a fold, I suppose it should also
auto-expand it.
  But how about 'replace all'?

* If using multiple panes, folding state is per-pane, right?

* What happens if the cursor is at the first posisble position after a folded
  block and I press backspace?

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.

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.
-- 
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop

Reply via email to