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

["Drew Adams" <drew.adams@oracle.com>]

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