From xemacs-m  Wed Jan  8 06:00:47 1997
Received: from lemcbed.lem.uni-karlsruhe.de (lemcbed.lem.uni-karlsruhe.de [129.13.103.197])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with SMTP
	  id FAA09368 for <xemacs-beta@xemacs.org>; Wed, 8 Jan 1997 05:59:28 -0600 (CST)
Received: by lemcbed.lem.uni-karlsruhe.de; id AA03212; Wed, 8 Jan 1997 13:01:11 +0100
To: xemacs-beta@xemacs.org
Subject: Re: scrollbars
References: <9701080035.AA12973@euler.alphatech.com> <kigafql5608.fsf@jagor.srce.hr> <x220bwlhpl.fsf@lemcbed.lem.uni-karlsruhe.de> <kigu3osmvl0.fsf@jagor.srce.hr>
X-Face: Z[@OB)("ZvE?ev~1b+b!0ZUB.$%rh.9qE>dVf>q}Q/V?%d`J3gd!LR\aAZ8<Hwi]xTA(:*c;i3,?K?+rCy*^b$)a,}E?eo},}x2]5LlJysyoUOK"o[>K)'\Ulb7y-7*.If^;rHl['oa)n_M7E6w+LDKMs"G8_`c)uOS1^}.1|8Ill]7X68X-paeUOpBhz<F`B0?~^2Et~GYfw~/0]H]nx4~C_E/_mp#^7Ixc:
Reply-To: jens@lemcbed.lem.uni-karlsruhe.de
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
From: Jens Lautenbacher <jens@lemcbed.lem.uni-karlsruhe.de>
Date: 08 Jan 1997 13:01:08 +0100
In-Reply-To: Hrvoje Niksic's message of 08 Jan 1997 09:15:23 +0100
Message-Id: <x2sp4cxtob.fsf@lemcbed.lem.uni-karlsruhe.de>
Lines: 104
X-Mailer: Red Gnus v0.76/XEmacs 19.14

Hrvoje Niksic <hniksic@srce.hr> writes:

> Jens Lautenbacher (jens@lemcbed.lem.uni-karlsruhe.de) wrote:
> > Unfortunately atomic-extents over more than one line are a little bit
> > broken.
> 
> I am not sure I follow you.  Are atomic-extents the right solution
> e.g. for hiding Gnus headers or not?  If they are broken over more
> than one line, they do not seem to be the answer. :-(


'atomic  makes an extent intangible. Together with the 'hidden
attribute they provide for portions of text getting totally out of the
way. (While only 'hidden doesn't provide for the cursor not being able
to enter the hidden area which is very confusing at least)

Consider this:

----->buffer start<-----------------------------------------
123456789012345678901234567890123456789012345678901234567890
         1         2         3         4         5         6 

(progn
  (put-text-property 20 40 'atomic t)
  (put-text-property 10 50 'read-only nil))

------------------------------------------------------------

At the beginning, we don't use read-only. move the cursor in the first
line: everything works as expected: the cursor jumps from 20 to 40, on
can add or delete in the other areas. One can even delete at the front
or from the end of the atomic area. --> first bug:
Assume we have deleted from pos 20 10 chars. The buffer's looking:

----->buffer start<-----------------------------------------
12345678901234567890123456789012345678901234567890
         1         2         3         4         5         6 
                  /\
                  point


moving one char to the right jumps to (now) pos 30 and vice versa.
Ok. but if one uses undo to get all the killed chars back, something
strange is happening (OK, it's not that strange if you know how
extents are handled in XEmacs):

Assume we have undone everything (still sitting at pos 20). Movin to
the right now jumps only two chars until one arrives at pos 30, the
next move gets us to pos 40. Something similar happens with deleteing
backwards from pos 40.

Conclusion: atomic is broken with respect to killing and undoing.
One has to use also read-only to be on a (safer) side.

So we change the read-only to t in the code above. No killing at pos
20 or anywhere inside 10-50 is now possible. Sitting at 9 and deleting
kills only one char, then it give a read-only error. Also trying
kill-line from inside 10-50 doesn't work. Thats fine. But if you use
kill-line from somewhere outside the 10-50 boundary you kill the
complete extent, regardless of read-only or atomic.

Conclusion: It's not only atomic that is broken, it's also read-only
(I know one can argue about that point). 

Next step: The multiline atomic extent:

------>buffer-start<----------------------------------------
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890

(put-text-property 20 223 'atomic t)

------------------------------------------------------------

Moving from the end of line 4 backward shows that everything seems
OK. *BUT:* setting the cursor at the beginning of line 5 and moving up
lets the cursor hang at the end of the atomic area, until you press
one time left, then it jumps to the beginning of the atomic region:

Conclusion: 'atomic is broken with respect to multible lines, as it
doesn't cope with the cursor moving up or down.

I hope I made myself clearer this time. I have statet these bugs many
times now, but it seems that noone is interested in this particular
area. On the other hand I don't have the insight to fix these things
myself. 

At the current state I think that 'atomic is usuable for the gnus
example you stated because everything is bette than having the cursor
lost in an invisible region of text. 

For everything more ambituous, like word processing, there are
currently so many things that are horrible broken (I mentioned the
face code, and extents/textprops are another area which would need
some polishing) that we better don't think about this for a very long
time. As someone (you? don't know and too lazy to search...)
mentioned, it's still impossible to view an inline image if the top of
the line has scrolled upwards out of the visible region. These are the
things that I believe  need to be fixed first :-)

Jens

