bug#74361: [PATCH] New option xref-navigation-display-window-action

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dmitry@gutov.dev,  rudalics@gmx.at,  74361@debbugs.gnu.org
> Date: Fri, 22 Nov 2024 09:29:00 +0200
> 
> >> cmuscheme.el:
> >>   (define-derived-mode inferior-scheme-mode comint-mode "Inferior Scheme"
> >>    ...
> >>     (pop-to-buffer "*scheme*" display-comint-buffer-action)
> >> 
> >> inf-lisp.el:
> >>   (define-derived-mode inferior-lisp-mode comint-mode "Inferior Lisp"
> >>    ...
> >>     (pop-to-buffer "*inferior-lisp*" display-comint-buffer-action)
> >> 
> >> shell.el:
> >>   (define-derived-mode shell-mode comint-mode "Shell"
> >>    ...
> >>     (pop-to-buffer buffer display-comint-buffer-action)
> >
> > Those are not the categories, those are the deprecated user options
> > for which the categories are supposed to be a replacement we
> > recommend:
> >
> >   (make-obsolete-variable
> >    'display-comint-buffer-action
> >    "use a `(category . comint)' condition in `display-buffer-alist'."
> >    "30.1")
> 
> The categories are a replacement only for customization.
> But all display-buffer calls should still contain
> `(category . comint)' that currently presented
> in these variables.  IOW, the variables currently
> are used in two ways:
> 1. as the default values for display-buffer calls
> 2. as user options
> 
> But now customization is supposed to be only with
> the help of `(category . comint)' in `display-buffer-alist'.
> So these variable will be used only in display-buffer calls.
> 
> > So if some user wants to take our advice and modernize his/her
> > customizations to use '(category . comint)' instead of
> > display-comint-buffer-action, the customization will stop working for
> > him/her when we remove those obsolete options in some future Emacs
> > version.  Right?  Or what am I missing?
> 
> These are two possible solutions:
> 1. Demote these options to variables not intended for customization.
> 2. Move their current default values to display-buffer calls.

I expected to see us do #2 at the same time we deprecated the user
options.  I don't understand why we didn't do that.  The deprecation
message clearly tells users not to use these variables, so it's
reasonable to expect them to be deleted.  Moreover, their presence in
our sources is a potential cause for byte-compilation warnings.