face-remap.el patch to resize window

face-remap.el patch to resize window

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

Commands `text-scale-decrease', `text-scale-increase', and
`text-scale-adjust' (bound to `C-x C--', `C-x C-+', `C-x C-=',
and `C-x C-0') let you resize the text in the current buffer
by changing its scale factor.

When you shrink or enlarge the apparent text size this way,
however, the window takes no notice of it.  In particular,
although shrinking text can result in extra horizontal
space at the right, window commands do not see this space
as extra (available).

With this patch, user option `text-scale-resize-window' lets
you automatically resize the selected window (horizontally,
vertically, or both) when text is resized, so that the way the
window fits the buffer text remains relatively constant.
Shrinking the text in one window shrinks that window, giving
more space to adjacent windows.

Feel free to change the default value for the option (e.g. to nil, to have no
effect by default). Feel free to accept the patch or ignore it.

[For anyone who might be interested in a version that also resizes a one-window
frame: http://www.emacswiki.org/emacs/face-remap%2b.el.]

[-- Attachment #2: face-remap-2009-06-22.patch --]
[-- Type: application/octet-stream, Size: 3126 bytes --]

diff -c -w face-remap.el face-remap-patched-2009-06-22.el
*** face-remap.el	Mon Jun 22 10:06:24 2009
--- face-remap-patched-2009-06-22.el	Mon Jun 22 11:41:02 2009
***************
*** 191,196 ****
--- 191,207 ----
    :type 'number
    :version "23.1")
  
+ (defcustom text-scale-resize-window t
+   "Non-nil means text scaling resizes the window accordingly.
+ For example, if you use `C-x C--' (`text-scale-decrease')' to make the
+ text smaller, then the window is made smaller by a similar factor."
+   :type '(choice
+           (const :tag "Do not resize window when scale text"  nil)
+           (const :tag "Resize window when scale text"         t)
+           (const :tag "Resize only horizontally"              horizontally)
+           (const :tag "Resize only vertically"                vertically))
+   :group 'display)
+ 
  ;; current remapping cookie for text-scale-mode
  (defvar text-scale-mode-remapping nil)
  (make-variable-buffer-local 'text-scale-mode-remapping)
***************
*** 237,247 ****
  Each step scales the height of the default face by the variable
  `text-scale-mode-step' (a negative number of steps decreases the
  height by the same amount).  As a special case, an argument of 0
! will remove any scaling currently active."
    (interactive "p")
    (setq text-scale-mode-amount
  	(if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
!   (text-scale-mode (if (zerop text-scale-mode-amount) -1 1)))
  
  ;;;###autoload
  (defun text-scale-decrease (dec)
--- 248,277 ----
  Each step scales the height of the default face by the variable
  `text-scale-mode-step' (a negative number of steps decreases the
  height by the same amount).  As a special case, an argument of 0
! removes any scaling currently active.
! 
! If option `text-scale-resize-window' is non-nil, then resize the
! selected window accordingly, so as to keep roughly the same text
! visible in the window.  See option `text-scale-resize-window' for the
! possible behaviors."
    (interactive "p")
