On 10/26/07, Rick DeNatale <rick.denatale / gmail.com> wrote:
> On 10/26/07, James Edward Gray II <james / grayproductions.net> wrote:
> > On Oct 26, 2007, at 8:15 AM, Todd Burch wrote:
> >
> > > James Gray wrote:
> > >> All of the basic operations occur around a text cursor. The minimal
> > >> operations on/at the cursor should be:
> >
> > > Just a terminology thing - the proper term is "caret", not a "text
> > > cursor".
> >
> > While I probably would have called it a caret as well, the term
> > doesn't seem completely out of line:
> >
> >    http://en.wikipedia.org/wiki/Cursor
> >
> >    http://en.wikipedia.org/wiki/Cursor_%28computers%29
>
> Actually, I'd say that caret is a UI/View related term (its the name
> of the ^ character, traditionally used in blue-pencil editing to mark
> a place to insert test.
>
> Cursor is kind of both a view and a model term, and I think we're
> talking about a model in this quiz.

Correct.  I've also seen the term cursor being used with databases
(pointer to what row is being operated on).  It has also been used to
mean the same as what rubyists call an "external iterator" (ruby
mainly uses "internal iterators" or what others might call visitors).

Before mice came on the scene the symbol representing the text
insertion point was also called a "cursor".  I didn't realize that
"cursor" is now mainly used for the mouse now and the text cursor has
been demoted to "caret".  I usually just say "mouse pointer" and "text
cursor".  According to how the term "cursor" is used in data
structures, I think the text cursor/caret deserves to use this term
more than a mouse pointer/cursor does.

> That said, in general, when I've looked at similar code, the analogous
> concept usually used is a selection, which represents a contiguous run
> of zero or more characters within the buffer.  The quiz seems to be
> using a degenerate version of this where the length is constrained to
> be zero.

Don't let the test in this quiz stop you.  I just provided a benchmark
for the simple stuff.  Feel free to implement other text editor
operations in addition to the simple operations that the benchmark
uses.  And don't let the benchmark restrict your API.  If the model
that the benchmark assumes doesn't match your model (i.e. a selection
in your case?), change the benchmark test to what you need.  Also,
achieving the best absolute performance on this benchmark isn't
necessarily the most important, but you should get reasonable big-O
performance.  I'd like to see what data structures some of you come up
with and how far you can take them in terms of functionality.  I think
there are lots of solutions with a variety of data structures.

Have fun!

Eric