bug#26242: 25.1; `dired-shrink-to-fit' warning

bug#26242: 25.1; `dired-shrink-to-fit' warning

[Drew Adams]

If code uses variable `dired-shrink-to-fit', this is the byte-compiler
warning you get:

Warning: ‘dired-shrink-to-fit’ is an obsolete variable (as of 24.3); use the Customization interface to add a new rule
to ‘display-buffer-alist’ where condition regexp is "^ \*Marked Files\*$",
action argument symbol is ‘window-height’ and its value is nil.

That is a _ridiculous_ warning.

This simple variable was defined this way, for decades:

(defvar dired-shrink-to-fit t
;; I see no reason ever to make this nil -- rms.
;;  (> baud-rate search-slow-speed)
  "Non-nil means Dired shrinks the display buffer to fit the marked files.")

IOW, the value should pretty much always be non-nil.

What on Earth is the point of the convoluted recipe given in that
warning?

`dired-shrink-to-fit' was never a user option.  It is not necessarily
something that someone would set in their init file.  It is just as
likely (if it is likely at all - see RMS's comment) that it would be
bound in some Lisp code.

Why should we tell users to customize `display-buffer-alist', perhaps
the most complex user option, and in such a way as to do the complicated
things the warning suggests?

What we should do is just restore the definition of
`dired-shrink-to-fit' (perhaps even making it a constant with value
`t'), or just replace occurrences of it with `t' and declare it obsolete
but without such a silly warning that tells you to customize
`display-buffer-alist'.


In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-11-15 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install 'CFLAGS=-O2
 -static -g3''

bug#26242: 25.1; `dired-shrink-to-fit' warning

[Lars Ingebrigtsen]

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

> If code uses variable `dired-shrink-to-fit', this is the byte-compiler
> warning you get:
>
> Warning: ‘dired-shrink-to-fit’ is an obsolete variable (as of 24.3); use the Customization interface to add a new rule
> to ‘display-buffer-alist’ where condition regexp is "^ \*Marked Files\*$",
> action argument symbol is ‘window-height’ and its value is nil.

[...]

> What on Earth is the point of the convoluted recipe given in that
> warning?

Because the variable is going away and if somebody had a customisation
for that, it's nice to let them know how to change it.  But it seems
unlikely that anybody would change that variable, as both you and the
comments point out.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#26242: 25.1; `dired-shrink-to-fit' warning

[Drew Adams]

> > What on Earth is the point of the convoluted recipe given in that
> > warning?
> 
> Because the variable is going away and if somebody had a customisation
> for that, it's nice to let them know how to change it.  But it seems
> unlikely that anybody would change that variable, as both you and the
> comments point out.

No. That doesn't answer the question or respond to
the bug report.  That just says what the status quo
is that the report reports should be fixed.

This is what should be done, as already pointed out:

  What we should do is just restore the definition
  of `dired-shrink-to-fit' (perhaps even making it
  a constant with value `t'), or just replace
  occurrences of it with `t' and declare it obsolete
  but without such a silly warning that tells you to
  customize `display-buffer-alist'.

bug#26242: 25.1; `dired-shrink-to-fit' warning

[npostavs]

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

> This is what should be done, as already pointed out:
>
>   What we should do is just restore the definition
>   of `dired-shrink-to-fit'

The definition of dired-shrink-to-fit was never changed, so what do you
mean by "restore"?

bug#26242: 25.1; `dired-shrink-to-fit' warning

[Drew Adams]

> > This is what should be done, as already pointed out:
> >
> >   What we should do is just restore the definition
> >   of `dired-shrink-to-fit'
> 
> The definition of dired-shrink-to-fit was never changed, so what do you
> mean by "restore"?

Don't remove the variable.

From Lars:

> Because the variable is going away...

Don't issue that byte-compiler warning, but
instead do one or more of the things I suggested.

Don't close the bug, saying there is nothing to
change about the "fix" of adding the byte-comp
warning.

bug#26242: 25.1; `dired-shrink-to-fit' warning

[npostavs]

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

> Don't issue that byte-compiler warning, but
> instead do one or more of the things I suggested.

> What we should do is just restore the definition of
> `dired-shrink-to-fit' (perhaps even making it a constant with value
> `t'), or just replace occurrences of it with `t' and declare it obsolete
> but without such a silly warning that tells you to customize
> `display-buffer-alist'.

So something like this (I don't see the benefit of replacing occurrences
with `t' before actually removing it completely)?

--- i/lisp/dired.el
+++ w/lisp/dired.el
@@ -299,9 +299,7 @@ dired-shrink-to-fit
 ;;  (> baud-rate search-slow-speed)
   "Non-nil means Dired shrinks the display buffer to fit the marked files.")
 (make-obsolete-variable 'dired-shrink-to-fit
-			"use the Customization interface to add a new rule
-to `display-buffer-alist' where condition regexp is \"^ \\*Marked Files\\*$\",
-action argument symbol is `window-height' and its value is nil." "24.3")
+			"stop using it." "24.3")
 
 (defvar dired-file-version-alist)
 

bug#26242: 25.1; `dired-shrink-to-fit' warning

[Drew Adams]

> > Don't issue that byte-compiler warning, but
> > instead do one or more of the things I suggested.
> 
> > What we should do is just restore the definition of
> > `dired-shrink-to-fit' (perhaps even making it a constant with value
> > `t'), or just replace occurrences of it with `t' and declare it obsolete
> > but without such a silly warning that tells you to customize
> > `display-buffer-alist'.
> 
> So something like this (I don't see the benefit of replacing occurrences
> with `t' before actually removing it completely)?
>
> +			"stop using it." "24.3")

Better, yes.