bug#36250: Allow Emacs to be resized arbitrarily

bug#36250: Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

For a long time Emacs was setting PResizeInc flag for WM_SIZE_HINTS, 
thus causing problems to users of standard-compliant window managers, 
such as not being able to open Emacs in fullscreen¹ or not being able 
to resize Emacs to fill all free space on the screen².

I investigated reasons why these variables were set in the first place, 
and found the first occurrence of `size_hints.width_inc` in `xterm.c`, 
commit `Initial revision` in 1991 year, function `x_wm_set_size_hint`. 
First occurrence in GTK related file is at `gtkutil.c`, commit `GTK 
files gtkutil.c and .h` in 2003. Both commits lack any description, and 
no comments on the resize matter provided.

This patch fixes the problem, the property "program specified resize 
increment" in `xprop` output is no longer set.

Unconstrained resize of Emacs is widely tested, e.g. I've been using 
for years Emacs on i3wm, which just ignores the property, thus resizes 
Emacs arbitrarily. Also: I don't touch in this patch 
`frame_resize_pixelwise` variable, because it's used for something 
else; in particular, setting this variable had no influence on the 
problem.

1: https://bugs.kde.org/show_bug.cgi?id=408746#c8
2: https://github.com/kwin-scripts/kwin-tiling/issues/161

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

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.
---
 src/emacsgtkfixed.c | 2 --
 src/gtkutil.c       | 9 +--------
 src/xterm.c         | 5 +----
 3 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/src/emacsgtkfixed.c b/src/emacsgtkfixed.c
