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

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

[Drew Adams]

(let ((name-width Buffer-menu-name-width)
 (size-width Buffer-menu-size-width))
    ;; Handle obsolete variable:
    (if Buffer-menu-buffer+size-width
 (setq name-width (- Buffer-menu-buffer+size-width size-width)))
 
The code calculates NAME-WIDTH based on a user's customized
`Buffer-menu-buffer+size-width', but it does not similarly calculate
SIZE-WIDTH.

It simply ignores the user's customization and uses the
default value of the new option `Buffer-menu-size-width'.
Not very user-friendly, eh?

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-05-06 on MARVIN
Bzr revision: 108144 cyd@gnu.org-20120507053738-5ovifsb71cmamn2f
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> (let ((name-width Buffer-menu-name-width)
>  (size-width Buffer-menu-size-width))
>     ;; Handle obsolete variable:
>     (if Buffer-menu-buffer+size-width
>  (setq name-width (- Buffer-menu-buffer+size-width size-width)))
>  
> The code calculates NAME-WIDTH based on a user's customized
> `Buffer-menu-buffer+size-width', but it does not similarly calculate
> SIZE-WIDTH.
>
> It simply ignores the user's customization and uses the
> default value of the new option `Buffer-menu-size-width'.
> Not very user-friendly, eh?

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)?

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

[Drew Adams]

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

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

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

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

Absolutely not; that way lies madness.  As far as possible, outside of
Customize only the value of the variable should have any meaning.

I amended the docstring of `B-m-b+s-w' to explicitly describe the
current behavior.  That is as good as we are going to get.

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

[Drew Adams]

> > 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.
> 
> Absolutely not; that way lies madness.

Apparently you do not distinguish deprecation from desupport.

> As far as possible, outside of Customize only the value of the
> variable should have any meaning.

What does that mean?  Who said anything to the contrary?

The suggestion was only to respect user customizations.  And for `B-m-b+s-w', to
respect it only during the deprecation period, i.e., until it is desupported.

> I amended the docstring of `B-m-b+s-w' to explicitly describe the
> current behavior. 

Why bother?  You've effectively desupported it.