GNU bug report logs - #11454
24.1.50; `list-buffers-refresh', `Buffer-menu-buffer+size-width'

Previous Next

Full log

Message #11 received at 11454 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 11454 <at> debbugs.gnu.org
Subject: RE: bug#11454: 24.1.50;
	`list-buffers-refresh', `Buffer-menu-buffer+size-width'
Date: Sat, 12 May 2012 06:43:33 -0700

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.