index 6b2b4f7018..352883a12f 100644
--- a/src/emacsgtkfixed.c
+++ b/src/emacsgtkfixed.c
@@ -222,8 +222,6 @@ XSetWMSizeHints (Display *d,
   data[6] = hints->min_height;
   data[7] = hints->max_width;
   data[8] = hints->max_height;
-  data[9] = hints->width_inc;
-  data[10] = hints->height_inc;
   data[11] = hints->min_aspect.x;
   data[12] = hints->min_aspect.y;
   data[13] = hints->max_aspect.x;
diff --git a/src/gtkutil.c b/src/gtkutil.c
index dccee15925..88ea38b557 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1428,12 +1428,7 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
 
   size_hints = f->output_data.x->size_hints;
   hint_flags = f->output_data.x->hint_flags;
-
-  hint_flags |= GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
-  hint_flags |= GDK_HINT_BASE_SIZE;
+  hint_flags |= GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE;
   /* Use one row/col here so base_height/width does not become zero.
      Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
      Obviously this makes the row/col value displayed off by 1.  */
@@ -1486,8 +1481,6 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
 
   size_hints.base_width /= scale;
   size_hints.base_height /= scale;
-  size_hints.width_inc /= scale;
-  size_hints.height_inc /= scale;
 
   if (hint_flags != f->output_data.x->hint_flags
       || memcmp (&size_hints,
diff --git a/src/xterm.c b/src/xterm.c
index bc56e99513..cff74e4f22 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12124,7 +12124,7 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
 #endif
 
   /* Setting PMaxSize caused various problems.  */
-  size_hints.flags = PResizeInc | PMinSize /* | PMaxSize */;
+  size_hints.flags = PMinSize /* | PMaxSize */;
 
   size_hints.x = f->left_pos;
   size_hints.y = f->top_pos;
@@ -12132,9 +12132,6 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
   size_hints.width = FRAME_PIXEL_WIDTH (f);
   size_hints.height = FRAME_PIXEL_HEIGHT (f);
 
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
   size_hints.max_width = x_display_pixel_width (FRAME_DISPLAY_INFO (f))
     - FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
   size_hints.max_height = x_display_pixel_height (FRAME_DISPLAY_INFO (f))
-- 
2.22.0

bug#36250: Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

Sorry, forgot to add "fixes bug", resending

bug#36250: [PATCH v2] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

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.

Fixes bug#36250

* 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.
---

v2: add "Fixes bug"

 src/emacsgtkfixed.c | 2 --
 src/gtkutil.c       | 9 +--------
 src/xterm.c         | 5 +----
 3 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/src/emacsgtkfixed.c b/src/emacsgtkfixed.c
index 6b2b4f7018..352883a12f 100644
--- a/src/emacsgtkfixed.c
+++ b/src/emacsgtkfixed.c
@@ -222,8 +222,6 @@ XSetWMSizeHints (Display *d,
   data[6] = hints->min_height;
   data[7] = hints->max_width;
   data[8] = hints->max_height;
-  data[9] = hints->width_inc;
-  data[10] = hints->height_inc;
   data[11] = hints->min_aspect.x;
   data[12] = hints->min_aspect.y;
   data[13] = hints->max_aspect.x;
diff --git a/src/gtkutil.c b/src/gtkutil.c
index dccee15925..88ea38b557 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1428,12 +1428,7 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
 
   size_hints = f->output_data.x->size_hints;
   hint_flags = f->output_data.x->hint_flags;
-
-  hint_flags |= GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
-  hint_flags |= GDK_HINT_BASE_SIZE;
+  hint_flags |= GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE;
   /* Use one row/col here so base_height/width does not become zero.
      Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
      Obviously this makes the row/col value displayed off by 1.  */
@@ -1486,8 +1481,6 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
 
   size_hints.base_width /= scale;
   size_hints.base_height /= scale;
-  size_hints.width_inc /= scale;
-  size_hints.height_inc /= scale;
 
   if (hint_flags != f->output_data.x->hint_flags
       || memcmp (&size_hints,
diff --git a/src/xterm.c b/src/xterm.c
index bc56e99513..cff74e4f22 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12124,7 +12124,7 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
 #endif
 
   /* Setting PMaxSize caused various problems.  */
-  size_hints.flags = PResizeInc | PMinSize /* | PMaxSize */;
+  size_hints.flags = PMinSize /* | PMaxSize */;
 
   size_hints.x = f->left_pos;
   size_hints.y = f->top_pos;
@@ -12132,9 +12132,6 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
   size_hints.width = FRAME_PIXEL_WIDTH (f);
   size_hints.height = FRAME_PIXEL_HEIGHT (f);
 
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
   size_hints.max_width = x_display_pixel_width (FRAME_DISPLAY_INFO (f))
     - FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
   size_hints.max_height = x_display_pixel_height (FRAME_DISPLAY_INFO (f))
-- 
2.22.0

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> 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.

Also, this change (and the variable to be added) should be called out
in NEWS.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Sun, 16 Jun 2019 21:24:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 36250@debbugs.gnu.org
> 
> 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"

Of course, I'd still like to hear comments about the change and its
safety, as well as invite people to try this with their window
managers.

Martin, any comments?

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

В Вс, июн 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.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Sun, 16 Jun 2019 21:42:25 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> > 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've been there before: the real world out there never ceases to
surprise us, no matter how sure we are in our conclusions.  I've
learned that lesson after seeing our best intentions backfire enough
times.

> We always can revert the code.

We can, but users who install distros usually cannot.  Having a
user-level knob to fix any unexpected situations is good for users.

> Let's not pile up maintainance burden by adding lots of variables
> for unnecessary behavior unless it's really needed.

There's no tangible burden here, believe me.

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

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.

Fixes bug#36250

* 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.
* etc/NEWS: describe changes
---

v3: add description in NEWS file

 etc/NEWS            | 8 ++++++++
 src/emacsgtkfixed.c | 2 --
 src/gtkutil.c       | 9 +--------
 src/xterm.c         | 5 +----
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 723f0a0fb0..e78ac326d0 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -171,6 +171,14 @@ This allows disabling the new feature introduced in Emacs 26.1 which
 loads files during completion of 'C-h f' and 'C-h v' according to
 'definition-prefixes'.
 
++++
+** Resize step is not forced anymore
+This should help users of standard-complaint window managers, such as KWin.
+Before this change they couldn't make Emacs full-screen on certain sizes, or
+even make it fill all free space on the screen.
+Users of window managers that ignored that hint, such as i3wm, won't notice
+any change.
+
 \f
 * Changes in Emacs 27.1
 
diff --git a/src/emacsgtkfixed.c b/src/emacsgtkfixed.c
index 6b2b4f7018..352883a12f 100644
--- a/src/emacsgtkfixed.c
+++ b/src/emacsgtkfixed.c
@@ -222,8 +222,6 @@ XSetWMSizeHints (Display *d,
   data[6] = hints->min_height;
   data[7] = hints->max_width;
   data[8] = hints->max_height;
-  data[9] = hints->width_inc;
-  data[10] = hints->height_inc;
   data[11] = hints->min_aspect.x;
   data[12] = hints->min_aspect.y;
   data[13] = hints->max_aspect.x;
diff --git a/src/gtkutil.c b/src/gtkutil.c
index dccee15925..88ea38b557 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1428,12 +1428,7 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
 
   size_hints = f->output_data.x->size_hints;
   hint_flags = f->output_data.x->hint_flags;
-
-  hint_flags |= GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
-  hint_flags |= GDK_HINT_BASE_SIZE;
+  hint_flags |= GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE;
   /* Use one row/col here so base_height/width does not become zero.
      Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
      Obviously this makes the row/col value displayed off by 1.  */
@@ -1486,8 +1481,6 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
 
   size_hints.base_width /= scale;
   size_hints.base_height /= scale;
-  size_hints.width_inc /= scale;
-  size_hints.height_inc /= scale;
 
   if (hint_flags != f->output_data.x->hint_flags
       || memcmp (&size_hints,
diff --git a/src/xterm.c b/src/xterm.c
index bc56e99513..cff74e4f22 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12124,7 +12124,7 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
 #endif
 
   /* Setting PMaxSize caused various problems.  */
-  size_hints.flags = PResizeInc | PMinSize /* | PMaxSize */;
+  size_hints.flags = PMinSize /* | PMaxSize */;
 
   size_hints.x = f->left_pos;
   size_hints.y = f->top_pos;
@@ -12132,9 +12132,6 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
   size_hints.width = FRAME_PIXEL_WIDTH (f);
   size_hints.height = FRAME_PIXEL_HEIGHT (f);
 
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
   size_hints.max_width = x_display_pixel_width (FRAME_DISPLAY_INFO (f))
     - FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
   size_hints.max_height = x_display_pixel_height (FRAME_DISPLAY_INFO (f))
-- 
2.22.0

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

В Вс, июн 16, 2019 at 21:53, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  Date: Sun, 16 Jun 2019 21:42:25 +0300
>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>  Cc: 36250@debbugs.gnu.org
>> 
>>  > 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've been there before: the real world out there never ceases to
> surprise us, no matter how sure we are in our conclusions.  I've
> learned that lesson after seeing our best intentions backfire enough
> times.

Okay, then, should I maybe bring it up on emacs-devel? I wanted 
initially to do just that, but then I figured that searching for 
reasons why these variables were added in the first place should be 
enough. But if not, I can still open a topic there.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Sun, 16 Jun 2019 21:59:26 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> > We've been there before: the real world out there never ceases to
> > surprise us, no matter how sure we are in our conclusions.  I've
> > learned that lesson after seeing our best intentions backfire enough
> > times.
> 
> Okay, then, should I maybe bring it up on emacs-devel?

That's orthogonal, and is up to you.  I don't see how any kind of
discussion could make us 110% sure this change can never do any harm,
with any window manager and any possible setup/configuration.

The way I see it, we add a simple Lisp variable and don't bother
documenting it except in NEWS.  Then a few releases from now, if no
one comes up with a problem, we can either delete the variable or
forget about it.  The advantage of this plan is that there's no danger
of breaking someone's setup without giving them a know to repair the
damage.  Which will allow us to make this backward-incompatible change
with less fear.

All this, of course, subject to the assumption that no one will object
to the change because they already know something about that.  Let's
not get ahead of ourselves, okay?

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Date: Sun, 16 Jun 2019 21:55:14 +0300
> 
> ++++

We are not going to document this in the manuals, so this should be
"---", not "+++".

> +** Resize step is not forced anymore
> +This should help users of standard-complaint window managers, such as KWin.
> +Before this change they couldn't make Emacs full-screen on certain sizes, or
> +even make it fill all free space on the screen.
> +Users of window managers that ignored that hint, such as i3wm, won't notice
> +any change.

This text should be more self-explanatory, I think.  At the very
least, the header line should mention "X window manager", because some
people read NEWS folded, and only open the headers they are interested
in.

Also, no need to mention situations where the change will not produce
any effect.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Sun, 16 Jun 2019 22:07:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 36250@debbugs.gnu.org
> 
> The advantage of this plan is that there's no danger of breaking
> someone's setup without giving them a know to repair the damage.
                                      ^^^^^^
I meant "a knob", sorry.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Alan Mackenzie]

Hello, Eli.

In article <mailman.222.1560709505.10840.bug-gnu-emacs@gnu.org> you wrote:
>> 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.

Yes.  Having a whole number of lines in a window is a legitimate thing to
want.

Also, I remember vaguely partial lines causing problems in Follow Mode in
the past.  In case they cause problems there again, or somewhere else, we
should have the ability to disable partial lines.

> Also, this change (and the variable to be added) should be called out
> in NEWS.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36250: Allow Emacs to be resized arbitrarily

[martin rudalics]

 > Unconstrained resize of Emacs is widely tested, e.g. I've been using
 > for years Emacs on i3wm, which just ignores the property, thus
 > resizes Emacs arbitrarily. Also: I don't touch in this patch
 > `frame_resize_pixelwise` variable, because it's used for something
 > else; in particular, setting this variable had no influence on the
 > problem.

Why do you think that 'frame_resize_pixelwise' is used for something
else?  gtkutil.c uses it to assign the increments as

   size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
   size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);

 > 1: https://bugs.kde.org/show_bug.cgi?id=408746#c8
 > 2: https://github.com/kwin-scripts/kwin-tiling/issues/161

There Martin Flöser says on 2019-06-16

 > Given the resize increment provided by emacs (8x17) it is impossible
 > to fullscreens the window with the used resolution. 1326 doesn't
 > divide by 8 and 681 doesn't divide by 17.

so it appears that you did _not_ set 'frame-resize-pixelwise' since
otherwise the 8 x 17 wouldn't be there.  Can you please clarify.

If setting 'frame-resize-pixelwise' does not work as intended, we
apparently fail to set the increments in due time.  But then this is
to my knowledge the first time this happens since we introduced that
variable and we certainly have to fix that.  So if it does not work
for some reason, please use GDB with a checkpoint at these assignments
and tell us whether frame_resize_pixelwise really wasn't set properly.

Thanks, martin

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[martin rudalics]

 > Of course, I'd still like to hear comments about the change and its
 > safety, as well as invite people to try this with their window
 > managers.

Window managers use size hints for two purposes:

(1) To provide feedback of the prospective size of the Emacs frame in
lines and columns displayed in a tooltip-like window whenever the user
drags a frame edge or border with the mouse.

(2) To effectively round the size of the Emacs frame to multiples of
lines and columns when dragging any of its borders or edges with the
mouse.

I suppose we cannot give up on these features given a strong minority
of Emacs users who prefer working with frame sizes where not a single
pixel gets wasted for showing anything but bare text.

martin

bug#36250: Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

On Пн, июн 17, 2019 at 10:21, martin rudalics <rudalics@gmx.at> 
wrote:
>  > Unconstrained resize of Emacs is widely tested, e.g. I've been 
> using
> > for years Emacs on i3wm, which just ignores the property, thus
> > resizes Emacs arbitrarily. Also: I don't touch in this patch
> > `frame_resize_pixelwise` variable, because it's used for something
> > else; in particular, setting this variable had no influence on the
> > problem.
> 
> Why do you think that 'frame_resize_pixelwise' is used for something
> else?  gtkutil.c uses it to assign the increments as
> 
>   size_hints.width_inc = frame_resize_pixelwise ? 1 : 
> FRAME_COLUMN_WIDTH (f);
>   size_hints.height_inc = frame_resize_pixelwise ? 1 : 
> FRAME_LINE_HEIGHT (f);
> 
> > 1: https://bugs.kde.org/show_bug.cgi?id=408746#c8
> > 2: https://github.com/kwin-scripts/kwin-tiling/issues/161
> 
> There Martin Flöser says on 2019-06-16
> 
> > Given the resize increment provided by emacs (8x17) it is impossible
> > to fullscreens the window with the used resolution. 1326 doesn't
> > divide by 8 and 681 doesn't divide by 17.
> 
> so it appears that you did _not_ set 'frame-resize-pixelwise' since
> otherwise the 8 x 17 wouldn't be there.  Can you please clarify.
> 
> If setting 'frame-resize-pixelwise' does not work as intended, we
> apparently fail to set the increments in due time.  But then this is
> to my knowledge the first time this happens since we introduced that
> variable and we certainly have to fix that.  So if it does not work
> for some reason, please use GDB with a checkpoint at these assignments
> and tell us whether frame_resize_pixelwise really wasn't set properly.

 From cursory reading of the code, frame_resize_pixelwise is only used 
on window creation. Either way, you can easily reproduce it the 
following way:

1. Evaluate in Emacs (setq frame-resize-pixelwise t)
2. Execute `xprop | grep "program specified resize increment"`

You will see something like "program specified resize increment: 7 by 
15"; both 7 and 15 are certainly bigger than 1 :)

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

On Пн, июн 17, 2019 at 10:22, martin rudalics <rudalics@gmx.at> 
wrote:
>  > Of course, I'd still like to hear comments about the change and its
> > safety, as well as invite people to try this with their window
> > managers.
> 
> Window managers use size hints for two purposes:
> 
> (1) To provide feedback of the prospective size of the Emacs frame in
> lines and columns displayed in a tooltip-like window whenever the user
> drags a frame edge or border with the mouse.
> 
> (2) To effectively round the size of the Emacs frame to multiples of
> lines and columns when dragging any of its borders or edges with the
> mouse.
> 
> I suppose we cannot give up on these features given a strong minority
> of Emacs users who prefer working with frame sizes where not a single
> pixel gets wasted for showing anything but bare text.
> 
> martin

So, if I understand the above correctly, the purpose is simply to not 
allow Emacs showing half of a line or half of a column. Well. I admit I 
don't really understand why would someone want to waste space showing 
nothing (since showing half of a line is more useful than showing 
nothing), but if you are sure that there are users who want this… Oh, 
well.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[martin rudalics]

 > Yes.  Having a whole number of lines in a window is a legitimate thing to
 > want.

It's legitimate provided as long as you (1) don't want to display your
frame in fullscreen mode and the screen size is not an integral
multiple of the frame's character size, and (2) don't use a tiling
window manager.

 > Also, I remember vaguely partial lines causing problems in Follow Mode in
 > the past.

Doesn't that imply that one cannot use Follow Mode for *info* buffers?

 > In case they cause problems there again, or somewhere else, we
 > should have the ability to disable partial lines.

In general, you cannot "disable" partial lines on graphical displays
any more.

martin

bug#36250: Allow Emacs to be resized arbitrarily

[martin rudalics]

 >  From cursory reading of the code, frame_resize_pixelwise is only
 >  used on window creation.

Right.

 > Either way, you can easily reproduce it the following way:
 >
 > 1. Evaluate in Emacs (setq frame-resize-pixelwise t)
 > 2. Execute `xprop | grep "program specified resize increment"`
 >
 > You will see something like "program specified resize increment: 7 by 15"; both 7 and 15 are certainly bigger than 1 :)

You either have to set it in your initial file (like I do, for
example) or before a new frame is created.

martin

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[martin rudalics]

 > So, if I understand the above correctly, the purpose is simply to
 > not allow Emacs showing half of a line or half of a column. Well. I
 > admit I don't really understand why would someone want to waste
 > space showing nothing (since showing half of a line is more useful
 > than showing nothing), but if you are sure that there are users who
 > want this… Oh, well.

Try to imagine why 'frame-resize-pixelwise' defaults to nil ...

martin

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Juanma Barranquero]

On Mon, Jun 17, 2019 at 10:42 AM Konstantin Kharlamov
<hi-angel@yandex.ru> wrote:

> So, if I understand the above correctly, the purpose is simply to not
> allow Emacs showing half of a line or half of a column. Well. I admit I
> don't really understand why would someone want to waste space showing
> nothing (since showing half of a line is more useful than showing
> nothing)

IIUC, it's not "half of a line"; it's whatever space is left. Having
*almost* a line could be useful, having a two-pixel strip would't be
useful, and in most cases in between what it would be is distracting,
not useful (to me, anyway).

> but if you are sure that there are users who want this…

Yes, there's people who do not want pixel resizing turned on unconditionally.

bug#36250: Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

On Пн, июн 17, 2019 at 10:44, martin rudalics <rudalics@gmx.at> 
wrote:
>  >  From cursory reading of the code, frame_resize_pixelwise is only
> >  used on window creation.
> 
> Right.
> 
> > Either way, you can easily reproduce it the following way:
> >
> > 1. Evaluate in Emacs (setq frame-resize-pixelwise t)
> > 2. Execute `xprop | grep "program specified resize increment"`
> >
> > You will see something like "program specified resize increment: 7 
> by 15"; both 7 and 15 are certainly bigger than 1 :)
> 
> You either have to set it in your initial file (like I do, for
> example) or before a new frame is created.

I just tested it, and it works. However I've always wondered, is there 
a place in .emacs file, which is guaranteed to be executed before a 
window is created? I may be mistaken, but it looks to me like Emacs 
tries to create window almost immediately on start, and that the (setq 
frame-resize-pixelwise t) line at the beginning of the config being 
executed before window is created is pure luck.

bug#36250: Allow Emacs to be resized arbitrarily

[martin rudalics]

 > I just tested it, and it works. However I've always wondered, is
 > there a place in .emacs file, which is guaranteed to be executed
 > before a window is created? I may be mistaken, but it looks to me
 > like Emacs tries to create window almost immediately on start, and
 > that the (setq frame-resize-pixelwise t) line at the beginning of
 > the config being executed before window is created is pure luck.

I had no complaints about it ever since that variable was introduced.
So it's hopefully a bit more than pure luck.  BTW Emacs 27 now has an
"Early Init File" (see section 49.4.6 of the Emacs manual) where you
can put things that should be done very early.

martin

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

Oh well, let's close this then. I'd still like to improve documentation 
for frame-resize-pixelwise to mention that this variable needs to be 
changed before Emacs window appears. Because until Martin mentioned 
that, it looked like the variable doesn't work.

Shall I mention that change in "NEWS"? Can I send the patch into this 
topic?

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Cc: 36250@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 17 Jun 2019 10:43:57 +0200
> 
>  > Also, I remember vaguely partial lines causing problems in Follow Mode in
>  > the past.
> 
> Doesn't that imply that one cannot use Follow Mode for *info* buffers?

Follow mode indeed has known problems in these situations.

> In general, you cannot "disable" partial lines on graphical displays
> any more.

Actually, that was true since Emacs 21.  What became true only lately
is that a window that occupies its whole frame can also have a
fractional number of lines, even when all the characters are displayed
in the default face.  That used to be not so in the past.

bug#36250: Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Mon, 17 Jun 2019 12:14:28 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> > > 1. Evaluate in Emacs (setq frame-resize-pixelwise t)
> > > 2. Execute `xprop | grep "program specified resize increment"`
> > >
> > > You will see something like "program specified resize increment: 7 
> > by 15"; both 7 and 15 are certainly bigger than 1 :)
> > 
> > You either have to set it in your initial file (like I do, for
> > example) or before a new frame is created.
> 
> I just tested it, and it works. However I've always wondered, is there 
> a place in .emacs file, which is guaranteed to be executed before a 
> window is created? I may be mistaken, but it looks to me like Emacs 
> tries to create window almost immediately on start, and that the (setq 
> frame-resize-pixelwise t) line at the beginning of the config being 
> executed before window is created is pure luck.

It doesn't have to be sheer luck: Emacs resets some display-related
parameters after it reads the init files, precisely to cater to the
cases such as this one.  I don't know if this parameter is one of
those that benefit from this, but it might be.  One example of
settings that definitely are acted upon after reading the init file is
default-frame-alist.

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Mon, 17 Jun 2019 15:32:11 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> Oh well, let's close this then. I'd still like to improve documentation 
> for frame-resize-pixelwise to mention that this variable needs to be 
> changed before Emacs window appears. Because until Martin mentioned 
> that, it looked like the variable doesn't work.
> 
> Shall I mention that change in "NEWS"? Can I send the patch into this 
> topic?

Yes, you can send the patch under this topic.  But the change
shouldn't be in NEWS, because this issue is nothing new, we are just
improving its documentation.  The change should be in the manual and
possibly also in the doc string of the variable (although the latter
already says to set it in the init file).

Thanks.

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[martin rudalics]

 >> Doesn't that imply that one cannot use Follow Mode for *info* buffers?
 >
 > Follow mode indeed has known problems in these situations.

Ever since, I suppose.  Why is it difficult to fix them?

 >> In general, you cannot "disable" partial lines on graphical displays
 >> any more.
 >
 > Actually, that was true since Emacs 21.  What became true only lately
 > is that a window that occupies its whole frame can also have a
 > fractional number of lines, even when all the characters are displayed
 > in the default face.  That used to be not so in the past.

Because we now do not show unidentified slack space below such a
window (or pretend that it's part of the echo area) but rather add
such space to the bottommost windows of each frame.

martin

bug#36250: [PATCH] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Cc: acm@muc.de, 36250@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 18 Jun 2019 10:17:55 +0200
> 
>  >> Doesn't that imply that one cannot use Follow Mode for *info* buffers?
>  >
>  > Follow mode indeed has known problems in these situations.
> 
> Ever since, I suppose.  Why is it difficult to fix them?

Lack of resources, mainly.  Follow mode tries to force the display
engine do something, and that is tricky, as we know.  Maybe it uses
the wrong hooks, or maybe we need a new hook just for this mode.

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Konstantin Kharlamov]

В Пн, июн 17, 2019 at 17:56, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  Date: Mon, 17 Jun 2019 15:32:11 +0300
>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>  Cc: 36250@debbugs.gnu.org
>> 
>>  Oh well, let's close this then. I'd still like to improve 
>> documentation
>>  for frame-resize-pixelwise to mention that this variable needs to be
>>  changed before Emacs window appears. Because until Martin mentioned
>>  that, it looked like the variable doesn't work.
>> 
>>  Shall I mention that change in "NEWS"? Can I send the patch into 
>> this
>>  topic?
> 
> Yes, you can send the patch under this topic.  But the change
> shouldn't be in NEWS, because this issue is nothing new, we are just
> improving its documentation.  The change should be in the manual and
> possibly also in the doc string of the variable (although the latter
> already says to set it in the init file).
> 
> Thanks.

A manual? I've changed it in the doc-string, but where is the manual?

FTR, I'm sending the patch too as a follow up, in case there's 
something wrong or whatever.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Konstantin Kharlamov]

* src/frame.c (syms_of_frame): remove from the second paragraph bits
of text that duplicate the first paragraph, and mention that the
variable needs to be set before a frame started.
---
 src/frame.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/frame.c b/src/frame.c
index 03bbbfb4da..c2d2793251 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -6152,10 +6152,9 @@ current values of `frame-char-height' and `frame-char-width'.  If this
 is non-nil, no rounding occurs, hence frame sizes can increase/decrease
 by one pixel.
 
-With some window managers you may have to set this to non-nil in order
-to set the size of a frame in pixels, to maximize frames or to make them
-fullscreen.  To resize your initial frame pixelwise, set this option to
-a non-nil value in your init file.  */);
+With some window managers you may have to set this to non-nil to be
+able maximize frames or to make them fullscreen.  For this to have
+effect the variable needs to be set before a frame started.  */);
   frame_resize_pixelwise = 0;
 
   DEFVAR_LISP ("frame-inhibit-implied-resize", frame_inhibit_implied_resize,
-- 
2.22.0

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Andreas Schwab]

On Jun 18 2019, Konstantin Kharlamov <Hi-Angel@yandex.ru> wrote:

> diff --git a/src/frame.c b/src/frame.c
> index 03bbbfb4da..c2d2793251 100644
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -6152,10 +6152,9 @@ current values of `frame-char-height' and `frame-char-width'.  If this
>  is non-nil, no rounding occurs, hence frame sizes can increase/decrease
>  by one pixel.
>  
> -With some window managers you may have to set this to non-nil in order
> -to set the size of a frame in pixels, to maximize frames or to make them
> -fullscreen.  To resize your initial frame pixelwise, set this option to
> -a non-nil value in your init file.  */);
> +With some window managers you may have to set this to non-nil to be
> +able maximize frames or to make them fullscreen.  For this to have
> +effect the variable needs to be set before a frame started.  */);

