all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: wanted: someone to integrate frame-resizing code
Date: Fri, 28 May 2004 14:10:50 -0700	[thread overview]
Message-ID: <MEEKKIABFKKDFJMPIOEBGECPCEAA.drew.adams@oracle.com> (raw)

RMS suggested I provide emacs-devel a summary of our conclusions regarding
some code I wrote to resize frames, and ask if there is anyone who would be
willing to integrate it (I do not have the resources to do that). I've
tested the code in Emacs 20 and 21.3.50 on Windows.

The code is especially useful when pop-up-frames is non-nil; that is, when
you use frames instead of Emacs windows by default. The code is here:

 - http://www.emacswiki.org/elisp/shrink-fit.el - a command,
shrink-frame-to-fit, that fits a frame to its selected window (should
probably be renamed resize-frame)

 - http://www.emacswiki.org/elisp/shrink-fit-all.el - provides automatic
frame resizing when appropriate

There are user variables to turn resizing on & off. Automatic resizing
applies only to one-window frames (the selected window is one-window-p).

Requirements -

  * Frames should be automatically resized:

    - When you create a new frame for a buffer.

    - When you read a different buffer into a frame.

    - When you display a buffer whose contents have changed since last
display.
      For instance, when a *Help* frame is raised, you want it to be the
right size each time.

  * Frames should *not* be automatically resized:

    - When the frame's buffer and its contents have not changed since last
display.
      This is the case, for instance, for *Occur* when the source buffer
doesn't change and you just redisplay it to access a different source line.

    - When a buffer is displayed before it has been filled.
      This is the case, for instance, for output buffers like *grep*.

Ideally, the code logic would follow these requirements exactly. My code is
not so sophisticated. If someone integrates the code it would be good to
consider a smarter implementation.

I simply added frame resizing to each of the basic display functions
(display-buffer, pop-to-buffer, switch-to-buffer). Without other changes
elsewhere this doesn't take into account the two requirements of *not*
resizing when inappropriate.

For instance, occur-* commands call pop-to-buffer, and if the user already
manually sized the source-code buffer (and wants it to stay put), resizing
it automatically would be annoying. Similarly, in compile, you want to
resize the frame explicitly after the buffer is full, not prematurely when
display-buffer is called on an empty output buffer.

The way I dealt with this was essentially a hack: In those places where
resizing would be inappropriate, I set a variable that inhibited resizing in
the basic display functions like pop-to-buffer. This is equivalent to having
two versions of each display function like pop-to-buffer, one that resizes
and one that doesn't, and calling the right one (analogy:
find-file-no-select vs find-file).

In practice, I only found two places where I needed to inhibit automatic
resizing: compile-internal and occur. However, I did not test exhaustively
with Emacs 21; there are perhaps other places where resizing should not be
done. I've used this with Emacs 20 for years with no inconvenience, but I
don't use all of Emacs.

For a more sophisticated solution, perhaps it would be possible to detect
(in resize-frame) whether or not the buffer had changed (either a different
buffer or changed content) since the last resizing of that frame (no matter
how it was resized: by the user or by program).

If someone decides to take this up, feel free to contact me with questions.
If no one has the time or interest to take up the automatic resizing,
consider at least adding command resize-frame to Emacs
(http://www.emacswiki.org/elisp/shrink-fit.el).

Thanks

  Drew

P.S. For more info:
http://www.emacswiki.org/cgi-bin/wiki/Shrink-Wrapping_Frames

             reply	other threads:[~2004-05-28 21:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-28 21:10 Drew Adams [this message]
2004-05-28 22:08 ` wanted: someone to integrate frame-resizing code Stefan Monnier
2004-05-29  1:21   ` Drew Adams
2004-05-30 21:11     ` Stefan Monnier
2004-06-01  0:34       ` automatic frame-resizing Drew Adams

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=MEEKKIABFKKDFJMPIOEBGECPCEAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.