[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font

From: Eli Zaretskii
Subject: bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font
Date: Fri, 03 May 2013 10:12:14 +0300

> Date: Fri, 03 May 2013 08:48:27 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
>  >> That's what I'm wondering about.
>  >
>  > You cannot just call change_frame_size on Windows anyway.  It doesn't
>  > do what you'd expect.
> I see no difference.

I was trying to explain why that comment might be of only historical
interest, since it describes code that we don't use.

>  >> So w32-send-sys-command is handled differently from setting the
>  >> fullscreen frame parameter to maximized?
>  >
>  > Not really: the latter is implemented by calling the former (or
>  > actually doing the same independently).
>  >
>  >> Does this mean the OP could have used `set-frame-parameter' and it
>  >> would have worked in his sense?
>  >
>  > No, see above.
> That's what I thought.  Hopefully `set-default-font`' at least resets
> the maximized frame parameter.

I don't think it does.  And I'm not sure it should.

>  In any case I'd consider it a bug that `set-default-font' is
> allowed to resize a maximized frame.

That's what your changes are about, I think.

>  >>  > By contrast, set-default-font works in the opposite direction: Emacs
>  >>  > _does_ understand what that means, it does know how to load a font and
>  >>  > get its metrics, and it does know how to resize the frame as result.
>  >>
>  >> But when x_set_window_size tells Windows that it wants to resize the
>  >> frame, it stumbles into some away-defined code.
>  >
>  > Not sure what x_set_window_size has to do with all this.
> That's the routine we're talking about here

I understand, but I don't see how it is related to set-default-font.

> When I fit the size of a frame to that of its buffer, I ideally would do
> this in one `modify-frame-parameters' call to set the size of the new
> frame.  But if this call shrinks the frame, both the menubar and the
> toolbar may wrap and my calculations get ignored.

Do we really want to allow resizing that causes this wrap, when what
the user wants is to fit frame size to buffer?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]