gnus-auto-center-summary off-center

gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At least for me, gnus-auto-center-summary started going off-center by one
line around 0.84, and I have finally gotten annoyed enough at it to
complain :).  Has anyone else seen this?  I am not doing anything with
Gnus buffer configuration.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.10 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3vMNigl+vIlSVSNkRAlQaAJwL/28alsvHiNljrxwEqCqFxWKoMgCg8CCE
YjI4q3B9Yv1NAFuBWZmrIjM=
=XupW
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW, summary centering is still off with pGnus 0.96.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.10 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3xzVTgl+vIlSVSNkRAjtaAJ98JuUSgTTPCKAiKyk93WMWuA4sswCgnaJj
pNqFVnTnoZeytkTJV79oZho=
=019K
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 

Re: gnus-auto-center-summary off-center

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> FWIW, summary centering is still off with pGnus 0.96.

Off in what way?  I still get point on the third line from the top,
like I've always had...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Lars Magne Ingebrigtsen <larsi@gnus.org>  on Fri, 24 Sep 1999
| Off in what way?  I still get point on the third line from the top,
| like I've always had...

If I have a 5-line summary buffer and the group has 5 messages in it (5
summary lines), when I select the 3rd or latter messages, Gnus scrolls the
buffer up 1 line so that only four summary lines are displayed and a blank
line above the buffer's mode line.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE36+Fugl+vIlSVSNkRAgOAAKDFSgrTDFO6/br0LgV+jAU167ckfQCdF1XV
h0CMR1H1sf7HsYKjZG9VsOc=
=sj4r
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: gnus-auto-center-summary off-center

[Shenghuo ZHU]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 * Lars Magne Ingebrigtsen <larsi@gnus.org>  on Fri, 24 Sep 1999
 | Off in what way?  I still get point on the third line from the top,
 | like I've always had...

Rat> If I have a 5-line summary buffer and the group has 5 messages in
Rat> it (5 summary lines), when I select the 3rd or latter messages,
Rat> Gnus scrolls the buffer up 1 line so that only four summary lines
Rat> are displayed and a blank line above the buffer's mode line.

In XEmacs, that's a hard part. A summary buffer may include characters
of different font sizes. Therefore, it is difficult to predict how
many lines can be displayed in the buffer window. If Gnus predicts a
greater number than the number of lines can actually be displayed, the
cursor (the current line) may be scroll out of the summary buffer
window, then the cursor is located to a weird place (another line in
the window). Now, Gnus predicts a bit smaller number, so a blank line
may be displayed in the summary buffer.

In GNU Emacs, there is no such problem.

-- 
Shenghuo ZHU

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Shenghuo ZHU <zsh@cs.rochester.edu>  on Fri, 24 Sep 1999
| Now, Gnus predicts a bit smaller number, so a blank line may be displayed
| in the summary buffer.

Does Gnus use `window-displayed-height' in this calculation instead of
window-height?  It should.  At least as far as XEmacs is concerned, use
window-height for geometry calculations and window-displayed-height to get
the actual number of lines of text displayed in the window -- regardless of 
variable text sizes.

What function is responsible for this prediction?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE37AsSgl+vIlSVSNkRAtkYAJ0doQS4Iaj547glfU/TMNh7PyUhVQCggg7g
Zvv5Bf02GPJ7GoPUUDLTYqM=
=0yZ/
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: gnus-auto-center-summary off-center

[Shenghuo ZHU]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

Rat> * Shenghuo ZHU <zsh@cs.rochester.edu>  on Fri, 24 Sep 1999
Rat> | Now, Gnus predicts a bit smaller number, so a blank line may be displayed
Rat> | in the summary buffer.

Rat> Does Gnus use `window-displayed-height' in this calculation
Rat> instead of window-height?  It should.  At least as far as XEmacs
Rat> is concerned, use window-height for geometry calculations and
Rat> window-displayed-height to get the actual number of lines of text
Rat> displayed in the window -- regardless of variable text sizes.

Yes, it is used. 

Rat> What function is responsible for this prediction?

gnus-xmas-summary-recenter in gnus-xmas.el.

-- 
Shenghuo ZHU

Re: gnus-auto-center-summary off-center

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> In XEmacs, that's a hard part. A summary buffer may include characters
> of different font sizes. Therefore, it is difficult to predict how
> many lines can be displayed in the buffer window. 

Yup.  I've now altered `gnus-xmas-summary-recenter' to show one more
line, though, and we'll see how that goes.  I have a feeling that it
might lead to some people getting a half-chopped-off line, but for me, 
right now, it displays fine.

We'll see after 0.97 whether it's a success or not.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-auto-center-summary off-center

[Shenghuo ZHU]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
>> In XEmacs, that's a hard part. A summary buffer may include characters
>> of different font sizes. Therefore, it is difficult to predict how
>> many lines can be displayed in the buffer window. 

