🚀 go-pugleaf

VERSION:  Epoch 4.2, but the same held for Epoch 4.x, not sure about 3.x

on an SGI Iris running Irix 4.0.x (not really important, I think
this should happen on any architecture)


The problem we are having here is that when you scroll-down
(i.e. M-v) the following happens:

     In Emacs:
      - move back by one "height of window" (height) number of lines
      - the cursor is left at the last visible line in the window
      - can continue this until you are at the beginning at which time
        your cursor is on line height (or height minus one)
        AND the first line in the file is at the top of the window

     In Epoch:
      - move back by one "height of window" (height) number of lines
      - the cursor is left at the last visible line in the window
      - the function layout_window() then RECENTERS that line to the
        middle of the window.
      - continue this scrolling by height lines until you are at the
	beginning at which point your cursor is on line "height"
        BUT that line has now been recentered leaving the first
	height/2 lines perpetually unreachable using scroll-down

The problem (IMHO) is the call to vmotion() from this line in layout_window()
in xdispepoch.c:

 recenter:
  /* Find a start position which centers point */
  pos = *vmotion (point, - height / 2, hscroll, window);

unfortunately recenter can be gotten to from a bunch of different
places and so the solution is not that simple.

Enclosed is the backtrace of the undesirable call to vmotion() from an
epoch started with:

   ./epoch -geometry 80x23 button.c

and no minibuffer attached (so that you can make sense of the height
parameter).


(gdb) bt
#0  vmotion (from=1169, vtarget=-11, hscroll=0, window=336010248)
    at indent.c:994
#1  0x4260b8 in layout_window (window=336010248, just_this_one=1)
    at xdispepoch.c:1461
#2  0x424558 in redisplay () at xdispepoch.c:952
#3  0x4377f8 in read_command_char (commandflag=1) at keyboard.c:1015
#4  0x438454 in read_key_sequence (keybuf=0x7fffc3fc "\evÅX\005\b;l",
    bufsize=30, prompt=0x0, nodisplay=0) at keyboard.c:1563
#5  0x436cd0 in command_loop_1 () at keyboard.c:682
#6  0x4693a4 in internal_condition_case (bfun=0x436a90 <command_loop_1>,
    handlers=17234192, hfun=0x4364b0 <cmd_error>) at eval.c:1018
#7  0x4368a8 in command_loop_2 () at keyboard.c:553
#8  0x468cdc in internal_catch (tag=17234172, func=0x436884 <command_loop_2>,
    arg=17233932) at eval.c:826
#9  0x436848 in command_loop () at keyboard.c:535
#10 0x4363f0 in recursive_edit_1 () at keyboard.c:420
#11 0x436364 in Frecursive_edit () at keyboard.c:402
#12 0x435b28 in main (argc=5, argv=0x7fffc71c, envp=0x7fffc734) at emacs.c:565
(gdb) quit


Could anyone out there give me a hand in making this go away?  Hasn't
anyone been driven insane by this?


lonnie

(lonhyn@nas.nasa.gov)



-- 
        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
       Email to: lonhyn@gulag.nas.nasa.gov     Human at: 415-604-3989
        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

In article <1992Nov12.222638.2886@nas.nasa.gov> lonhyn@gulag.nas.nasa.gov (Lonhyn T. Jasinskyj) writes:


   VERSION:  Epoch 4.2, but the same held for Epoch 4.x, not sure about 3.x

   on an SGI Iris running Irix 4.0.x (not really important, I think
   this should happen on any architecture)


   The problem we are having here is that when you scroll-down
   (i.e. M-v) the following happens:

	In Emacs:
	 - move back by one "height of window" (height) number of lines
	 - the cursor is left at the last visible line in the window
	 - can continue this until you are at the beginning at which time
	   your cursor is on line height (or height minus one)
	   AND the first line in the file is at the top of the window

	In Epoch:
	 - move back by one "height of window" (height) number of lines
	 - the cursor is left at the last visible line in the window
	 - the function layout_window() then RECENTERS that line to the
	   middle of the window.
	 - continue this scrolling by height lines until you are at the
	   beginning at which point your cursor is on line "height"
	   BUT that line has now been recentered leaving the first
	   height/2 lines perpetually unreachable using scroll-down



I just experienced a very similar problem on my Sun Sparc, so the
problem doesn't rest in the Iris.  The problem doesn't happen in all
my epoch incarnations, only in this one "application" that I've built
on top of epoch.  By application, I mean a great big bunch of elisp
code.

I get the undesired recentering of the window as I scroll with
(scroll-down 1).  In the application that has the problem, I can
easily produce the effect by binding that to a key such as
(local-set-key "\M-n" '(func () (scroll-down 1)) and invoking [M-n]
when the cursor is on the bottom line of the window.  You have to be
partway through a file that is bigger than the window, of course.


OK, I've now tracked down the problem in my application.  Scroll-down
breaks when I have fonts of two different sizes on the mode line!
My app highlights the file name in the mode line using modeline
styles, and I only have this problem when I mix fonts on the modeline.

This may not be the real true and only problem, but it solved my
problem and sure is a big hint!





--
B<   Brian Kahn   blk@mitre.org   "may the farce be with you"