Display text property problem

Display text property problem

[Stephen Berman]

I would be very interested to know whether anybody here can reproduce
the following in Emacs 22.1 or CVS Emacs from the trunk. (I also see
something similar in Emacs 21.3, though there the behavior is somewhat
different, due I think to additional bugs that have been fixed in
Emacs 22.)  And I would be especially interested in, and grateful for,
suggestions about how to debug this.

Thanks,
Steve Berman

______________________________________________________________________
1. emacs -Q

2. Type "test " 17 times, i.e., enough to make the line of text longer
than fill-column.

3. Put the cursor on column 70 and type
   `M-: (put-text-property (1- (point)) (point) 'display " \n     ")'
(the display string here is one space + a newline + five spaces, but
it is only important that it contain a newline and a following
character).

Now the buffer displays the following, where `|' marks the left
fringe, and the cursor is still on column 70, indicated by `^':

|test test test test test test test test test test test test test test 
|     test test test 
      ^

4. Type M-: (scroll-up 1); now the buffer displays the following,
where again `|' marks the left fringe, and the cursor is still on
column 70, indicated by `^':

|test test test
 ^

A variant of this bug is seen by doing steps 1-3 and then reducing the
frame height (e.g. by dragging the mouse) one line at a time until the
window contains just one line (plus the mode line and the minibuffer),
at which point the text is displayed as in step 4.
 

Another example:
a. emacs -Q
b. Type " " (i.e., space)
c. Type M-: (put-text-property (1- (point)) (point) 'display "\n***"),
so that the buffer displays this:
|
|***
 ^
d. Now typing M-: (scroll-up 1) yields an "End of buffer" error, but
clicking the down arrow in the scroll bar (at least with the GTK+
toolkit) once makes the "***" disappear and the cursor get vertically
centered in the window.  (If you put the cursor after "***" and then
click the down arrow in the scroll bar, "***" still vanishes but the
cursor is now at the top of the window.)


The first example can also be reproduced with emacs -nw -Q, however,
the resulting display after step 4 is different:
|t test

Re: Display text property problem

[Peter Dyballa]

Am 14.06.2007 um 12:00 schrieb Stephen Berman:

>
> The first example can also be reproduced with emacs -nw -Q, however,
> the resulting display after step 4 is different:
> |t test

With the one week old version from CVS I can't reproduce. For case 1:  
did you try to hit home? For me the first line was scrolled up and  
became invisible, but when reaching the home position, beginning-of- 
buffer, it was still there, nothing was lost.

--
Greetings

   Pete

"Email is a wonderful thing for people whose role in life is to be on  
top of things. But not for me; my role is to be on the bottom of  
things. What I do takes long hours of studying and uninterruptible  
concentration."
                                              -Donald Knuth

Re: Display text property problem

[Stephen Berman]

On Thu, 14 Jun 2007 12:24:44 +0200 Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> With the one week old version from CVS I can't reproduce. For case 1:
> did you try to hit home? For me the first line was scrolled up and
> became invisible, but when reaching the home position, beginning-of- 
> buffer, it was still there, nothing was lost.

Thanks for the feedback, but I think you have misunderstood the
problem I was trying to describe: it's not that the first line
disappears, but that the display property is not correctly displayed
after scrolling.  In fact, in the test case there is only one line
(the line number indicator in the mode line remains L1 throughout),
but the display property makes it look like two lines.  Again, before
scrolling I see this:

|test test test test test test test test test test test test test test 
|     test test test 
      ^

After scrolling, I see this:

|test test test
 ^

but, due to the display property, I had expected to see this:

|     test test test
      ^

This is the problem.  Are you saying you cannot reproduce this?  (As
you point out, hitting HOME brings the "first line" (i.e., the part of
the line before the display property) back into view, and visually
confirms that the display property is still present, but the problem
is that, after scrolling but before hitting HOME, the display property
appears to have vanished.)

Steve Berman

Re: Display text property problem

[Peter Dyballa]

Am 14.06.2007 um 13:10 schrieb Stephen Berman:

> but, due to the display property, I had expected to see this:
>
> |     test test test

I see this in the X client and in Terminal and cannot reproduce what  
you see.

--
Greetings

   Pete

Mac OS X is like a wigwam: no fences, no gates, but an apache inside.

Re: Display text property problem

[Stephen Berman]

On Thu, 14 Jun 2007 13:48:09 +0200 Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> Am 14.06.2007 um 13:10 schrieb Stephen Berman:
>
>> but, due to the display property, I had expected to see this:
>>
>> |     test test test
>
> I see this in the X client

I want to be sure I understand: Do you mean that, after inserting the
text property and scrolling, you see:

|     test test test

and not:

|test test test

That would very much surprise me, as does:

>                            and in Terminal and cannot reproduce what
> you see.

What operating system are you running Emacs on?  (Mine is
i686-pc-linux-gnu, GTK+ Version 2.10.6)

Steve Berman

Re: Display text property problem

[Peter Dyballa]

Am 14.06.2007 um 14:06 schrieb Stephen Berman:

> I want to be sure I understand: Do you mean that, after inserting the
> text property and scrolling, you see:
>
> |     test test test
>
> and not:
>
> |test test test
>
> That would very much surprise me, as does:
>
>>              and in Terminal and cannot reproduce what you see.


Right. Going to describe it as detailed as possible. I am doing my  
tests in ``Text´´ mode buffers.

Terminal
========

After step 3 the cursor is at line #2 column #5 (beginning of word  
test). In mode-line the position is tracked as (1,70), where it was  
before. In the echo are a ``nil´´ has appeared.

After evaluating step 4 nothing changes, except: the echo area now  
contains: ``End of buffer´´.



X client
========

After step 3 the cursor is at line #2 column #5 (beginning of word  
test). In mode-line the position is tracked as (1,70), where it was  
before. In the echo are a ``nil´´ has appeared.

After evaluating step 4 the first line disappears, and so do the  
spaces before the first word ``test´´ in line #2. Mode-line has not  
changed, the echo area contains a ``nil´´. When I now press up GNU  
Emacs makes a quak sound (indicating some error has occurred) and I  
see both lines complete. The cursor is in the first line first  
column. Mode-line shows (1,0).

*Messages* contains:

	nil
	Auto-saving...
	nil


On Mac OS X 10.4.9, and no GTK+!

In GNU Emacs 22.1.50.1 (powerpc-apple-darwin8.9.0, X toolkit, Xaw3d  
scroll bars)
of 2007-06-09 on localhost
Windowing system distributor `The XFree86 Project, Inc', version  
11.0.40400000
configured using `configure  '--without-sound' '--without-pop' '-- 
with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '-- 
enable-locallisppath=/Library/Application Support/Emacs/calendar22:/ 
Library/Application Support/Emacs/caml:/Library/Application Support/ 
Emacs:/sw/share/emacs21/site-lisp/elib' 'CPPFLAGS=-no-cpp-precomp -I/ 
usr/include/openssl -I/sw/include/pango-1.0 -I/sw/lib/freetype219/ 
include -I/sw/lib/freetype219/include/freetype2 -I/sw/lib/fontconfig2/ 
include -I/sw/include/libpng12 -I/usr/local/include -I/sw/include'  
'CXXFLAGS=-no-cpp-precomp -I/usr/include/openssl -I/sw/include/ 
pango-1.0 -I/sw/lib/freetype219/include -I/sw/lib/freetype219/include/ 
freetype2 -I/sw/lib/fontconfig2/include -I/sw/include/libpng12 -I/usr/ 
local/include -I/sw/include' 'LDFLAGS=-dead_strip -L/sw/lib/ 
freetype219/lib -L/sw/lib/fontconfig2/lib -L/sw/lib/ncurses -L/usr/ 
local/lib -L/sw/lib' 'CFLAGS=-pipe -bind_at_load -fPIC -mcpu=7450 - 
mtune=7450 -fast -mpim-altivec -ftree-vectorize -foptimize-register- 
move -freorder-blocks -freorder-blocks-and-partition -fthread-jumps - 
fpeephole -fno-crossjumping''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   locale-coding-system: utf-8
   default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: identity


--
Greetings

   Pete

Remember: use logout to logout.

Re: Display text property problem

[Stephen Berman]

On Thu, 14 Jun 2007 14:50:11 +0200 Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> Right. Going to describe it as detailed as possible. I am doing my
> tests in ``Text´´ mode buffers.

Thanks for the detailed feedback!

> Terminal
> ========
>
> After step 3 the cursor is at line #2 column #5 (beginning of word
> test). In mode-line the position is tracked as (1,70), where it was
> before. In the echo are a ``nil´´ has appeared.
>
> After evaluating step 4 nothing changes, except: the echo area now
> contains: ``End of buffer´´.

I can only reproduce this (your last sentence), if I do `M-:
(scroll-up)' (same as pressing the NEXT (Page Down) key).  When I
instead do `M-: (scroll-up 1), I get what I reported in my OP (but I
neglected to add that, with emacs -Q -nw, after step 4 the cursor is
now at column 83 instead of 70).

> X client
> ========
>
> After step 3 the cursor is at line #2 column #5 (beginning of word
> test). In mode-line the position is tracked as (1,70), where it was
> before. In the echo are a ``nil´´ has appeared.
>
> After evaluating step 4 the first line disappears, and so do the
> spaces before the first word ``test´´ in line #2. Mode-line has not
> changed, the echo area contains a ``nil´´. When I now press up GNU
> Emacs makes a quak sound (indicating some error has occurred) and I
> see both lines complete. The cursor is in the first line first
> column. Mode-line shows (1,0).

OK, this is just what I originally described, except that I hear the
beep only if I press PageUp a second time, which is just Emacs
signalling that the invocation of scroll-up was a no-op, since the
beginning of the buffer is already visible.

> *Messages* contains:
>
> 	nil
> 	Auto-saving...
> 	nil
>
>
> On Mac OS X 10.4.9, and no GTK+!

Maybe there's a difference in the terminal version under Mac OSX, if
you really did (scroll-up 1) and not (scroll-up).  Otherwise, you've
confirmed the display bug, at least under X.  So now it remains to
figure out how to fix it...

Steve Berman

Re: Display text property problem

[Peter Dyballa]

Am 14.06.2007 um 15:38 schrieb Stephen Berman:

>> Terminal
>> ========
>>
>> After step 3 the cursor is at line #2 column #5 (beginning of word
>> test). In mode-line the position is tracked as (1,70), where it was
>> before. In the echo are a ``nil´´ has appeared.
>>
>> After evaluating step 4 nothing changes, except: the echo area now
>> contains: ``End of buffer´´.
>
> I can only reproduce this (your last sentence), if I do `M-:
> (scroll-up)' (same as pressing the NEXT (Page Down) key).  When I
> instead do `M-: (scroll-up 1), I get what I reported in my OP (but I
> neglected to add that, with emacs -Q -nw, after step 4 the cursor is
> now at column 83 instead of 70).

Doing the test in xterm version XFree86 4.3.99.903(184), it happens  
that after (scroll-up 1) only one ``test´´ word is left visible, the  
last one of line #2. Pressing up then plays a sound and shows  
everything ...

--
Greetings
                                  <]
    Pete      o        __o         |__    o           recumbo
     ___o    /I       -\<,         |o \  -\),-%       ergo sum!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________

Re: Display text property problem

[Peter Dyballa]

Am 14.06.2007 um 15:38 schrieb Stephen Berman:

> (but I
> neglected to add that, with emacs -Q -nw, after step 4 the cursor is
> now at column 83 instead of 70)

Oops, forgot to mention: mode-line is updated to (1,79). *Messages*  
contains:

nil [2 times]
Auto-saving...

--
Greetings

   Pete

A morning without coffee is like something without something else.