LMI> Yup.  I've now altered `gnus-xmas-summary-recenter' to show one
LMI> more line, though, and we'll see how that goes.  I have a feeling
LMI> that it might lead to some people getting a half-chopped-off
LMI> line, but for me, right now, it displays fine.

LMI> We'll see after 0.97 whether it's a success or not.  :-)

Not a success.

The half-chopped-off line causes the problem in XEmacs. 

Suppose the current line be the last line. When enter the news, the
line is half chopped off, then the cursor move to the center of the
window, while the line is still in the bottom of the window and
half-chopped-off. This is the reason why I remove one line in 0.89.

-- 
Shenghuo ZHU

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Shenghuo ZHU <zsh@cs.rochester.edu>  on Mon, 27 Sep 1999
| The half-chopped-off line causes the problem in XEmacs.

What I think is happening is that the mode line bezel makes the mode line
"taller" than a line of text.  XEmacs laps the bezel over the buffer text,
producing your "half-chopped-off line".  This is not a bug, it is normal
and correct behaviour for XEmacs.  When you select the last message in the
summary buffer, XEmacs scrolls up the entire window by 1 line so that the
full text of the line is displayed without being cropped.

What happens if you reduce the size of the mode line bezel to 0 with
`(set-specifier modeline-shadow-thickness 0)'?  This will make XEmacs' mode 
lines look like FSF Emacs mode lines and should make the cropping problem
go away.

I normally use XEmacs without mode line bezels.  Your "fix" really screws
up the display, I am sorry to say.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE38CZQgl+vIlSVSNkRApjHAJwOO61i4f6RDVP9r0IND0XM8MQkOQCgpDWO
qLsjCVnwPxg4Cs/Spzi0Qyw=
=GkPj
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Stainless Steel Rat <ratinox@peorth.gweep.net>  on Mon, 27 Sep 1999
| I normally use XEmacs without mode line bezels.  Your "fix" really screws
| up the display, I am sorry to say.

Just following up on my own post as I realized it as I was about to shut
down for the night.  This also applies to XEmacs running in a terminal
(xterm, rxvt, Linux console, whatever) rather than in its own window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE38Cy/gl+vIlSVSNkRAtd+AJ4hAz00DCs6O/9xdn+rEtPMFUVbFQCgkpcn
7BRGYjB2MQBQFIimUuRLaZA=
=1F7o
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.

Re: gnus-auto-center-summary off-center

[Shenghuo ZHU]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

Rat> What I think is happening is that the mode line bezel makes the
Rat> mode line "taller" than a line of text.  XEmacs laps the bezel
Rat> over the buffer text, producing your "half-chopped-off line".
Rat> This is not a bug, it is normal and correct behaviour for XEmacs.
Rat> When you select the last message in the summary buffer, XEmacs
Rat> scrolls up the entire window by 1 line so that the full text of
Rat> the line is displayed without being cropped.

Rat> What happens if you reduce the size of the mode line bezel to 0
Rat> with `(set-specifier modeline-shadow-thickness 0)'?  This will
Rat> make XEmacs' mode lines look like FSF Emacs mode lines and should
Rat> make the cropping problem go away.

Rat> I normally use XEmacs without mode line bezels.  Your "fix"
Rat> really screws up the display, I am sorry to say.

Unfortunately, it is not the case. The mode line bezel does not make
Gnus get wrong answer. In XEmacs, Gnus use `window-displayed-height'
to calculate the height of the window. I guess
`window-displayed-height' has count the thickness of the mode line
bezel. And I never said it is a bug of XEmacs.

But, it is the *displayed* height. When Gnus scrolls the summary
lines, some lines leaves the windows, and other lines enter. Then the
window-displayed-height may change, since the font size of lines may
be different. In the case that the last line is the current line, Gnus
may scroll it half-chopped-off or even out of the window.  This is the
bug I tried to fix.

-- 
Shenghuo ZHU

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Shenghuo ZHU <zsh@cs.rochester.edu>  on Tue, 28 Sep 1999
| But, it is the *displayed* height. When Gnus scrolls the summary lines,
| some lines leaves the windows, and other lines enter. Then the
| window-displayed-height may change, since the font size of lines may be
| different.  In the case that the last line is the current line, Gnus may
| scroll it half-chopped-off or even out of the window.  This is the bug I
| tried to fix.

This is not actually a bug, per se.  It is a side effect of counting lines
where the size of a line is not a constant.

How about this: when a message is selected, compare window-displayed-height 
to window-height.  If they differ significantly enough, shrink or enlarge
the summary buffer window so that it displays the correct number of summary 
lines.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE38NTOgl+vIlSVSNkRAsqMAKC7ZDA+H/S3v1ZUM7813DgwNCy23ACdFp8i
309RKFnA14w2A/5gDfmR8P0=
=tieA
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.

Re: gnus-auto-center-summary off-center

[Jan Vroonhof]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | But, it is the *displayed* height. When Gnus scrolls the summary lines,
> | some lines leaves the windows, and other lines enter. Then the
> | window-displayed-height may change, since the font size of lines may be
> | different.  In the case that the last line is the current line, Gnus may
> | scroll it half-chopped-off or even out of the window.  This is the bug I
> | tried to fix.
> 
> This is not actually a bug, per se.  It is a side effect of counting lines
> where the size of a line is not a constant.