Frames don't start, they are created.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Eli Zaretskii]

> Date: Tue, 18 Jun 2019 23:34:48 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> A manual? I've changed it in the doc-string, but where is the manual?

When and where (in what branch) did you change the doc string?  I
don't think I see the change.

As for the manual: this variable is documented in
doc/emacs/frames.texi.  In the formatted Info manual, go to the node
"Frame Commands" and see there.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Date: Tue, 18 Jun 2019 23:35:02 +0300
> 
> * src/frame.c (syms_of_frame): remove from the second paragraph bits
> of text that duplicate the first paragraph, and mention that the
> variable needs to be set before a frame started.

I don't see why you needed to remove part of the text.  It isn't a
repetition: the first sentence talks about frames in general, the
second only about the initial frame.  The bit about the init file is
only relevant to the latter.

Thanks.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Konstantin Kharlamov]

В Ср, июн 19, 2019 at 19:16, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
>>  Date: Tue, 18 Jun 2019 23:35:02 +0300
>> 
>>  * src/frame.c (syms_of_frame): remove from the second paragraph bits
>>  of text that duplicate the first paragraph, and mention that the
>>  variable needs to be set before a frame started.
> 
> I don't see why you needed to remove part of the text.  It isn't a
> repetition: the first sentence talks about frames in general, the
> second only about the initial frame.  The bit about the init file is
> only relevant to the latter.

