From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Mon, 8 Aug 2011 14:59:53 +1000 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@gmx.at> <4E248102.6080904@gmx.at> <4E380918.3060806@gmx.at> <4E397611.5020603@gmx.at> <4E3C13D4.9000707@gmx.at> <4E3D4592.40809@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1312779606 28390 80.91.229.12 (8 Aug 2011 05:00:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2011 05:00:06 +0000 (UTC) Cc: martin rudalics , Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 08 07:00:02 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 1QqHwV-0007bv-9Y for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 06:59:59 +0200 Original-Received: from localhost ([::1]:36718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqHwU-00047e-O1 for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 00:59:58 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqHwS-00047X-In for emacs-devel@gnu.org; Mon, 08 Aug 2011 00:59:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqHwR-0002dZ-Au for emacs-devel@gnu.org; Mon, 08 Aug 2011 00:59:56 -0400 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:37702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqHwR-0002dR-80 for emacs-devel@gnu.org; Mon, 08 Aug 2011 00:59:55 -0400 Original-Received: by yib2 with SMTP id 2so2462889yib.0 for ; Sun, 07 Aug 2011 21:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=shW9zUBb6BoOdGLVby/1ahDxrOtg4YR/m+CnCkmmPZ8=; b=q3ADKmVpMZ2gjeQtWkTEWZhoIoZWwo4ul/0I5UdwSCAQ84rYKoUwzLm6DwncX6Iw1Z u6g+/Pe6HBFqQUoRTahre5oAKTs85f24BkPWm5TutlwIGym2wyOmSFI3aBtNSM0TnSi/ K1zeBHJeltIvMzOQYYEE6HGUZcDb+QISkSkJQ= Original-Received: by 10.42.29.196 with SMTP id s4mr5385992icc.12.1312779593570; Sun, 07 Aug 2011 21:59:53 -0700 (PDT) Original-Received: by 10.231.15.12 with HTTP; Sun, 7 Aug 2011 21:59:53 -0700 (PDT) In-Reply-To: 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:142999 Archived-At: On Mon, Aug 8, 2011 at 12:41 PM, Stefan Monnier wrote: > While you don't hear them, a majority of users like the new features we > enable in each Emacs release. =A0So, 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