Box attribute in mode-line and scrolling

Box attribute in mode-line and scrolling

[Antoine Levitt]

There seems to be a conflict between scrolling and the box attribute in
mode-line. I have in my config a ":box t" attribute in mode-line (from
the theme I use, zenburn.el). With this setting on, C-v M-v produces a
net displacement of one line up, which is annoying. This seems to be
irrespective of settings such as scroll-conservatively or
scroll-preserve-screen-position.

This is a pretty old bug. It might (or might not) be related to
http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00339.html

My understanding of these issues is not sufficient to help debug it, I'm
afraid. Any ideas?

Antoine

Re: Box attribute in mode-line and scrolling

[Juanma Barranquero]

On Sun, Mar 27, 2011 at 13:43, Antoine Levitt <antoine.levitt@gmail.com> wrote:

> There seems to be a conflict between scrolling and the box attribute in
> mode-line. I have in my config a ":box t" attribute in mode-line (from
> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
> net displacement of one line up, which is annoying. This seems to be
> irrespective of settings such as scroll-conservatively or
> scroll-preserve-screen-position.

That doesn't seem like a bug, but the fact that adding the box
enlarges the size of the modeline, and likely the last line of the
window isn't fully displayed.

Does it also happen if, instead of ":box t" you use ":box
'(:line-width -1 :style released-button)"?

    Juanma

Re: Box attribute in mode-line and scrolling

[Antoine Levitt]

27/03/11 14:15, Juanma Barranquero
> On Sun, Mar 27, 2011 at 13:43, Antoine Levitt <antoine.levitt@gmail.com> wrote:
>
>> There seems to be a conflict between scrolling and the box attribute in
>> mode-line. I have in my config a ":box t" attribute in mode-line (from
>> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
>> net displacement of one line up, which is annoying. This seems to be
>> irrespective of settings such as scroll-conservatively or
>> scroll-preserve-screen-position.
>
> That doesn't seem like a bug, but the fact that adding the box
> enlarges the size of the modeline, and likely the last line of the
> window isn't fully displayed.

Yes, that seems to be what's happening. But how is that not a bug? Even
if the last line isn't fully displayed, can't emacs try and figure out a
way to respect the semantics of C-v and M-v cancelling each other out in
the middle of a file?

>
> Does it also happen if, instead of ":box t" you use ":box
> '(:line-width -1 :style released-button)"?

Yup, that fixes it, and even if I don't use :style released-button.

Antoine

Re: Box attribute in mode-line and scrolling

[Antoine Levitt]

27/03/11 14:15, Juanma Barranquero
> On Sun, Mar 27, 2011 at 13:43, Antoine Levitt <antoine.levitt@gmail.com> wrote:
>
>> There seems to be a conflict between scrolling and the box attribute in
>> mode-line. I have in my config a ":box t" attribute in mode-line (from
>> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
>> net displacement of one line up, which is annoying. This seems to be
>> irrespective of settings such as scroll-conservatively or
>> scroll-preserve-screen-position.
>
> That doesn't seem like a bug, but the fact that adding the box
> enlarges the size of the modeline, and likely the last line of the
> window isn't fully displayed.

Yes, that seems to be what's happening. But how is that not a bug? Even
if the last line isn't fully displayed, can't emacs try and figure out a
way to respect the semantics of C-v and M-v cancelling each other out in
the middle of a file?

>
> Does it also happen if, instead of ":box t" you use ":box
> '(:line-width -1 :style released-button)"?

Yup, that fixes it, and even if I don't use :style released-button.

Antoine

Re: Box attribute in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Date: Sun, 27 Mar 2011 13:43:31 +0200
> 
> There seems to be a conflict between scrolling and the box attribute in
> mode-line. I have in my config a ":box t" attribute in mode-line (from
> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
> net displacement of one line up, which is annoying. This seems to be
> irrespective of settings such as scroll-conservatively or
> scroll-preserve-screen-position.

Please report this as a bug (with "M-x reporte-emacs-bug RET") to the
bug tracker, including a full recipe needed to reproduce this starting
with "emacs -Q".  Then someone else could try to reproduce and debug
this.

Re: Box attribute in mode-line and scrolling

[Antoine Levitt]

27/03/11 15:24, Eli Zaretskii
>> From: Antoine Levitt <antoine.levitt@gmail.com>
>> Date: Sun, 27 Mar 2011 13:43:31 +0200
>> 
>> There seems to be a conflict between scrolling and the box attribute in
>> mode-line. I have in my config a ":box t" attribute in mode-line (from
>> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
>> net displacement of one line up, which is annoying. This seems to be
>> irrespective of settings such as scroll-conservatively or
>> scroll-preserve-screen-position.
>
> Please report this as a bug (with "M-x reporte-emacs-bug RET") to the
> bug tracker, including a full recipe needed to reproduce this starting
> with "emacs -Q".  Then someone else could try to reproduce and debug
> this.

Done (and sorry for the double post in this thread, gnus froze and I
didn't know whether the mail was sent or not)

RE: Box attribute in mode-line and scrolling

[Drew Adams]

> > That doesn't seem like a bug, but the fact that adding the box
> > enlarges the size of the modeline, and likely the last line of the
> > window isn't fully displayed.
> 
> Yes, that seems to be what's happening. But how is that not a 
> bug?
> 
> > Does it also happen if, instead of ":box t" you use ":box
> > '(:line-width -1 :style released-button)"?
> 
> Yup, that fixes it, and even if I don't use :style released-button.

This gotcha should be pointed out more clearly in the doc, since the default
behavior increases the height of the current line, which can throw off various
things.

The doc is clear, but it could help to explicitly point out that (a) the default
value's effective :line-width of 1 increases the height of the text line
containing the boxed characters, and that that (b) can automatically lead to a
change the window or frame height because Emacs uses an integral number of
lines.

[If and when the latter is alleviated (there was some talk of making it
pixel-based instead of line-based), the doc can be updated to reflect the
improvement.]

Another possibility, which I would support, would be to change the default
:line-width to -1 instead of 1.  For backward compatibility we probably should
not just reinterpret `t', but we could change the default to `inside', meaning
the same as `t' but with a :line-width of -1.

The following information, necessary to using :box without problems, is not
obvious without studying various parts of the doc (parts that do not cross
reference each other):

1. You can use a negative :line-width, and a positive value always increases the
effective line height.

2. Window height is based on an integral number of text lines.

We would avoid making the user understand all of that just to use boxes, by
changing the default :line-width to -1.

In that case, a user might still wonder how to get a box with the line moved
farther out (analog of #1), but we have doc for that, and that doesn't require
understanding of the details about line height.

Note too that underline and overline face attributes correspond to a box
:line-width of -1, not 1.  At least they appear to on my platform.  Which is why
this line-height gotcha only bites users for :box.

Re: Box attribute in mode-line and scrolling

[Antoine Levitt]

27/03/11 17:06, Drew Adams
>> > That doesn't seem like a bug, but the fact that adding the box
>> > enlarges the size of the modeline, and likely the last line of the
>> > window isn't fully displayed.
>> 
>> Yes, that seems to be what's happening. But how is that not a 
>> bug?
>> 
>> > Does it also happen if, instead of ":box t" you use ":box
>> > '(:line-width -1 :style released-button)"?
>> 
>> Yup, that fixes it, and even if I don't use :style released-button.
>
> This gotcha should be pointed out more clearly in the doc, since the default
> behavior increases the height of the current line, which can throw off various
> things.

Right. That seems to be a different issue though. Even with a larger
mode line, why do the scrolling commands behave this way?

RE: Box attribute in mode-line and scrolling

[Drew Adams]

>> >> There seems to be a conflict between scrolling and the box 
>> >> attribute in mode-line. I have in my config a ":box t"
>> >> attribute in mode-line (from the theme I use, zenburn.el).
>> >> With this setting on, C-v M-v produces a net displacement
>> >> of one line up, which is annoying. This seems to be
>> >> irrespective of settings such as scroll-conservatively or
>> >> scroll-preserve-screen-position.
>> >> 
>> >> This is a pretty old bug. It might (or might not) be
>> >> related to
>> >> http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00339.html
>> >
>> > That doesn't seem like a bug, but the fact that adding the box
>> > enlarges the size of the modeline, and likely the last line of the
>> > window isn't fully displayed.
>> 
>> Yes, that seems to be what's happening. But how is that not a 
>> bug? Even if the last line isn't fully displayed, can't emacs
>> try and figure out a way to respect the semantics of C-v and
>> M-v cancelling each other out in the middle of a file?
>> 
>> > Does it also happen if, instead of ":box t" you use ":box
>> > '(:line-width -1 :style released-button)"?
>> 
>> Yup, that fixes it, and even if I don't use :style released-button.
>>
>> > This gotcha should be pointed out more clearly in the doc, 
>> > since the default behavior increases the height of the
>> > current line, which can throw off various things.
>> >
>> > [And/or let's] change the default :line-width to -1 instead of 1. 
> 
> Right. That seems to be a different issue though. Even with a larger
> mode line, why do the scrolling commands behave this way?

My guess is that it is not a different issue.  As you guessed in citing the
October message (see e.g. the last message in that thread), as Juanma indicated
is likely, and as you seem to have confirmed using the fix he suggested, the
problem for the scrolling commands is also (I'm guessing) the increased
(mode-)line height.

Documenting this unfortunate side effect better, and changing the default so as
to not increase the line height, would (if our guesses are correct) directly
address your issue.