From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Resizing windows after display-buffer Date: Mon, 25 Apr 2011 15:00:33 +0200 Message-ID: References: <87oc3v8b8z.fsf@stupidchicken.com> <4DB53246.7040600@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1303736484 7466 80.91.229.12 (25 Apr 2011 13:01:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Apr 2011 13:01:24 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 25 15:01:20 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QELPh-0007Or-VW for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 15:01:18 +0200 Original-Received: from localhost ([::1]:49215 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QELPh-0004BB-JE for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2011 09:01:17 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QELPf-0004Ai-15 for emacs-devel@gnu.org; Mon, 25 Apr 2011 09:01:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QELPd-0006p0-Qg for emacs-devel@gnu.org; Mon, 25 Apr 2011 09:01:14 -0400 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:33938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QELPd-0006on-Ny for emacs-devel@gnu.org; Mon, 25 Apr 2011 09:01:13 -0400 Original-Received: by yib18 with SMTP id 18so753090yib.0 for ; Mon, 25 Apr 2011 06:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=z3OCFBsH71lifCiEfWReLHaCa/uK40Q8C4TN1RxGgQo=; b=Dn5wdlBBZHah7t7uCgv+kNftErw6DwxY+hcsWEztXdbvgZIA5isiGWa6pyFtqApWAg W2ub8xL0RtcN/y/+Jzzw5ZYdTxFDw6xr+A1xBkll9RKszX1hSK9KK3lMKJSikfmBmktH quIH+L9yLbVcru3OQ/c4SNIUvzNmA3rmnVFfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=pWI0DMQ2DGJl+iCwFf0zHXdUhmtmJyX5GUx9DYbPYcTTpClaAkJrX85zAM0DfVt8zv zcFl9MvEpNX3rlzrjZlyPxUvYssVr8jrR/dugLP8dUvn8OsfvWCZD1i9XGF49b18X6Zy GpxOuBXdZefpH2nXrhgheR2pvf4pS5BYhx8V8= Original-Received: by 10.236.72.226 with SMTP id t62mr3804999yhd.495.1303736473155; Mon, 25 Apr 2011 06:01:13 -0700 (PDT) Original-Received: by 10.147.182.5 with HTTP; Mon, 25 Apr 2011 06:00:33 -0700 (PDT) In-Reply-To: <4DB53246.7040600@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.218.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138730 Archived-At: On Mon, Apr 25, 2011 at 10:35, martin rudalics wrote: > I suppose the `fit-window-to-buffer' feature should probably depend on > the buffer name much like the options `same-window-buffer-names' or > `special-display-buffer-names' so a user can choose the set of buffers > where the windows should fit. Yes. > This means the `fit-window-to-buffer' scheme should probably only apply > to new windows. =C2=A0In the case you describe we have also to observe th= ings > like `even-window-heights' whose interaction with `fit-window-to-buffer' > seems yet unresolved at the moment. In my case `even-window-heights' is set to nil quite soon in .emacs :-) > Likely `fit-window-to-buffer' > should prevail, but should we, for example, even sizes when both buffers > are to large to fit the window? I cannot answer that, because I haven't ever thought about `even-window-heights' =3D=3D t. > We already have a defcustom like `dired-shrink-to-fit'. =C2=A0Also note t= hat > `temp-buffer-resize-mode' only applies to the `display-buffer' call > itself. =C2=A0Thereafter, it does not have any effect - changing the size= of > characters or the text of the buffer doesn't trigger resizing of the > window. =C2=A0Hence calling this a mode seems a bit exaggerated. In most cases, I'm not worried about not resizing the window after creation; many modes do not require it (help,occur, ielm, inferior interpreters), and for those that I want, I use an advice or a hook to call fit-window-to-buffer. But it would be nice to have a true minor-mode, of course. > So the question is why you think that activating a minor mode from a > mode hook is more convenient than setting an option from that hook. If by "setting an option from that hook" you mean setting a local variable in the buffer before it is displayed, then I'm OK. =C2=A0 =C2=A0 Juanma