Re: invisible

[Stephen Berman]

Sorry for the late response.

On Sun, 18 Nov 2007 16:27:09 +0100 martin rudalics <address@hidden> wrote:

>>>>(put-text-property 6 7 `invisible t)
>>>>(put-text-property 12 13 `invisible t)
>>>>(put-text-property 18 19 `invisible t)
>>>>(put-text-property 24 25 `invisible t)
>>>>(put-text-property 30 31 `invisible t)
>
> These will cause problems with `forward-line'.
>
> I'd propose to use
>
> (add-text-properties 6 7 '(invisible t rear-nonsticky t))
> (add-text-properties 12 13 '(invisible t rear-nonsticky t))
> (add-text-properties 18 19 '(invisible t rear-nonsticky t))
> (add-text-properties 24 25 '(invisible t rear-nonsticky t))
> (add-text-properties 30 31 '(invisible t rear-nonsticky t))
>
> instead.
>
>>>>C-p beginning of line4.  Why did we skip line5?
>>>>C-p beginning of line2.  Skipped line3.
>
> See above.  Verify by running (forward-line -1) on these.  Your results
> may differ according to the value of `track-eol'.

With the rear-nonsticky property set to t C-p does not skip lines 5 and
3, i.e. it DTRT.  With (forward-line -1) there is also no line skipping,
but this is also the case without setting the rear-nonsticky property to
t, i.e., I see no difference, in contrast to C-p.  The value of
track-eol is nil (the default).  So I am not sure what problems you
mean.

>>>This behavior still exists in GNU Emacs 23.0.50.4 (i686-pc-linux-gnu,
>>>GTK+ Version 2.12.0) of 2007-11-09 on escher.[1]  In addition, starting
>>>with the cursor at (point-min), the line number indicator in the mode
>>>line displays L1, and it continues to display L1 as you advance either
>>>by C-n or by C-f until it reaches the `l' of `line7', then it changes to
>>>L7.  From there if you type C-b moving point to just after `6', the mode
>>>line displays L6.  Now continuing backwards either by C-p or C-b the
>>>mode line usually continues to display L6, even at (point-min).  Typing
>>>C-b again here then changes the display to L1.
>
> We have been discussing this at the beginning of this year but I don't
> recall the thread.  I seem to recall that Emacs tries to optimize line
> number calculations as long as the buffer is not modified.

I don't recall this discussion, but in any case Emacs normally does
update the line number display when the cursor moves to another line,
which does not involve buffer modification, so I don't see why
invisibility should make a difference here.

>> In current development Emacs, the cursor stays put, i.e., C-p is a no-op
>> here; the same goes for every position in line 3, except the beginning
>> of the line: here C-p goes to the beginning of line 1 (the parenthetical
>> comment doesn't make sense, unless it is a typo for line 1, or maybe he
>> means the mode line should display L2 instead of L3, even though the
>> cursor stays put).
>
> This seems like a bug in `line-move-finish', please try the attached
> patch (untested).

With your patch typing C-p, with the cursor at any position in line 3
but the beginning of the line, moves the cursor to the beginning of line
3, i.e., does the same thing as C-a.  I think I would have expected it
to put the cursor on line 1.  (At the beginning of line 3 the behavior
is as before, C-p goes to the beginning of line 1.)

>>>At the beginning of line 3, C-e goes to "i" in line 3.
>>>     (should go to the end of line 3)
>>
>>
>> In current development Emacs, the cursor goes to the end of line 1
>> (anywhere else on line 3, C-e goes to the end of line 3).  On the other
>> hand, C-a at the beginning of line 3 goes to "i" in line 3 (elsewhere it
>> goes to the beginning of the line, so that repeatedly typing C-a
>> starting from the beginning of line 3 makes the cursor oscillate between
>> the first and second columns of the line).
>>
>>
>>>(2) If line-move-ignore-invisible is t:
>>>
>>>At the end of line 1, C-n goes to the beginning of line 3.
>>>     (should go to the end of line 3)
>>>At the end of line 4, C-p goes to the beginning of line 3.
>>>     (should go to the end of line 3)
>>>At the beginning of the line 3, C-e goes to "i" in line 3.
>>>     (should go to the end of line 3)
>
> There's likely also a bug in `line-move-to-column': `move-to-column'
> apparently skips invisible text (I didn't find any documentation for
> that).  I tried to fix it in a really awkward way in the same patch.

Is this patch intended to fix the behavior I described above (2)?  For
that case, if I do as you suggested above and set both invisible and
rear-nonsticky to t, then no patch is needed: with these properties both
C-e and C-a DTRT at all positions.  But leaving rear-nonsticky nil, the
misbehavior remains even with your patch.

Summarizing, it appears that rear-nonsticky should be set to t when a
position is given the invisible property.  In particular,
facemenu-set-invisible should be changed accordingly, otherwise the menu
choice Edit->Text Properties->Special Properties->Invisible admits the
observed motion misbehavior.  (But I don't know if there are other cases
where facemenu-set-invisible should leave the invisible position
rear-sticky.)  This still does not fix the problem with C-p at positions
other than the beginning of the line after an invisible line, but your
patch for that also results in unexpected behavior.

Steve Berman