emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lispref/text.texi


From: Andreas Roehler
Subject: Re: lispref/text.texi
Date: Sun, 02 Jul 2006 20:21:10 +0200
User-agent: Thunderbird 1.5.0.4 (X11/20060516)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]