GNU bug report logs -
#14326
24.3; Conflict of w32-send-sys-command and set-default-font
Previous Next
Reported by: Eric Liu <eenliu <at> gmail.com>
Date: Wed, 1 May 2013 01:37:02 UTC
Severity: normal
Found in version 24.3
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #79 received at 14326 <at> debbugs.gnu.org (full text, mbox):
> > > For example, increasing the font size should not make a
> > > maximized frame larger than the screen. We're kidding users
> > > with such behavior.
> >
> > 1. Your argument here applies to any size increase beyond
> > the screen size, not just doing that via `set-frame-font'.
> > So it is irrelevant as an argument why resizing via
> > `set-frame-font' should be an exception.
>
> It _is_ relevant, because Martin's argument applies not only to
> increasing maximized frames, but also to decreasing their size as
> well, as side effect of any change except an explicit change in frame
> dimensions.
What argument? That is the conclusion, but what is the argument supporting it?
> IOW, when the frame is maximized, only explicitly changing its height
> or width, or explicitly un-maximizing it, should
Should why? That's the question. Haven't seen an answer yet.
> ever affect the frame's size. Any other changes, such as font change or
> adding/removing scroll bars or fringes -- should
Should why?
> leave the frame at the same pixel dimensions, i.e. still maximized.
All of that just repeats the claim; it does not support it.
That is the claim for which I am asking for a supporting reason.
You have also generalized beyond just `set-frame-font' (the only exception
mentioned until now, AFAIK), BTW. Now it is apparently not just
`set-frame-font' that is the exception but any way of resizing other than
"explicitly changing its height or width, or explicitly un-maximizing it".
My question remains, in any case: What is the _reason_ why such ways of resizing
should be neutered? What is the _reason_ why "explicitly changing its height or
width, or explicitly un-maximizing it" should be the only way of changing the
size?
There might be a good reason for such a claim, but I've seen none advanced, so
far. "X because X" is no support for X: it just assumes the conclusion.
This bug report was last modified 12 years and 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.