all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: cschol2112@googlemail.com, lekktu@gmail.com, 9873@debbugs.gnu.org
Subject: bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file
Date: Wed, 26 Oct 2011 07:08:42 -0400	[thread overview]
Message-ID: <E1RJ1Le-0006AV-47@fencepost.gnu.org> (raw)
In-Reply-To: <4EA7D13C.8060801@gmx.at> (message from martin rudalics on Wed, 26 Oct 2011 11:22:04 +0200)

> Date: Wed, 26 Oct 2011 11:22:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Christoph Scholtes <cschol2112@googlemail.com>, 9873@debbugs.gnu.org
> 
>  >> Thanks Juanma, this fixes the problem. I am not sure I understand what
>  >> other implications this has, though.

Lucky you.  I didn't understand a thing about it.

> The Elisp manual should cover `window-nest' in some detail.  Please have
> a look.

IMNSHO, the doc string needs "Some Work"®, as right now it's
impenetrable for mere mortals (this being is a user option).  Users
aren't, and shouldn't be, aware that windows are arranged in a tree.
Without a very good understanding of that, talking about "a new parent
window" and "binary tree of windows" misses the target by a very large
measure.

Besides, user options should be first and foremost be described in the
user manual, not in the ELisp manual.

After reading what's written in the ELisp manual (and digressing to
"Windows and Frames" for a while, to understand what the heck it is
talking about when it says "parent window"), I do understand what the
variable does in terms of the window tree, but still cannot tell I
understand its effects in practice, beyond the specific example of
splitting and unsplitting windows that is described there in detail.
Is this the only user-visible effect of this variable?  If so, why not
name it something that is related to resizing or splitting, and why
not say that in the doc string, instead of describing the window tree
and the "parent window" which a user will never see and does not care
about in the first place?  Since when do we explain user-level
features in terms of abstract data types and structures that are all
but invisible to users??

I'm sorry for being so blunt, but it's the first time I've read in an
Emacs manual a whole section, which does a very good job at describing
what it sets out to describe, but is completely useless for me as a
guide for understanding the practical implications of a certain user
option.





  reply	other threads:[~2011-10-26 11:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-26  2:03 bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file Christoph Scholtes
2011-10-26  2:16 ` Juanma Barranquero
2011-10-26  2:50   ` Christoph Scholtes
2011-10-26  2:52     ` Juanma Barranquero
2011-10-26  9:22       ` martin rudalics
2011-10-26 11:08         ` Eli Zaretskii [this message]
2011-10-26 14:22           ` martin rudalics
2011-10-26 18:30             ` Eli Zaretskii
2011-10-27  9:51               ` martin rudalics
2011-10-27 10:23                 ` Eli Zaretskii
2011-10-27 13:15                   ` martin rudalics
2011-10-27  3:39         ` Christoph Scholtes
2011-10-27  9:53           ` martin rudalics
2011-10-28  8:12             ` Juri Linkov
2011-10-28 17:16               ` martin rudalics
2011-10-31 10:11                 ` Juri Linkov
2011-10-31 10:27                   ` martin rudalics
2011-11-03 19:42                     ` Juri Linkov
2012-10-04 18:31             ` Juri Linkov
2012-10-04 18:51               ` martin rudalics
2012-10-04 19:40                 ` Juri Linkov
2012-10-05  7:03                   ` martin rudalics

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=E1RJ1Le-0006AV-47@fencepost.gnu.org \
    --to=eliz@gnu.org \
    --cc=9873@debbugs.gnu.org \
    --cc=cschol2112@googlemail.com \
    --cc=lekktu@gmail.com \
    --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.