unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: eenliu@gmail.com, 14326@debbugs.gnu.org
Subject: bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font
Date: Fri, 03 May 2013 10:12:14 +0300	[thread overview]
Message-ID: <834neko7u9.fsf@gnu.org> (raw)
In-Reply-To: <51835DBB.1060609@gmx.at>

> Date: Fri, 03 May 2013 08:48:27 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eenliu@gmail.com, 14326@debbugs.gnu.org
> 
>  >> 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	other threads:[~2013-05-03  7:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01  1:34 bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font Eric Liu
2013-05-01  9:15 ` martin rudalics
2013-05-01 15:02   ` Eli Zaretskii
2013-05-01 17:33     ` Eric Liu
2013-05-01 17:37       ` Eli Zaretskii
2013-05-02  9:23     ` martin rudalics
2013-05-02 17:08       ` Eli Zaretskii
2013-05-02 18:32         ` martin rudalics
2013-05-02 18:55           ` Eli Zaretskii
2013-05-02 19:08             ` martin rudalics
2013-05-02 19:38               ` Eli Zaretskii
2013-05-03  6:48                 ` martin rudalics
2013-05-03  7:12                   ` Eli Zaretskii [this message]
2013-05-03  7:28                     ` martin rudalics
2013-05-03 14:59                   ` Drew Adams
2013-05-03 15:48                     ` Eli Zaretskii
2013-05-03 15:54                       ` Eli Zaretskii
2013-05-03 16:26                       ` Drew Adams
2013-05-03 18:04                         ` Eli Zaretskii
2013-05-03 18:19                           ` Drew Adams
2013-05-03 19:25                             ` Eli Zaretskii
2013-05-03 18:59                       ` martin rudalics
2013-05-03 20:06                         ` Drew Adams
2013-05-03 20:18                           ` Eli Zaretskii
2013-05-03 20:31                             ` Drew Adams
2013-05-04  6:37                               ` Eli Zaretskii
2013-05-04  7:50                                 ` martin rudalics
2013-05-04 14:17                                 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834neko7u9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=14326@debbugs.gnu.org \
    --cc=eenliu@gmail.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).