The specific part of text being removed sounds as"in order to set the 
size of a frame in pixels, ", which explains what happens when variable 
is non-nil.

However, if you read both of two paragraphs of documentation, you may 
find that the 1st paragraph already explains the technical details 
behind the variable, and the "non-nil" word in particular appears twice.

At that point, if reader came to 2nd paragraph, they probably know what 
Emacs does when variable is non-nil; or at least they know where to 
look that up. So, repeating that part again does nothing aside of 
wasting one's mental resources used to parse the sentence.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Eli Zaretskii]

> Date: Fri, 28 Jun 2019 14:27:14 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> > I don't see why you needed to remove part of the text.  It isn't a
> > repetition: the first sentence talks about frames in general, the
> > second only about the initial frame.  The bit about the init file is
> > only relevant to the latter.
> 
> The specific part of text being removed sounds as"in order to set the 
> size of a frame in pixels, ", which explains what happens when variable 
> is non-nil.
> 
> However, if you read both of two paragraphs of documentation, you may 
> find that the 1st paragraph already explains the technical details 
> behind the variable, and the "non-nil" word in particular appears twice.
> 
> At that point, if reader came to 2nd paragraph, they probably know what 
> Emacs does when variable is non-nil; or at least they know where to 
> look that up. So, repeating that part again does nothing aside of 
> wasting one's mental resources used to parse the sentence.

