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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11454 in the body.
You can then email your comments to 11454 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.1.50; `list-buffers-refresh', `Buffer-menu-buffer+size-width'
Date: Fri, 11 May 2012 13:06:57 -0700

(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 <at> 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'
 

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
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 14:32:23 +0800

"Drew Adams" <drew.adams <at> 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)?

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.

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
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 22:29:16 +0800

"Drew Adams" <drew.adams <at> 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.

Message #19 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 07:49:30 -0700

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

Previous Next

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