From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Marking old window variables obsolete Date: Thu, 9 Aug 2012 07:12:57 -0700 Message-ID: <6863B68E762149B28EF9C1A159D441A3@us.oracle.com> References: <87fw7wpfid.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1344521598 5772 80.91.229.3 (9 Aug 2012 14:13:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 14:13:18 +0000 (UTC) To: "'Chong Yidong'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 09 16:13:17 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SzTUC-00015Q-6T for ged-emacs-devel@m.gmane.org; Thu, 09 Aug 2012 16:13:16 +0200 Original-Received: from localhost ([::1]:33524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzTUA-000298-LJ for ged-emacs-devel@m.gmane.org; Thu, 09 Aug 2012 10:13:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzTU2-00026t-EN for emacs-devel@gnu.org; Thu, 09 Aug 2012 10:13:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzTU1-0006SB-B1 for emacs-devel@gnu.org; Thu, 09 Aug 2012 10:13:06 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:39042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzTU1-0006S6-4H; Thu, 09 Aug 2012 10:13:05 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79ED3QX013558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 14:13:04 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79ED21F021487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 14:13:03 GMT Original-Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79ED2Z4019830; Thu, 9 Aug 2012 09:13:02 -0500 Original-Received: from dradamslap1 (/10.159.217.233) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 07:13:02 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87fw7wpfid.fsf@gnu.org> Thread-Index: Ac12E3OhsVsSRMPoStyVros4+636JgAIY+mw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 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:152362 Archived-At: > The new display-buffer machinery still supports the following > variables: > > special-display-buffer-names > special-display-regexps > special-display-frame-alist > special-display-function > same-window-buffer-names > same-window-regexps > display-buffer-reuse-frames > > I think we can mark these as obsolete for 24.2. Any objections? > > There's also pop-up-frames and pop-up-windows, but I think we > can wait a few releases before marking those as obsolete. FWIW and for the record, I disagree with _all_ of that proposal. Please do not do this. There should be _no_ hurry to do anything of the sort. Why can't you wait a few releases - or more - for all of the above? In fact, I would like to see these variables continued anyway, as (to me, at least), a much simpler, alternative way to customize buffer display. If the variables have fancy equivalents in the new machinery, fine. Let users choose: fancy or simple, super-general or (presumably) more limited. I do not claim _any_ expertise in this area - far from it. And that's one reason I ask that the simple approach be kept (as well as the more complex). You might be able to do more and better with the new system - or as you say "machinery" (usine a gaz?), but it does not seem (to me) to be so straightforward (simple) to use. It is still not clear to me how to - easily - replace the above user options, and I use them heavily. The doc regarding the new machinery, if not the machinery itself (can't speak to that), is impenetrable, for me. I'm sorry to say that, and I tried to raise the doc problem early, but I still do not see a clear explanation. Perhaps that is just a reflection of how complicated the machinery is - I can't judge, for lack of understanding. Just one, dumb user - who happens to actually _use_ the simple variables you are in a hurry to toss overboard. (Out of curiosity, I wonder how much those who came up with the new machinery ever actually used those variables. I don't argue that the machinery is bad or is implemented badly - on the contrary, I am convinced that Martin and others did a great job. But I wonder about its use value and ease of use, at least for some users.)