I think you read "resize a frame" and "set the size of a frame" as
referring to the same operation.  But they aren't: the former is about
changing the size of an existing frame with a mouse or with
set-frame-size, whereas the latter is about doing other things that
implicitly require the frame's size to have pixel resolution.

So no, this is not repetition, and should not be removed.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Konstantin Kharlamov]

В Пт, июн 28, 2019 at 16:16, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  Date: Fri, 28 Jun 2019 14:27:14 +0300
>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>  Cc: 36250@debbugs.gnu.org
>> 
>>  > I don't see why you needed to remove part of the text.  It isn't a
>>  > repetition: the first sentence talks about frames in general, the
>>  > second only about the initial frame.  The bit about the init file 
>> is
>>  > only relevant to the latter.
>> 
>>  The specific part of text being removed sounds as"in order to set 
>> the
>>  size of a frame in pixels, ", which explains what happens when 
>> variable
>>  is non-nil.
>> 
>>  However, if you read both of two paragraphs of documentation, you 
>> may
>>  find that the 1st paragraph already explains the technical details
>>  behind the variable, and the "non-nil" word in particular appears 
>> twice.
>> 
>>  At that point, if reader came to 2nd paragraph, they probably know 
>> what
>>  Emacs does when variable is non-nil; or at least they know where to
>>  look that up. So, repeating that part again does nothing aside of
>>  wasting one's mental resources used to parse the sentence.
> 
> I think you read "resize a frame" and "set the size of a frame" as
> referring to the same operation.  But they aren't: the former is about
> changing the size of an existing frame with a mouse or with
> set-frame-size, whereas the latter is about doing other things that
> implicitly require the frame's size to have pixel resolution.
> 
> So no, this is not repetition, and should not be removed.

