From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11454: 24.1.50; `list-buffers-refresh', `Buffer-menu-buffer+size-width' Date: Sat, 12 May 2012 06:43:33 -0700 Message-ID: <877B41D90D8D4BB5998F2C69190EF9C3@us.oracle.com> References: <87vck19afc.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 1336830298 31192 80.91.229.3 (12 May 2012 13:44:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 May 2012 13:44:58 +0000 (UTC) Cc: 11454@debbugs.gnu.org To: "'Chong Yidong'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 12 15:44:57 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1STCcy-0004fo-LI for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 May 2012 15:44:56 +0200 Original-Received: from localhost ([::1]:41899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STCcy-0002nb-3a for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 May 2012 09:44:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STCcv-0002nW-Dd for bug-gnu-emacs@gnu.org; Sat, 12 May 2012 09:44:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1STCct-000056-Ll for bug-gnu-emacs@gnu.org; Sat, 12 May 2012 09:44:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STCct-000051-IN for bug-gnu-emacs@gnu.org; Sat, 12 May 2012 09:44:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1STCd3-0008SB-Nd for bug-gnu-emacs@gnu.org; Sat, 12 May 2012 09:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 May 2012 13:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11454 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11454-submit@debbugs.gnu.org id=B11454.133683026132433 (code B ref 11454); Sat, 12 May 2012 13:45:01 +0000 Original-Received: (at 11454) by debbugs.gnu.org; 12 May 2012 13:44:21 +0000 Original-Received: from localhost ([127.0.0.1]:49991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1STCcO-0008R4-KT for submit@debbugs.gnu.org; Sat, 12 May 2012 09:44:20 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:34186) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1STCc4-0008QB-3F for 11454@debbugs.gnu.org; Sat, 12 May 2012 09:44:19 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4CDhgEE031170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 May 2012 13:43:43 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4CDhgtS011251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 May 2012 13:43:42 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 q4CDhfls032108; Sat, 12 May 2012 08:43:41 -0500 Original-Received: from dradamslap1 (/10.159.219.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 May 2012 06:43:41 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87vck19afc.fsf@gnu.org> Thread-Index: Ac0wCQPJWvqkRnpWSfWQCFBBINmFWAAN6usg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:59956 Archived-At: > What would you suggest: ignoring Buffer-menu-buffer+size-width if both > Buffer-menu-name-width and Buffer-menu-size-width are specified > (i.e. ignoring it by default)? Yes, if by "specified" you mean customized by the user. No, if you mean only defined in the new code. The latter would just be overriding the user's customizations. Here's what I would suggest: Respect a user's customizations and, in priority, customizations of the new options over customization of the old option. For that you would need to detect whether a user has customized either of the new options. (And if s?he customized only one of them, pick up the other new option value from Buffer-menu-buffer+size-width if customized (minus the customized new one), or the new default value if not.) Or else, in the transition period of deprecation (before desupport), use nil as the default value of all three options and then DTRT based on any existing (hence customized) values. Maybe something like this (just a possibility): (setq name-width Buffer-menu-name-width size-width Buffer-menu-size-width) (when Buffer-menu-buffer+size-width (cond ((and name-width (not size-width)) (setq size-width (- Buffer-menu-buffer+size-width name-width))) ((and size-width (not name-width)) (setq name-width (- Buffer-menu-buffer+size-width size-width))))) (unless name-width (setq name-width 19)) (unless size-width (setq size-width 7)) But perhaps there is a precedent for how such a change (e.g., splitting a string-valued option in two) should be handled? Dunno. Not a big deal, in any case. It just seems wrong to ignore user customizations that can perhaps be respected.