It a side effect of counting lines where one should deal with pixels.
Note that XEmacs 21.2 contains an experimental partial scrolling of
the top line which could make this even worse. (The partial scrolling
is to deal with the Pictures larger than window issue).

What I don't understand is: what is wrong with calling 'recenter' or
'center-to-window-line'?

Jan

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Jan Vroonhof <vroonhof@math.ethz.ch>  on Wed, 29 Sep 1999
| What I don't understand is: what is wrong with calling 'recenter' or
| 'center-to-window-line'?

When there is variable height text in the summary buffer, the last line of
the buffer is clipped by the mode line.  The current "fix" for this problem 
causes the entire summary buffer to be pushed up one line so that the last
line is not clipped -- but when text and mode line all have the same
height, causes the buffer not to be centered correctly when centering is
invoked.  That is why I think when centering is performed the summary
buffer should be resized so that displayed height and pixel height match.
This way, clipping is avoided and "push up" is likewise avoided.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE38kHzgl+vIlSVSNkRAq5jAKDcTNX8zfxr4Gr8bvwANdeMnZaKgQCdGNuM
iL4IG1tl9o5LtT+J7jccN/8=
=ONrd
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.

Re: gnus-auto-center-summary off-center

[Lars Magne Ingebrigtsen]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> What I don't understand is: what is wrong with calling 'recenter' or
> 'center-to-window-line'?

The thing that's, er, in dispute here is not how to actually update
the window, but how to compute which line we want to center on.

We want to have two lines above point, if we are not at the end of the 
buffer, and then we want to just let point go down to the line it
would naturally be on.  If you get my drift.

The problem is with half-cut-off lines, and the "go down to the line"
part.  In some cases, the current algorithm seems to miscompute
something somewhere (or XEmacs is not forthright in its information;
it's a somewhat obscure problem), and when typing `M-> SPC' (or the
like), point will jump up to the middle of the buffer, leaving the
user very confused.

Or to put it more succinctly -- when skipping to the final line, and
the final line is displayed in a half-cut-off fashion, something will
miscompute.  Shenghou's fix makes this problem go away, but at the
price of showing a half-blank line, always, at the bottom of the
summary buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-auto-center-summary off-center

[Jan Vroonhof]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | What I don't understand is: what is wrong with calling 'recenter' or
> | 'center-to-window-line'?
> 
> When there is variable height text in the summary buffer, the last line of
> the buffer is clipped by the mode line.  The current "fix" for this problem 
> causes the entire summary buffer to be pushed up one line so that the last
> line is not clipped

Sorry for being dense, but it what way does that answer my question.
The XEmacs C version of recenter and friends are aware of the all the
actual line heights so why not use them?

Jan

Re: gnus-auto-center-summary off-center

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Jan Vroonhof <vroonhof@math.ethz.ch>  on Thu, 30 Sep 1999
| Sorry for being dense, but it what way does that answer my question.
| The XEmacs C version of recenter and friends are aware of the all the
| actual line heights so why not use them?

I do not know that pGnus does not use them, so I guess I cannot answer this 
one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE386+Tgl+vIlSVSNkRAin3AKDckscWyFbJE9ZjqNxawNeI2kWxXwCeP7eD
iJj0QtP2r6VDz5FKrijZvJ4=
=6zrG
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: gnus-auto-center-summary off-center

[Jan Vroonhof]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | Sorry for being dense, but it what way does that answer my question.
> | The XEmacs C version of recenter and friends are aware of the all the
> | actual line heights so why not use them?
> 
> I do not know that pGnus does not use them, so I guess I cannot answer this 
> one.

I was hoping Larsi or Shengo could answer that.

Jan

Re: gnus-auto-center-summary off-center

[Shenghuo ZHU]

>>>>> "ZSH" == Shenghuo ZHU <zsh@cs.rochester.edu> writes:

ZSH> In XEmacs, that's a hard part. A summary buffer may include
ZSH> characters of different font sizes. Therefore, it is difficult to
ZSH> predict how many lines can be displayed in the buffer window. If
ZSH> Gnus predicts a greater number than the number of lines can
ZSH> actually be displayed, the cursor (the current line) may be
ZSH> scroll out of the summary buffer window, then the cursor is
ZSH> located to a weird place (another line in the window). Now, Gnus
ZSH> predicts a bit smaller number, so a blank line may be displayed
ZSH> in the summary buffer.

ZSH> In GNU Emacs, there is no such problem.

Actually, there is a bug in gnus-auto-center-summary in both GNU Emacs
and XEmacs.  In newsgroups with long summary lines, such as clari.ALL,
when I turn lines truncation on (`gnus-summary-toggle-truncation'),
the cursor may leave the current summary line, if I enter last few
messages.

-- 
Shenghuo ZHU