Right, but the 1st paragraph also says "If this is non-nil, […] frame 
sizes can increase/decrease by one pixel". I.e. this says that setting 
the variable to non-nil makes further operations on frames to have 
one-pixel resolution — which is the same as what the "in order to set 
the size of a frame in pixels," tries to convey.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Eli Zaretskii]

> Date: Fri, 28 Jun 2019 16:59:45 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> > I think you read "resize a frame" and "set the size of a frame" as
> > referring to the same operation.  But they aren't: the former is about
> > changing the size of an existing frame with a mouse or with
> > set-frame-size, whereas the latter is about doing other things that
> > implicitly require the frame's size to have pixel resolution.
> > 
> > So no, this is not repetition, and should not be removed.
> 
> Right, but the 1st paragraph also says "If this is non-nil, […] frame 
> sizes can increase/decrease by one pixel".

Yes, but it doesn't say you can _set_ the size at pixel granularity to
begin with.

> I.e. this says that setting the variable to non-nil makes further
> operations on frames to have one-pixel resolution

That's your interpretation, but the text doesn't say that, it says
something slightly different.  Thus the second paragraph is not
repetition.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Konstantin Kharlamov]

В Пт, июн 28, 2019 at 17:22, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  Date: Fri, 28 Jun 2019 16:59:45 +0300
>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>  Cc: 36250@debbugs.gnu.org
>> 
>>  > I think you read "resize a frame" and "set the size of a frame" as
>>  > referring to the same operation.  But they aren't: the former is 
>> about
>>  > changing the size of an existing frame with a mouse or with
>>  > set-frame-size, whereas the latter is about doing other things 
>> that
>>  > implicitly require the frame's size to have pixel resolution.
>>  >
>>  > So no, this is not repetition, and should not be removed.
>> 
>>  Right, but the 1st paragraph also says "If this is non-nil, […] 
>> frame
>>  sizes can increase/decrease by one pixel".
> 
> Yes, but it doesn't say you can _set_ the size at pixel granularity to
> begin with.
> 
>>  I.e. this says that setting the variable to non-nil makes further
>>  operations on frames to have one-pixel resolution
> 
> That's your interpretation, but the text doesn't say that, it says
> something slightly different.  Thus the second paragraph is not
> repetition.

