bug in frame-width

bug in frame-width

[Luc Teirlinck]

I believe the following is an outright bug.

Do `emacs -q &'

ELISP> (frame-width)
80

Indeed, exacly 80 characters fit on the screen.

ELISP> (fringe-mode 0)
nil

Now 83 characters fit on the screen.  But we still get:

ELISP> (frame-width)
80

Unless there is something I completely fail to understand, that should
be 83.

Sincerely,

Luc.

Re: bug in frame-width

[Richard Stallman]

    Indeed, exacly 80 characters fit on the screen.

    ELISP> (fringe-mode 0)
    nil

    Now 83 characters fit on the screen.  But we still get:

    ELISP> (frame-width)
    80

Can you debug it and fix it?

Re: bug in frame-width

[Luc Teirlinck]

Richard Stallman wrote:

       Indeed, exacly 80 characters fit on the screen.

       ELISP> (fringe-mode 0)
       nil

       Now 83 characters fit on the screen.  But we still get:

       ELISP> (frame-width)
       80

   Can you debug it and fix it?

The problem is that the bug does not seem to be in `fringe-mode', but
in parts of the C code that are supposed to resize X windows.  I am
not very familiar with that stuff.

The problem is that if I use `modify-frame-parameters' to change the
`left-fringe' or `right-fringe' parameters, then (frame-width)
actually _should_ stay the same, but the X window should narrow or
broaden.  This does not happen.

Note, by contrast, that if I use `modify-frame-parameters' to change
`menu-bar-lines', then the X window _does_ grow smaller or taller.

Sincerely,

Luc.

Re: bug in frame-width

[Stefan]

> The problem is that if I use `modify-frame-parameters' to change the
> `left-fringe' or `right-fringe' parameters, then (frame-width)
> actually _should_ stay the same, but the X window should narrow or
> broaden.  This does not happen.

The general rule of thumb in X11 is that an application should only change
its window's position and size if the user explicitly asks for it.  When the
user asks to change the fringe, she does not request a change in the
window's size, so frame-width should change so that the window's pixel
size stays constant, not the other way around.

> Note, by contrast, that if I use `modify-frame-parameters' to change
> `menu-bar-lines', then the X window _does_ grow smaller or taller.

Yes, it's been that way for a while, but I think it's bad behavior.


        Stefan

Re: bug in frame-width

[Jan D.]

>> The problem is that if I use `modify-frame-parameters' to change the
>> `left-fringe' or `right-fringe' parameters, then (frame-width)
>> actually _should_ stay the same, but the X window should narrow or
>> broaden.  This does not happen.
>
> The general rule of thumb in X11 is that an application should only 
> change
> its window's position and size if the user explicitly asks for it.  
> When the
> user asks to change the fringe, she does not request a change in the
> window's size, so frame-width should change so that the window's pixel
> size stays constant, not the other way around.

I would not say that it is a rule of thumb.  After all, xterm resizes 
itself
when the scroll bar is enabled/disabled.  Also, changing font size does
resize the window to keep number of rows and columns the same in both
xterm and Emacs.  However, as you point out, Emacs is inconsistent in
how it deals with this.  I for one would prefer if Emacs always tried
to keep the number of rows and columns the same.  We should agree on
the desired strategy (keep rows/columns or keep frame width/height) for
Emacs before fixing things like this.

	Jan D.

Re: bug in frame-width

[Stefan Monnier]

>> The general rule of thumb in X11 is that an application should only change
>> its window's position and size if the user explicitly asks for it.
> I would not say that it is a rule of thumb.

True, it's more of a convention about what a good UI should do.
Another such convention is not to move the mouse pointer unless it's
*really* The Right Thing to do.

> After all, xterm resizes itself when the scroll bar is enabled/disabled.
> Also, changing font size does resize the window to keep number of rows and
> columns the same in both xterm and Emacs.

Yes, it's a convention that is not always followed.  I consider most if not
all of those counter examples as bugs.

Some people sometimes follow the convention that "the geometry as given by
the -geometry parameter should be preserved", i.e. in xterm and Emacs the
number of lines/columns should be preserved rather than the pixel size of
the window.

IMNSHO, at startup, the -geometry argument should take precedence of course
(after all, it's not a question of changing the size but of setting the
initial size), but after the initial setup, any request to change some
aspect of the window other than its size should not change its size.

For Emacs that implies that we should distinguish fringe-changes made in the
.emacs from those made later.


        Stefan

Re: bug in frame-width

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> After all, xterm resizes itself when the scroll bar is enabled/disabled.
>> Also, changing font size does resize the window to keep number of rows and
>> columns the same in both xterm and Emacs.
>
> Yes, it's a convention that is not always followed.  I consider most if not
> all of those counter examples as bugs.

I would find it annoying when increasing the font size in xterm would
cause it to lose columns.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bug in frame-width

[Miles Bader]

