all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>, "'martin rudalics'" <rudalics@gmx.at>
Cc: 11276@debbugs.gnu.org
Subject: bug#11276: minibuffers windows can no longer explictly be resized
Date: Thu, 19 Apr 2012 08:13:03 -0700	[thread overview]
Message-ID: <EC35619F77E0437AB5CD9BB92AB36C99@us.oracle.com> (raw)
In-Reply-To: <83zka7iy7t.fsf@gnu.org>

> resize-mini-windows is a misnomer: it actually means "mini-window size
> is controlled by display engine".  That's why window-sizing commands
> in previous versions never paid heed to it, only redisplay did.  And
> that's why, quite counter-intuitively, setting it to _nil_ allows the
> user to resize the mini-window.
> 
> We could make the implementation more in line with the name in future
> versions, if we want, of course.

1. The right way to go is to decide first on the behavior you want.  Then base
the name on what it actually does.  If it needs to be renamed based on the
desired behavior then rename it, deprecating and temporarily aliasing the old
name.

It does not make much sense to instead design the behavior based on what the
name happens to be - unless that behavior is what you want anyway.  IOW, design
and name together; don't constrain the design to an existing name.

2. Wrt naming something that happens automatically (and possibly prevents or
overrides manual change by a user - in this case resizing): Use "auto" or
"automatic".  In this case, call it "autosize", "autoresize",
"automatic-(re)size", or some such.  That suggests that (a) the behavior is
automatic and (b) you might not be able to override it manually.

If the behavior of this option should be to allow automatic resizing (which
might or might not prevent manual resizing, depending on the design), then call
it something like "auto-resize-minibuffer" or "auto-resize-minibuf-window".

3. I've already said before that it is wrong to use only "mini" here.  This is
not just a mini-window, i.e., a small window - it is a minibuffer window.  See
bug #3320, deemed "wont-fix" by Lars:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3320.  Perhaps now that others
consider that `resize-mini-windows' is a misnomer (for additional reasons), this
misuse of "mini" can be reconsidered.

4. It might also be wrong (unnecessary for users) to refer here to minibuffer
window_s_ (plural).  In most contexts users do not need to know or care about
the existence of multiple minibuffer windows.  And in this case, unless the
option behavior does something specific that needs to call user attention to
multiple windows, Occam advises to just use the singular in the name.  Nuances,
if need be, can be pointed out in the doc.

5. And in this case it would perhaps not be inappropriate to refer to
auto-resizing of the minibuffer and not bother to add "window".  True, someone
using apropos for "window" would not find it, but a search for "minibuf" would:
`auto-resize-minibuffer'.






  reply	other threads:[~2012-04-19 15:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19  1:04 bug#11276: minibuffers windows can no longer explictly be resized Glenn Morris
2012-04-19  6:56 ` martin rudalics
2012-04-19  7:12   ` Glenn Morris
2012-04-19 10:42     ` martin rudalics
2012-04-19 14:37       ` Eli Zaretskii
2012-04-19 15:13         ` Drew Adams [this message]
2012-04-19 17:18         ` martin rudalics
2012-04-20  7:43           ` Eli Zaretskii
2012-04-20 10:01             ` martin rudalics
2012-04-20 10:16               ` Eli Zaretskii
2012-04-21  1:01               ` Glenn Morris
2012-04-19 14:31   ` Eli Zaretskii
2012-04-19 17:23     ` martin rudalics
2012-04-20  7:47       ` Eli Zaretskii
2012-04-20 10:01         ` martin rudalics
2012-04-20 10:49           ` Eli Zaretskii
2012-04-20 12:05             ` martin rudalics
2012-04-20 14:17               ` Eli Zaretskii
2012-04-20 15:31                 ` martin rudalics
2012-04-19 14:28 ` Eli Zaretskii

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=EC35619F77E0437AB5CD9BB92AB36C99@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=11276@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rudalics@gmx.at \
    /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.