Re: lispref/text.texi

[Andreas Roehler]

Thien-Thi Nguyen schrieb:
> Andreas Roehler <address@hidden> writes:
>
>   
> > "Keep in mind that point is always between two
> > characters, and the cursor appears on the character
> > after point."
> >
> > Given the group of users indicated, I fear a certian
> > danger of distraction and/or confusion from it.
> >     
>
> if we drop this, we will see more questions than now;
> more confusion arises from forgetting this detail,
> which properly can be considered as relating to the
> design of emacs, not just its implementation.
>
> anyway, the "group of users indicated" is people who
> wish to program emacs using emacs lisp, for which even
> a small bit of implementation detail can sometimes be
> considered as design detail.  (they are more likely to
> blur the line, being programmers, and thus Confused By
> Choice.)
>
> i will look at text.texi this week, as well, starting
> from the end and working backwards (but "accumulating"
> forwards :-).
>
> thi

So maybe we will meet somewhere in the middle of text.texi. :)

OK. To be serious: Will reflect this further. In any
case it seems nothing to be done quickly before the
release.

Just let me - while reading forward this day - give a
more detailed description of this question (a suspected
intermix of meanings of `current', `at', `before' and
`after') nonetheless.

;;;

Let's see the description of `(point)':
...

"Return value of point, as an integer."

Assume we got a value of 10.

If we now speak of an integer `beyond' that value,
everyone would think of 11, 12 and so on.

AFAIU `beyond' excludes the present. If we are here, we
are not `beyond'.

Now reading the text.texi:

Docu `split-line' declares: This command splits the
   current line, moving the portion of the line after
   point down.

Here is mentioned `after point' i.e. indeed
`beyond'. So if (point) returned 10, I would assume pos
with value 11 is affected.

But what happens at the visual scene?: Just the char
the point is on - the char whose position-value was
returned by `(point)' - i.e. 10 in this example - is
moved by `split-line.'

I assume there are reasons to put it that way and also
that there is no way to have all the benefits of this
world united.

Nonetheless I'm dreaming of a text-editing-world where

`before' means `before visible point', the position
lower than the value returned of (point)

`after' a position greater than the value returned
of (point)

while `at' means just the position/char the
visible point (cursor) is on.

__
Andreas Roehler

PS. Would be great to see an example where the point
being in reality before the shown position matters - as
far as text-editing functions are concerned.

(As already written, my idea was to exclude that from
this level or docu-part, but may be wrong here.)