On Thu, Aug 12, 2004 at 11:36:10AM -0400, Stefan Monnier wrote:
> >> The general rule of thumb in X11 is that an application should only change
> >> its window's position and size if the user explicitly asks for it.
> > I would not say that it is a rule of thumb.
> 
> True, it's more of a convention about what a good UI should do.

The term "good UI" is so vague as to be meaningless -- there are many
different sorts of UIs, each of which has its particular constraints; xterm
is very different from say, a typical icon-laden file-browser window.

It's probably reasonable to say "don't resize the window without a good
reason" though.  In xterm's case, there _is_ a very good reason, and emacs is
arguably enough like xterm in this respect that it should follow in many
cases.

The key thing about xterm (and perhaps emacs) is that the number of colums is
usually important, and should remain constant when the fontsize changes, and
regardless of decorations being added to the sides.  In emacs's case, it
could be said that the number of _rows_ is less important, but I suppose it's
probably too confusing to have different rules for X and Y dimensions.

[Yeah I know, there are people like you who use 500-column wide emacs
windows, and probably don't care about the numberm of columns remaining
constant -- but I'd say that's a vanishingly small proportion of the
user-base; most people seem to use 80 column windows.]

I perfectly agree that the resizing the frame is quite ugly and annoying in
some cases, but regardless, it's important that certain constraints like
number of columns are maintained.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: bug in frame-width

[Paul Pogonyshev]

Stefan wrote:

> > The problem is that if I use `modify-frame-parameters' to change the
> > `left-fringe' or `right-fringe' parameters, then (frame-width)
> > actually _should_ stay the same, but the X window should narrow or
> > broaden.  This does not happen.
> 
> The general rule of thumb in X11 is that an application should only change
> its window's position and size if the user explicitly asks for it.  When the
> user asks to change the fringe, she does not request a change in the
> window's size, so frame-width should change so that the window's pixel
> size stays constant, not the other way around.
> 
> > Note, by contrast, that if I use `modify-frame-parameters' to change
> > `menu-bar-lines', then the X window _does_ grow smaller or taller.
> 
> Yes, it's been that way for a while, but I think it's bad behavior.

I agree absolutely.  Emacs should not touch window size when it
shows/hides its widgets.

I have this in my `~/.Xdefaults':

Emacs.menuBar:		off
Emacs.toolBar:		0
Emacs.geometry:		139x54+0+0

because I don't need the menu and the toolbar, but if I hide them
from `~/.emacs', then Emacs'es window size changes and that is very
annoying.  And, btw, I'm not satisfied with the above solution
because it is extremely non-obvious, was very difficult to find and
there is high chance that I forget to preserve `~/.Xdefaults'
contents when upgrading my system next time.

Paul

Re: bug in frame-width

[Luc Teirlinck]

Stefan Monnier wrote:

   When the user asks to change the fringe, she does not request a
   change in the window's size, so frame-width should change so that
   the window's pixel size stays constant, not the other way around.

When the user asks to change a parameter and does not ask to change
any other parameters, the other parameters should stay constant.  That
is logical, expected and as documented.  To keep the width parameter
constant, the size of the X window has to change.  If this would be
considered bad behavior, then the meaning of the width parameter
should be changed to refer to the size of the X window.  The same
holds for the height parameter.

Currently, `width' refers to the number of text columns, `height'
includes the tool bar but not the menu bar.  Any changes in current
situation, even those we agree on it, seem to have to wait until after
the 21.4 release.  In the current situation, changing the fringe width
should keep the number of text columns constant.

I personally do not believe that it is _just_ "in the current
situation".  In as far as the width is concerned I believe that it
_should_ refer to actual text columns.  If the number of columns
changes from the 80 I am used to, even to to 79 or 81, I get a very
hard time with manual filling.  As a consequence Emacs becomes
difficult to use.  If it happens without me necessarily being aware of
it, things are worse.

In as far as `height' is concerned, we all seem to agree that the
current behavior makes no sense.  Either _both_ menu and tool bar
should be included or _none_.   For reasons I explained earlier, I
personally would prefer both, but Richard seems to believe it should
be none.  Either way, it seems that we have to live with the current
situation until after 21.4 is released.

To me, deleting or adding widgets, font changes and the like should
keep the number of text columns constant (and thus, change the X
window width).  I personally would prefer them to keep the X window
height fixed (and change the number of text lines).  This is not
inconsistent, because there is no symmetry between the number of text
columns (should be 80, more is _not_ better) and the number of text
lines (no fixed "logical" number and more _is_ better).  If I
understand correctly, Richard believes that _both_ number of text
lines and number of text columns should take precedence over X window
size.

Sincerely,

Luc.

Re: bug in frame-width

[Jan D.]

>
> When the user asks to change a parameter and does not ask to change
> any other parameters, the other parameters should stay constant.  That
> is logical, expected and as documented.  To keep the width parameter
> constant, the size of the X window has to change.  If this would be
> considered bad behavior, then the meaning of the width parameter
> should be changed to refer to the size of the X window.  The same
> holds for the height parameter.

I agree with this view.  Keeping columns constant is important to me
also.

>
> Currently, `width' refers to the number of text columns, `height'
> includes the tool bar but not the menu bar.  Any changes in current
> situation, even those we agree on it, seem to have to wait until after
> the 21.4 release.  In the current situation, changing the fringe width
> should keep the number of text columns constant.

