bug#63744: 28.2; fix dired-guess-default

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Leo Liu <sdl.web@gmail.com>,  63744@debbugs.gnu.org
> Date: Mon, 29 May 2023 03:23:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > There is no alternative at the moment other than redefining
> > > dired-guess-default.
> >
> > But your suggestion is also a change in that function, so what's the
> > difference?
> 
> I think he means: the user should not have to do this.

If there's only one user who wants that, there's no difference...

> > >    (RE ("STR1" "STR2" ...))
> >
> > Can't you generate the entire value of dired-guess-shell-alist-user
> > dynamically, including the RE part?
> 
> It's a real difference, actually a real win.  Please don't only have
> constant lists in mind.

Does this answer my question above?  If so, I don't think I understand
the answer, please elaborate.  I asked why not generate the whole
value, including the REGEXP part, dynamically.

> "Dynamically" means that dired can inspect the matched file (the file
> name is provided via the variable 'file' bound when evaluating the
> expression).  This means the EXPR can look at the properties of the
> file, it's type and modes etc, which allows a more fine grained user
> customization.  With such a change one can have entries looking like
> 
>   (RE (if COND (GET-DEFAULTS-FOR-COND) (GET-OTHER-DEFAULTS)))
> 
> which would currently be have to be specified as several entries like
> 
>   (RE (when COND DEFAULT-FOR-COND-1))
>   (RE (when COND DEFAULT-FOR-COND-2))
>     ...
>   (RE (when COND DEFAULT-FOR-COND-n))
>   (RE (when (not COND) OTHER-DEFAULT-1))
>   ...
>   (RE (when (not COND) OTHER-DEFAULT-m))
> 
> and, much worse, testing the CONDITION would have to be performed many
> times.

Sorry, I don't see why it has to be so complicated.  RE can be
generated just once, and then consed into a list with whatever should
follow it, and those other elements could be generated dynamically.

Anyway, I don't see why we should keep arguing.  I already said that I
won't object to such an extension of the forms in
dired-guess-shell-alist-user, I just think we should document them,
and I'm quite sure such a change in the code is not for the released
branch.