+   (let* ((oamount       (if text-scale-mode text-scale-mode-amount 0))
+          (scale-factor  (expt text-scale-mode-step (if (= inc 0) (- oamount) inc)))
+          (edges         (window-edges))
+          (owidth        (- (nth 2 edges) (nth 0 edges)))
+          (oheight       (- (nth 3 edges) (nth 1 edges))))
      (setq text-scale-mode-amount
            (if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
!     (text-scale-mode (if (zerop text-scale-mode-amount) -1 1))
!     (when text-scale-resize-window
!       (unless (eq text-scale-resize-window 'vertically)
!         (condition-case nil
!             (enlarge-window-horizontally (round (- (* owidth scale-factor) owidth)))
!           (error nil)))
!       (unless (eq text-scale-resize-window 'horizontally)
!         (condition-case nil
!             (enlarge-window (round (- (* oheight scale-factor) oheight)))
!           (error nil))))))
  
  ;;;###autoload
  (defun text-scale-decrease (dec)

Diff finished.  Mon Jun 22 11:42:00 2009

face-remap.el patch to resize window

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Resending.


-----Original Message-----
From: Drew Adams Sent: Monday, June 22, 2009 1:40 PM

Commands `text-scale-decrease', `text-scale-increase', and
`text-scale-adjust' (bound to `C-x C--', `C-x C-+', `C-x C-=',
and `C-x C-0') let you resize the text in the current buffer
by changing its scale factor.

When you shrink or enlarge the apparent text size this way,
however, the window takes no notice of it.  In particular,
although shrinking text can result in extra horizontal
space at the right, window commands do not see this space
as extra (available).

With this patch, user option `text-scale-resize-window' lets
you automatically resize the selected window (horizontally,
vertically, or both) when text is resized, so that the way the
window fits the buffer text remains relatively constant.
Shrinking the text in one window shrinks that window, giving
more space to adjacent windows.

Feel free to change the default value for the option (e.g. to nil, to have no
effect by default). Feel free to accept the patch or ignore it.

[For anyone who might be interested in a version that also resizes a one-window
frame: http://www.emacswiki.org/emacs/face-remap%2b.el.]

[-- Attachment #2: face-remap-2009-06-22.patch --]
[-- Type: application/octet-stream, Size: 3126 bytes --]

diff -c -w face-remap.el face-remap-patched-2009-06-22.el
*** face-remap.el	Mon Jun 22 10:06:24 2009
--- face-remap-patched-2009-06-22.el	Mon Jun 22 11:41:02 2009
***************
*** 191,196 ****
--- 191,207 ----
    :type 'number
    :version "23.1")
  
+ (defcustom text-scale-resize-window t
+   "Non-nil means text scaling resizes the window accordingly.
+ For example, if you use `C-x C--' (`text-scale-decrease')' to make the
+ text smaller, then the window is made smaller by a similar factor."
+   :type '(choice
+           (const :tag "Do not resize window when scale text"  nil)
+           (const :tag "Resize window when scale text"         t)
+           (const :tag "Resize only horizontally"              horizontally)
+           (const :tag "Resize only vertically"                vertically))
+   :group 'display)
+ 
  ;; current remapping cookie for text-scale-mode
  (defvar text-scale-mode-remapping nil)
  (make-variable-buffer-local 'text-scale-mode-remapping)
***************
*** 237,247 ****
  Each step scales the height of the default face by the variable
  `text-scale-mode-step' (a negative number of steps decreases the
  height by the same amount).  As a special case, an argument of 0
! will remove any scaling currently active."
    (interactive "p")
    (setq text-scale-mode-amount
  	(if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
!   (text-scale-mode (if (zerop text-scale-mode-amount) -1 1)))
  
  ;;;###autoload
  (defun text-scale-decrease (dec)
--- 248,277 ----
  Each step scales the height of the default face by the variable
  `text-scale-mode-step' (a negative number of steps decreases the
  height by the same amount).  As a special case, an argument of 0
! removes any scaling currently active.
! 
! If option `text-scale-resize-window' is non-nil, then resize the
! selected window accordingly, so as to keep roughly the same text
! visible in the window.  See option `text-scale-resize-window' for the
! possible behaviors."
    (interactive "p")
+   (let* ((oamount       (if text-scale-mode text-scale-mode-amount 0))
+          (scale-factor  (expt text-scale-mode-step (if (= inc 0) (- oamount) inc)))
+          (edges         (window-edges))
+          (owidth        (- (nth 2 edges) (nth 0 edges)))
+          (oheight       (- (nth 3 edges) (nth 1 edges))))
      (setq text-scale-mode-amount
            (if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
!     (text-scale-mode (if (zerop text-scale-mode-amount) -1 1))
!     (when text-scale-resize-window
!       (unless (eq text-scale-resize-window 'vertically)
!         (condition-case nil
!             (enlarge-window-horizontally (round (- (* owidth scale-factor) owidth)))
!           (error nil)))
!       (unless (eq text-scale-resize-window 'horizontally)
!         (condition-case nil
!             (enlarge-window (round (- (* oheight scale-factor) oheight)))
!           (error nil))))))
  
  ;;;###autoload
  (defun text-scale-decrease (dec)

Diff finished.  Mon Jun 22 11:42:00 2009

RE: face-remap.el patch to resize window

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

Resending - got no response.

Doesn't it make sense to resize the window to take advantage of space freed up
when text is scaled smaller? As an option at least?

Option `text-scale-resize-window' lets you recuperate such space horizontally,
vertically, both, or neither (do nothing).


-----Original Message-----
From: Drew Adams Sent: Monday, June 22, 2009 1:40 PM

Commands `text-scale-decrease', `text-scale-increase', and
`text-scale-adjust' (bound to `C-x C--', `C-x C-+', `C-x C-=',
and `C-x C-0') let you resize the text in the current buffer
by changing its scale factor.

When you shrink or enlarge the apparent text size this way,
however, the window takes no notice of it.  In particular,
although shrinking text can result in extra horizontal
space at the right, window commands do not see this space
as extra (available).

With this patch, user option `text-scale-resize-window' lets
you automatically resize the selected window (horizontally,
vertically, or both) when text is resized, so that the way the
window fits the buffer text remains relatively constant.
Shrinking the text in one window shrinks that window, giving
more space to adjacent windows.

Feel free to change the default value for the option (e.g. to nil, to have no
effect by default). Feel free to accept the patch or ignore it.

[For anyone who might be interested in a version that also resizes a one-window
frame: http://www.emacswiki.org/emacs/face-remap%2b.el.]

[-- Attachment #2: face-remap-2009-06-22.patch --]
[-- Type: application/octet-stream, Size: 3126 bytes --]

diff -c -w face-remap.el face-remap-patched-2009-06-22.el
*** face-remap.el	Mon Jun 22 10:06:24 2009
--- face-remap-patched-2009-06-22.el	Mon Jun 22 11:41:02 2009
***************
*** 191,196 ****
--- 191,207 ----
    :type 'number
    :version "23.1")
  
+ (defcustom text-scale-resize-window t
+   "Non-nil means text scaling resizes the window accordingly.
+ For example, if you use `C-x C--' (`text-scale-decrease')' to make the
+ text smaller, then the window is made smaller by a similar factor."
+   :type '(choice
+           (const :tag "Do not resize window when scale text"  nil)
+           (const :tag "Resize window when scale text"         t)
+           (const :tag "Resize only horizontally"              horizontally)
+           (const :tag "Resize only vertically"                vertically))
+   :group 'display)
+ 
  ;; current remapping cookie for text-scale-mode
  (defvar text-scale-mode-remapping nil)
  (make-variable-buffer-local 'text-scale-mode-remapping)
***************
*** 237,247 ****
  Each step scales the height of the default face by the variable
  `text-scale-mode-step' (a negative number of steps decreases the
  height by the same amount).  As a special case, an argument of 0
! will remove any scaling currently active."
    (interactive "p")
    (setq text-scale-mode-amount
  	(if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
!   (text-scale-mode (if (zerop text-scale-mode-amount) -1 1)))
  
  ;;;###autoload
  (defun text-scale-decrease (dec)
--- 248,277 ----
  Each step scales the height of the default face by the variable
  `text-scale-mode-step' (a negative number of steps decreases the
  height by the same amount).  As a special case, an argument of 0
! removes any scaling currently active.
! 
! If option `text-scale-resize-window' is non-nil, then resize the
! selected window accordingly, so as to keep roughly the same text
! visible in the window.  See option `text-scale-resize-window' for the
! possible behaviors."
    (interactive "p")
+   (let* ((oamount       (if text-scale-mode text-scale-mode-amount 0))
+          (scale-factor  (expt text-scale-mode-step (if (= inc 0) (- oamount) inc)))
+          (edges         (window-edges))
+          (owidth        (- (nth 2 edges) (nth 0 edges)))
+          (oheight       (- (nth 3 edges) (nth 1 edges))))
      (setq text-scale-mode-amount
            (if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
!     (text-scale-mode (if (zerop text-scale-mode-amount) -1 1))
!     (when text-scale-resize-window
!       (unless (eq text-scale-resize-window 'vertically)
!         (condition-case nil
!             (enlarge-window-horizontally (round (- (* owidth scale-factor) owidth)))
!           (error nil)))
!       (unless (eq text-scale-resize-window 'horizontally)
!         (condition-case nil
!             (enlarge-window (round (- (* oheight scale-factor) oheight)))
!           (error nil))))))
  
  ;;;###autoload
  (defun text-scale-decrease (dec)

Diff finished.  Mon Jun 22 11:42:00 2009

Re: face-remap.el patch to resize window

[Stefan Monnier]

> Doesn't it make sense to resize the window to take advantage of space
> freed up when text is scaled smaller? As an option at least?

To me the fact that text-scale-increase doesn't change the window's
size is one of its greatest features.  Resizing windows is the job of
the window-manager (and most of my window's sizes are dicated by the
screen size).
But if people like it, I won't object to this feature as an option, as
long as it's well integrated.


        Stefan

RE: face-remap.el patch to resize window

[Drew Adams]

> > Doesn't it make sense to resize the window to take 
> > advantage of space freed up when text is scaled
> > smaller? As an option at least?
> 
> To me the fact that text-scale-increase doesn't change the window's
> size is one of its greatest features.

The savings in space come when you decrease text size, not increase it.

In any case, given your personal preference, you would simply leave the option
value as nil. This is about giving users the option. The default value can be
nil.

> Resizing windows is the job of the window-manager (and most
> of my window's sizes are dicated by the screen size).

Of course, if your windows are full-screen, then this wouldn't be very useful to
you. But some users split windows; some often have windows that are less than
full-screen.

> But if people like it, I won't object to this feature as an option, as
> long as it's well integrated.

The small patch I sent does that.

Re: face-remap.el patch to resize window

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Doesn't it make sense to resize the window to take advantage of space
>> freed up when text is scaled smaller? As an option at least?
>
> To me the fact that text-scale-increase doesn't change the window's
> size is one of its greatest features.  Resizing windows is the job of
> the window-manager (and most of my window's sizes are dicated by the
> screen size).
> But if people like it, I won't object to this feature as an option, as
> long as it's well integrated.

It sounds like a very confusing feature -- remember that
text-scale-increase applies to a single buffer, but windows are
typically used for many buffers in turn.

It could be useful for very specific cases, but it seems somehow wrong
to have it as a global setting.

-Miles

-- 
Logic, n. The art of thinking and reasoning in strict accordance with the
limitations and incapacities of the human misunderstanding.

Re: face-remap.el patch to resize window

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]


What do you think of the following patch, which is an alternative
approach based on hooks?

Basically to get the behavior you want, you can do:

   (add-hook 'text-scale-mode-hook 'text-scale-mode-adjust-window-size)

-Miles

-- 
Corporation, n. An ingenious device for obtaining individual profit without
individual responsibility.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: text-scale-mode-hooks-20090810-0.patch --]
[-- Type: text/x-diff, Size: 3367 bytes --]

diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index c899a8d..53e99ec 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -203,6 +203,19 @@ Each positive or negative step scales the default face height by this amount."
 (defvar text-scale-mode-amount 0)
 (make-variable-buffer-local 'text-scale-mode-amount)
 
+(defvar text-scale-mode-old-scale-factor nil
+  "Previously active scale factor for default face :height
+attribute when `text-scale-mode-hook' is called, or nil if
+text-scale-mode was not previously active (meaning the old scale
+factor was 1.0).")
+(make-variable-buffer-local 'text-scale-mode-old-scale-factor)
+
+(defvar text-scale-mode-scale-factor nil
+  "Scale factor for default face :height attribute when
+`text-scale-mode-hook' is called, or nil if text-scale-mode will
+be deactivated (meaning the scale factor is 1.0).")
+(make-variable-buffer-local 'text-scale-mode-scale-factor)
+
 (define-minor-mode text-scale-mode
   "Minor mode for displaying buffer text in a larger/smaller font than usual.
 
@@ -221,14 +234,55 @@ disable `text-scale-mode' as necessary)."
   (setq text-scale-mode-lighter
 	(format (if (>= text-scale-mode-amount 0) "+%d" "%d")
 		text-scale-mode-amount))
+  (setq text-scale-mode-old-scale-factor
+	(nth 2 text-scale-mode-remapping))
+  (setq text-scale-mode-scale-factor
+	(and text-scale-mode
+	     (expt text-scale-mode-step text-scale-mode-amount)))
   (setq text-scale-mode-remapping
 	(and text-scale-mode
 	     (face-remap-add-relative 'default
-					  :height
-					  (expt text-scale-mode-step
-						text-scale-mode-amount))))
+				      :height text-scale-mode-scale-factor)))
   (force-window-update (current-buffer)))
 
+(defun text-scale-mode-adjust-window-horizontal-size ()
+  "Change the horizontal size of the current window corresponding to ratio
+`text-scale-mode-scale-factor / text-scale-mode-old-scale-factor'.
+
+This function is intended to be used as a hook for `text-scale-mode-hook'."
+  (let* ((edges (window-edges))
+	 (owidth (- (nth 2 edges) (nth 0 edges)))
+	 (scale-factor
+	  (/ (or text-scale-mode-scale-factor 1.0)
+	     (or text-scale-mode-old-scale-factor 1.0))))
+    (condition-case nil
+	(enlarge-window-horizontally
+	 (round (- (* owidth scale-factor) owidth)))
+      (error nil))))
+
+(defun text-scale-mode-adjust-window-vertical-size ()
+  "Change the vertical size of the current window corresponding to ratio
+`text-scale-mode-scale-factor / text-scale-mode-old-scale-factor'.
+
+This function is intended to be used as a hook for `text-scale-mode-hook'."
+  (let* ((edges (window-edges))
+	 (oheight (- (nth 3 edges) (nth 1 edges)))
+	 (scale-factor
+	  (/ (or text-scale-mode-scale-factor 1.0)
+	     (or text-scale-mode-old-scale-factor 1.0))))
+    (condition-case nil
+	(enlarge-window
+	 (round (- (* oheight scale-factor) oheight)))
+      (error nil))))
+
+(defun text-scale-mode-adjust-window-size ()
+  "Change the size of the current window corresponding to ratio
+`text-scale-mode-scale-factor / text-scale-mode-old-scale-factor'.
+
+This function is intended to be used as a hook for `text-scale-mode-hook'."
+  (text-scale-mode-adjust-window-vertical-size)
+  (text-scale-mode-adjust-window-horizontal-size))
+
 ;;;###autoload
 (defun text-scale-set (level)
   "Set the scale factor of the default face in the current buffer to LEVEL.

Re: face-remap.el patch to resize window

[Stefan Monnier]

> It sounds like a very confusing feature -- remember that
> text-scale-increase applies to a single buffer, but windows are
> typically used for many buffers in turn.

Very good point, thanks for reminding me.  Of course, for dedicated
windows this is usually not an issue.


        Stefan

RE: face-remap.el patch to resize window

[Drew Adams]

> remember that text-scale-increase applies to a single
> buffer, but windows are typically used for many
> buffers in turn.

I didn't forget. ;-)

And?

If you have the same buffer open in more than one window, only the current
window is resized when you scale the text.

Windows alone in their frame are not affected by this feature (not resized). It
is only when there are adjacent windows that could benefit that the current
window is resized.

It's an option. Use if you find it useful for you; otherwise don't.


Example (one use case):

Two buffers (two windows) side by side in a frame. You are working mainly in the
left buffer, but you want to see the right buffer also, without caring too much
for its details. So you shrink (Cx C--) the right buffer's text and its window
width.

Now and then, you want to see something more closely in the right buffer, while
still following in the left. You enlarge the right buffer's text (C-x C-=). The
window that has the larger text is larger; the window with the smaller text is
smaller (it needs less room).

The effect is that of a fisheye lens. For the buffer you are focusing on: larger
text and more space to view it. For the buffer you are not studying in detail:
smaller text and less space needed to view it.

One pill (C-=) makes you larger, and one pill (C--) makes you small...

> It could be useful for very specific cases,
> but it seems somehow wrong to have it as a global setting.

No reason given? What good to others is a judgment with no supporting rationale,
arguments or evidence?

Re: face-remap.el patch to resize window

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> It could be useful for very specific cases,
>> but it seems somehow wrong to have it as a global setting.
>
> No reason given? What good to others is a judgment with no supporting
> rationale, arguments or evidence?

The main problem is that I think it often depends on the buffer contents
(or etc) as to whether such window-adaptation is useful.

For instance, I shrink text for several reasons:

  1) To see more of the buffer at once; in this case, I probably don't
     want the window to shrink.  This is probably the most common case
     for me.

  2) To shrink a short buffer to take up less space, e.g. a help buffer;
     in this case, I often do want the window to shrink, or even better,
     to be re-fit to the buffer contents (like the help display
     functions do initially).

  3) To shrink a buffer that I want to keep on screen so I can keep an
     eye on it, but in many cases, only really care about the last
     bit -- e.g., a compile buffer, or log buffer which is being
     updated.  Often my goal is to make the window showing this buffer
     as small as possible or a little larger.  [and I often shrink the
     font to some absurdly small size, since I care more about motion
     and text-shape than actual contents]

So, really I want the behavior to vary depending on the situation; a
single "adapt windows" or "don't adapt windows" doesn't really suffice
for my usage.  However, a "clever" function that encodes my preferences
(as noted above) might be something I'd like to use.

That's why I like a hook-based situation (see earlier patch) that can
examine the situation and do something appropriate in an easily
user-adaptable way.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

RE: face-remap.el patch to resize window

[Drew Adams]

> The main problem is that I think it often depends on the 
> buffer contents (or etc) as to whether such window-adaptation
> is useful.

<snipped good info about why you might want window resizing to be
buffer-specific>

That's precisely an advantage of the variable approach. Just make the variable
buffer-local for given buffers.

Don't resize for buffer A, resize horizontally for buffer B, vertically for
buffer C, both for buffer D. Set the default for other buffers to whichever
behavior you prefer most of the time.

RE: face-remap.el patch to resize window

[Drew Adams]

> What do you think of the following patch, which is an alternative
> approach based on hooks?
> 
> Basically to get the behavior you want, you can do:
>    (add-hook 'text-scale-mode-hook 
>              'text-scale-mode-adjust-window-size)

If that's what it takes to get such a feature added, fine; please go for it.

I don't, however see any advantage of your hook hack over the patch I sent. And
you didn't cite any.

On the contrary, I see disadvantages of your approach:

1. The means of changing the setting (say from vertical to horizontal size
adjustment) is, well, removing and adding hook functions.

Why make users do that? With my patch, you can easily change the option value on
the fly using, say, `set-variable'.

2. What's more, a user could make the option buffer-local, and so have
window-resizing behavior be buffer-specific: don't resize, resize horizontally,
vertically, or both.


At any rate, for my personal use I already have what I need, so if you want to
add your patch to Emacs, I'm in favor.

Re: face-remap.el patch to resize window

[Stefan Monnier]

> Now and then, you want to see something more closely in the right
> buffer, while still following in the left.  You enlarge the right
> buffer's text (C-x C-=).  The window that has the larger text is
> larger; the window with the smaller text is smaller (it needs less
> room).

How 'bout Miles's suggestion to use your code but without a separate
config var, using text-scale-mode-hook instead?  That would sound like
a good idea to me.


        Stefan

RE: face-remap.el patch to resize window

[Drew Adams]

> How 'bout Miles's suggestion to use your code but without a separate
> config var, using text-scale-mode-hook instead?  That would sound like
> a good idea to me.

(No reason given.) Why?

I mentioned some disadvantages to using a hook. No one has mentioned any
advantages. Pronouncing a judgment without giving any reasons is not helpful. Do
you expect to persuade people just because you declare something good/bad?

Anyway, as I said, if that's what it takes to get such a feature in Emacs,
please go for it.

Re: face-remap.el patch to resize window

[Stefan Monnier]

>   1) To see more of the buffer at once; in this case, I probably don't
>      want the window to shrink.  This is probably the most common case
>      for me.

This is also my main use, tho I often also increase the text size to
make it more readable from afar (in that case increasing the window size
would also make sense, tho I'm usually already maxed out at that point
so it doesn't make any real difference).

>   2) To shrink a short buffer to take up less space, e.g. a help buffer;
>      in this case, I often do want the window to shrink, or even better,
>      to be re-fit to the buffer contents (like the help display
>      functions do initially).

This actually points to a need to mark a window as "fitted" so it can be
refitted dynamically (which would also affect frame resizing, C-x + and
things like that).

> That's why I like a hook-based situation (see earlier patch) that can
> examine the situation and do something appropriate in an easily
> user-adaptable way.

I don't know if it can be made automatic, really.  Maybe a separate
command (at least for your case nb 3) is preferable.


        Stefan

Re: face-remap.el patch to resize window

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> How 'bout Miles's suggestion to use your code but without a separate
>> config var, using text-scale-mode-hook instead?  That would sound like
>> a good idea to me.
>
> (No reason given.) Why?

Well the obvious reason is that it avoids hard-wiring behavior which we
believe to be to inflexible, and is a smaller change.

[The hook, after all, already exists; my patch mainly just records a bit
more information for it to use.]

> I mentioned some disadvantages to using a hook.

Hmm, the only real disadvantage I can see is that hooks aren't
well-supported by customize.  [As for "buffer localness", hooks, after
all, can also be buffer-local, or can examine a buffer-local variable to
determine their behavior.]

> No one has mentioned any advantages.

See above:  Smaller; more flexible.

Hooks (like other indirection mechanisms) are generally more flexible,
at some cost in user-friendliness and clarity.  So if there's very
commonly desired behavior, sometimes it's good to hard-wire it instead
of telling people to use a hook or whatever (even if an appropriate hook
already exists).  However as I've mentioned, it's not clear to me that
the described behavior in this case is generally useful/universal enough
to hard-wire.

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: face-remap.el patch to resize window

[Stefan Monnier]

>> How 'bout Miles's suggestion to use your code but without a separate
>> config var, using text-scale-mode-hook instead?  That would sound like
>> a good idea to me.
> (No reason given.) Why?

I'm not convinced that a global variable setting is the right solution.
So using a hook is good enough so users can get the same result, but
keeping it "low-profile" (i.e. still begging for a better solution).

> Anyway, as I said, if that's what it takes to get such a feature in Emacs,
> please go for it.

So you're saying that using a hook is indeed an approach that works?


        Stefan

RE: face-remap.el patch to resize window

[Drew Adams]

> > (No reason given.) Why?
> 
> Well the obvious reason is that it avoids hard-wiring 
> behavior which we believe to be to inflexible, and is
> a smaller change.

There is no inflexible, hard-wired behavior in the patch I sent. If the option
value is nil, nothing is done. If it is non-nil, then the window is resized.
Completely soft control, via a variable. User control, in fact -nothing is
softer. No hard-wiring, and nothing inflexible.

And my patch has 17% fewer lines than yours, if that's what you meant by
smaller. ;-)

> [The hook, after all, already exists; my patch mainly just 
> records a bit more information for it to use.]

These are each tiny patches. One adds a user variable and calls
`enlarge-window*' if the option value is non-nil. The other adds two internal
variables that record state and three alternative functions that call
`enlarge-window*'.

One makes text-scaling look at the option value and maybe change the window
size. The other provides window-sizing functions that you can add to the
text-scale hook. That's the only real difference, I think you'll agree.

I don't see either approach as unclean, inflexible, or hard-wired.

I see one approach that is user-friendly, with well-defined behavior that is
advertised to users clearly via a user option.

I see another approach that does nothing for users, unless they happen to read
the code, discover the potential hook functions, and add one of them to the
hook. And if a user wants to change the behavior, s?he needs to mess with
`add-hook' and `remove-hook' all over again.

> > I mentioned some disadvantages to using a hook.
> 
> Hmm, the only real disadvantage I can see
> is that hooks aren't well-supported by customize.

Not just Customize.

Hooks also do not facilitate on-the-fly addition/removal by users. A user cannot
get the equivalent of `set-variable' using hooks - s?he needs to fiddle with
some Lisp code (e.g. via `M-:').

And that includes making the behavior buffer-specific or updating a buffer-local
setting. With `set-variable', you just use a prefix arg to do that. With hooks,
you need to first use `remove-hook', then `add-hook', specifying the LOCAL flag
as appropriate.

The question is whether we really intend this for users. Using hooks instead is
somewhat of a copout IMO - making it seem like we did something. (E.g. to get
Drew off our backs. ;-) )

> [As for "buffer localness", hooks, after
> all, can also be buffer-local, or can examine a buffer-local 
> variable to determine their behavior.]

Sure, a user can always code something up. But _why_ make users do that, when
using an option is so much simpler for them?

You seem to suggests that your patch is easier for those working with the code
(though it's not). What about the users?

> > No one has mentioned any advantages.
> 
> See above:  Smaller; more flexible.
> Hooks (like other indirection mechanisms) are generally more flexible,

How is it smaller? More flexible for whom? Users?

> at some cost in user-friendliness and clarity.  So if there's very
> commonly desired behavior, sometimes it's good to hard-wire it

Apparently, code that examines a user option and reacts to it constitutes
"hard-wired" behavior, for you. That's a misleading designation.

Yes, you can add any behavior you want with a hook, so in that sense nothing
beats its flexibility - it does nothing, anything, and everything. The behavior
is undefined.

Yes, predefined behavior that reflects a user's intention through an option
value is, well, predetermined. IOW, it is well-defined. As you said, it has the
advantages of "user-friendliness and clarity".

> instead of telling people to use a hook or whatever (even if an 
> appropriate hook already exists).  However as I've mentioned,
> it's not clear to me that the described behavior in this case
> is generally useful/universal enough to hard-wire.

The point really seems to be that you're not convinced users should be offered
this behavior. ;-) But you're willing to provide the hook functions for it.
Sounds like that's as good as we're going to get.

It's still an improvement for users to have this possibility, no matter what
they need to do to use it. Please add the feature, one way or the other.

RE: face-remap.el patch to resize window

[Drew Adams]

> So you're saying that using a hook is indeed an approach that works?

Sure, why wouldn't it work?

Of course, users won't be likely to know about this feature. Not as likely as if
there were a user option that controlled the behavior. But that seems to be your
point anyway. ;-)

Re: face-remap.el patch to resize window

[Stefan Monnier]

> Of course, users won't be likely to know about this feature. Not as
> likely as if there were a user option that controlled the
> behavior. But that seems to be your point anyway. ;-)

Yes.


        Stefan