emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications


From: Tim Cross
Subject: Re: display-buffer-alist simplifications
Date: Mon, 8 Aug 2011 14:59:53 +1000

On Mon, Aug 8, 2011 at 12:41 PM, Stefan Monnier
<address@hidden> wrote:

> While you don't hear them, a majority of users like the new features we
> enable in each Emacs release.  So, even if keeping the default
> minimalistic would satisfy the few people who complain, it would not
> satisfy the silent majority (who otherwise might not even have known
> that such a feature could exist).
>

While I agree with much of what you say regarding change and the
associated difficulties that come with it, I think the above is more
wishful thinking than anything else. The silent majority, by
definition, is silent. You do not know whether they liked the change
and cannot assume so. They may like it, they may dislike it, but don't
see any point in saying anything or more likely, are blissfully
unaware anything has changed. To assume the silent majority is in
favour tends to paint those who raise objection as nothing more than a
complaining minority who don't like change. While this may sometimes
be true, it is not always true. Those who dislike the change may
simply be those who are directly affected by it and in fact, may be
the majority who are directly affected. In some cases, change is
justified on the basis that in the long-term it will produce a better
outcome for everyone. However, this does not mean those who seem
resistant can just be ignored as a noisy minority. Those making the
changes need to demonstrate who those affected will have their needs
met and if they won't, why the change will be beneficial, even if
initially accompanied by some discomfort.

On something more specific to display-buffer-alist, I just looked at
the doc string again and either I'm getting use to it, or it has
improved from the last time I tried to digest it. I now *think* I may
understand how to use it (at least for the simple cases where I
need/want to). However, I still think a doc string of over 280 lines
is excessive and wonder if part of the reason people have trouble
understanding it is that there are conflicting objectives in the
string. On one hand, trying to be very concise and on the other,
trying to explain something potentially complex.

Perhaps it would be better to be extremely brief and provide a link to
the relevant section of the elisp reference. Those reading the doc
string who need a quick reference/memory jog will be happy and those
needing more will know they have to follow the link to the reference
and be less likely to believe they really understand the variables
purpose just by the doc string.

Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]