unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Konstantin Kharlamov <hi-angel@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36250@debbugs.gnu.org
Subject: bug#36250: [PATCH] Allow Emacs to be resized arbitrarily
Date: Sun, 16 Jun 2019 21:42:25 +0300	[thread overview]
Message-ID: <1560710545.19774.2@yandex.ru> (raw)
In-Reply-To: <837e9lv15t.fsf@gnu.org>



В Вс, июн 16, 2019 at 21:24, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
>>  Date: Sun, 16 Jun 2019 21:01:22 +0300
>> 
>>  This constraint disallows standard compliant window managers to make
>>  Emacs fullscreen on certain screen resolutions (ones that are not
>>  multiple of width_inc and height_inc), or to expand Emacs to fill 
>> free
>>  space on the screen (on certain sizes too).
>> 
>>  It doesn't seem to do anything useful otherwise; besides some WMs
>>  (like i3wm) just ignore this property anyway.
>> 
>>  * src/xterm.c (x_wm_set_size_hint): don't set width_inc, 
>> height_inc, and
>>    GDK_HINT_RESIZE_INC.
>>  * src/gtkutil.c (x_wm_set_size_hint): don't set width_inc, 
>> height_inc, and
>>    PResizeInc.
>>  * src/emacsgtkfixed.c (XSetWMSizeHints): don't set width_inc and 
>> height_inc.
> 
> Thanks, but after so many years of doing this stuff the way we do, and
> without any experts in this domain on board, I think we need to leave
> behind a "fire escape" -- a variable that users could set from Lisp to
> get back the old behavior.  There are too many window managers out
> there, and we cannot be sure none of them need the old code.

As I noted, "unconstrained behavior" is widely tested. At the very 
least, it's tested by users of i3wm.

We always can revert the code. Let's not pile up maintainance burden by 
adding lots of variables for unnecessary behavior unless it's really 
needed.







  parent reply	other threads:[~2019-06-16 18:42 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-16 17:59 bug#36250: Allow Emacs to be resized arbitrarily Konstantin Kharlamov
2019-06-16 18:01 ` bug#36250: [PATCH] " Konstantin Kharlamov
2019-06-16 18:24   ` Eli Zaretskii
2019-06-16 18:34     ` Eli Zaretskii
2019-06-17  8:22       ` martin rudalics
2019-06-17  8:41         ` Konstantin Kharlamov
2019-06-17  8:46           ` martin rudalics
2019-06-17  8:58           ` Juanma Barranquero
2019-06-16 18:42     ` Konstantin Kharlamov [this message]
2019-06-16 18:53       ` Eli Zaretskii
2019-06-16 18:59         ` Konstantin Kharlamov
2019-06-16 19:07           ` Eli Zaretskii
2019-06-16 19:15             ` Eli Zaretskii
2019-06-16 18:22 ` bug#36250: " Konstantin Kharlamov
2019-06-16 18:22 ` bug#36250: [PATCH v2] " Konstantin Kharlamov
2019-06-16 18:55 ` bug#36250: [PATCH v3] " Konstantin Kharlamov
2019-06-16 19:10   ` Eli Zaretskii
2019-06-17 12:32     ` Konstantin Kharlamov
2019-06-17 14:56       ` Eli Zaretskii
2019-06-18 20:34         ` Konstantin Kharlamov
2019-06-19 16:13           ` Eli Zaretskii
2020-08-26 10:26       ` Lars Ingebrigtsen
     [not found] ` <mailman.222.1560709505.10840.bug-gnu-emacs@gnu.org>
2019-06-17  7:54   ` bug#36250: [PATCH] " Alan Mackenzie
2019-06-17  8:43     ` martin rudalics
2019-06-17 14:38       ` Eli Zaretskii
2019-06-18  8:17         ` martin rudalics
2019-06-18 15:49           ` Eli Zaretskii
2019-06-17  8:21 ` bug#36250: " martin rudalics
2019-06-17  8:27   ` Konstantin Kharlamov
2019-06-17  8:44     ` martin rudalics
2019-06-17  9:14       ` Konstantin Kharlamov
2019-06-17  9:46         ` martin rudalics
2019-06-17 14:41         ` Eli Zaretskii
2019-06-18 20:35 ` bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation Konstantin Kharlamov
2019-06-18 20:38   ` Andreas Schwab
2019-06-19 16:16   ` Eli Zaretskii
2019-06-28 11:27     ` Konstantin Kharlamov
2019-06-28 13:16       ` Eli Zaretskii
2019-06-28 13:59         ` Konstantin Kharlamov
2019-06-28 14:22           ` Eli Zaretskii
2019-06-28 14:34             ` Konstantin Kharlamov
2019-06-28 14:49               ` Eli Zaretskii

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=1560710545.19774.2@yandex.ru \
    --to=hi-angel@yandex.ru \
    --cc=36250@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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).