Ah, I think I see, you probably read the
	"to non-nil         in order to set the size of a frame in pixels"
as
	"to a numeric value in order to set the size of a frame in pixels".

I had such interpretation too in mind. However note that 
frame_resize_pixelwise in C code is mostly used as a boolean. The only 
place where it's used as a numeric variable are 2 lines in src/widget.c:

	276:  ew->core.width = (frame_resize_pixelwise
	279:  ew->core.height = (frame_resize_pixelwise

In particular, if you look at the patch that started the topic, you'll 
find out that its value is not currently used to set width/height of a 
frame: instead it's either 1 or line-height/column-width.

bug#36250: [PATCH] Improve a bit frame-resize-pixelwise documentation

[Eli Zaretskii]

> Date: Fri, 28 Jun 2019 17:34:50 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 36250@debbugs.gnu.org
> 
> Ah, I think I see, you probably read the
> 	"to non-nil         in order to set the size of a frame in pixels"
> as
> 	"to a numeric value in order to set the size of a frame in pixels".

No, the value is boolean.

The issue is a different one: "resizing" a frame vs "setting its
size", in particular when maximizing it.  These are two different (but
related) operations, and each paragraph talks about one of them.

bug#36250: [PATCH v3] Allow Emacs to be resized arbitrarily

[Lars Ingebrigtsen]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Oh well, let's close this then. I'd still like to improve
> documentation for frame-resize-pixelwise to mention that this variable
> needs to be changed before Emacs window appears. Because until Martin
> mentioned that, it looked like the variable doesn't work.

This was a very confusing thread, but I think the conclusion was that 1)
the proposed patch shouldn't be applied, and 2) the documentation for
frame-resize-pixelwise was OK.

So I'm closing this bug report.  If there is more to be worked on here,
send a message to the debbugs mail address, and we'll reopen the bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no