Re: invisible

[martin rudalics]

> I'm afraid it did not, which puzzles me in view of the confidence you
> expressed.  I wonder if we did something different again.

Yes and no.  I've been experimenting with a different approach to make
parts of lines invisible.  Everything you did was correct.

I'm afraid the problem cannot be solved satisfactorily without using the
rear-nonsticky property.  In fact the "bug" happens _before_ we can see
it.  Consider the following configuration where the "\n" are visible
newlines, the "(\n)" invisible rear-sticky ones, dots are plain visible
non-newline text, and "^" indicates the position of `point':

.....\n
.....(\n).....(\n).....(\n).....(\n).....\n
^.....\n

C-p now should move to

.....\n
.....(\n).....(\n).....(\n).....(\n)^.....\n
.....\n

but the point-setting in scan_newline really moves to

.....\n
.....(\n).....(\n).....(\n).....^(\n).....\n
.....\n

which _appears_ correct because the newline doesn't appear on screen.
Recall that the point-setting mechanism doesn't permit to position
`point' after the invisible newline because the text property is
rear-sticky.

Hitting C-p again first invokes (forward-line -1) to move `point' to the
beginning of the previous line as

.....\n
.....(\n).....(\n)^.....(\n).....(\n).....\n
.....\n

but the point-setting mechanism in scan_newline again corrects this to

.....\n
.....(\n).....^(\n).....(\n).....(\n).....\n
.....\n

The next C-p gets us to

.....\n
^.....(\n).....(\n).....(\n).....(\n).....\n
.....\n

because we now are after a visible newline and our `goal-column' is
still zero.

I think we first have to specify what we really want and then fix this
accordingly.  I can think of the following alternatives:

(1) Provide for disabling the point adjustment mechanism in
scan_newline.  The disadvantage of this approach is that `point' may
appear after rear-sticky invisible text and doing a self-insert there
won't show the character.

(2) Make self-insertion after rear-sticky invisible (intangible, ...)
text by default _not_ inherit the invisibility property.  Intuitively,
this should do the right thing but the outcome would be different for
not self-inserting commands that try to insert text at `point'.

(3) Use the rear-nonsticky property and live with the fact that
insertions may occur on either end of the invisible text depending on
whether you arrived at the corresponding screen position either by
moving forwards or backwards.  As Stefan said we could ameliorate this
when using ellipses.  However, what should `forward-char' do with
invisible text replaced by an ellipis and `point' immediately before it:

text^...text

Should it go here

text...^text

or here

text...t^ext