It is more inconsistent than that.  The GTK version does not count the
tool bar, because this is a GTK native tool bar and may not be an 
integral
number of text lines (actually this makes the GTK version do the wrong
thing when geometry is specified, it is on my TODO list).

My view is that width and height should refer to available text area,
exclusive of fringe, scroll bar, menu bar and tool bar.

	Jan D.

Re: bug in frame-width

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> It is more inconsistent than that.  The GTK version does not count the
> tool bar, because this is a GTK native tool bar and may not be an
> integral
> number of text lines (actually this makes the GTK version do the wrong
> thing when geometry is specified, it is on my TODO list).
> 
> My view is that width and height should refer to available text area,
> exclusive of fringe, scroll bar, menu bar and tool bar.

And my view is that width and height should refer to available text
area when specified in the units of characters, and that it should
refer to the complete area inclusive of fringe, scroll bar, menu bar
and toolbar when specified in the unit of pixels.

And actually, I want my Emacs windows typically to be 80 characters
wide and about 740 pixels tall.  And when I change the font size, I
still want them 80 characters wide and 740 pixels tall.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: bug in frame-width

[Stefan Monnier]

> And actually, I want my Emacs windows typically to be 80 characters
> wide and about 740 pixels tall.  And when I change the font size, I
> still want them 80 characters wide and 740 pixels tall.

That would be perfect indeed.


        Stefan

Re: bug in frame-width

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> And actually, I want my Emacs windows typically to be 80 characters
> wide and about 740 pixels tall.  And when I change the font size, I
> still want them 80 characters wide and 740 pixels tall.

I second that.  When changing the number of columns lines may wrap at
different places which can be distracting.  When changing the number of
lines the only change is how many lines are visible towards the bottom,
which has much less visible effect.  (The situation is somewhat different
if you have mutiple windows.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bug in frame-width

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > And actually, I want my Emacs windows typically to be 80 characters
> > wide and about 740 pixels tall.  And when I change the font size, I
> > still want them 80 characters wide and 740 pixels tall.
> 
> I second that.  When changing the number of columns lines may wrap at
> different places which can be distracting.  When changing the number of
> lines the only change is how many lines are visible towards the bottom,
> which has much less visible effect.  (The situation is somewhat different
> if you have mutiple windows.)

Well, my point was that we don't need any inconsistencies if we can
come up with a scheme where you may specify your geometry in terms of
characters _or_ pixels.  Let's say, something stupid like unsigned
numbers are in characters, signed numbers are in pixels.

Then my desired geometry would be 80x+740, and a fullscreen mode
something like +1020x+740.  And negative numbers mean to take the
complete available dimension of the screen and leave the specified
free areas, so that 80x-40 would be 80 columns, and the whole vertical
area minus 40 pixels.

Pixels include everything in the window, characters not.  For symmetry
with text terminals, I'd say that the mode line and the
minibuffer/message line count as one line each when we are talking
about lines.  Menu line?  No idea.  It _does_ take space in a text
terminal, too.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: bug in frame-width

[Richard Stallman]

      If I
    understand correctly, Richard believes that _both_ number of text
    lines and number of text columns should take precedence over X window
    size.

Yes.  The specified window size (in the X geometry) should be the
number of lines and columns (as long as you stick to the standard
character height and width), and the other things in the frame should
be in addition to them.

David Kastrup wrote:

    And my view is that width and height should refer to available text
    area when specified in the units of characters, and that it should
    refer to the complete area inclusive of fringe, scroll bar, menu bar
    and toolbar when specified in the unit of pixels.

The question about dimensions in pixels is one where we may not have
to choose.  These dimensions are only used in various Lisp functions,
and we can easily have functions for both inclusive and exclusive
versions of the pixel dimensions.

    Well, my point was that we don't need any inconsistencies if we can
    come up with a scheme where you may specify your geometry in terms of
    characters _or_ pixels.  Let's say, something stupid like unsigned
    numbers are in characters, signed numbers are in pixels.

I have nothing against this in principle, after the coming release.

However, what we need to do now is fix bugs, and above all, to check
the manuals for things that need updating.  If more people don't start
helping with that, we won't HAVE another release, and these ideas
will all be irrelevant.

Only a few people have helped in checking the manual.  Luc Teirlinck
has done a lot, but everyone else combined has not done as much as he.
Would people please help with this essential task?