Subject: bug#75910: 31; Deprecate minibuffer-completing-file-name

From: Daniel Mendler <[email-masked]>
Date: Wed, 29 Jan 2025 15:17:30 +0100

Michael Albinus <[email-masked]> writes:

> Daniel Mendler <[email-masked]> writes:
>
> Hi Daniel,
>
>>> I don't understand what's the glaring argument for removing that
>>> variable. IIRC, it was requested already a while ago, and this was
>>> rejected. What's the change now for doing so?
>>
>> Can you please point to the relevant discussion? The last time I have
>> talked with Stefan Monnier about this variable, the plan was still to
>> deprecate this variable in the longer term, with the goal of use the
>> completion category as a unifying mechanism.
>
> But the question remains: What is the benefit removing (deprecating)
> this variable?

The completion category mechanism is a generalization of various old
`minibuffer-completing-*' variables. Completion tables like the file
completion table already provide the category, so
`minibuffer-completing-file-name' is a redundancy. Minibuffer-related
variables are often let-bound around a completion call, which is not
correct in a strict sense, since the variable should only hold inside
the minibuffer and not for nested completion sessions. The completion
metadata including the category does not have this problem. Furthermore
completion tables can specify categories per completion field. This
means that the category can change during completion, for example when
completing $environment variables as part of a path. In this sense, the
category is more precise. The completion category is used at various
places in the completion machinery and enables the user to customize
behavior per completion category. See for example the customization
variable `completion-category-overrides'. These features and advantages
are not offered by the old `minibuffer-completing-*' variables, and
these are the reasons for the addition of the category mechanism as I
understand. The deprecation of `minibuffer-completing-file-name' is just
one step in the transition to the category mechanism. As I have
mentioned the variable `minibuffer-completing-symbol' had been
deprecated and has even been removed already.

> Furthermore, I don't know the mechanism of completion categories. Is it
> guaranteed, that it also works when we're not inside read-file-name? The
> advantage of minibuffer-completing-file-name is, that it alwas returns
> nil or non-nil, even if there's no active file name completion. Tramp
> would require a similar indication, being called inside any completion,
> or not. Your proposed replacement, minibuffer-category-p, seems to check
> the contents of the minibuffer, which is not relevant for Tramp in general.

If `minibuffer-completing-file-name' becomes deprecated, a working
alternative should be provided, which works properly for all current
uses of `minibuffer-completing-file-name', even outside the minibuffer.
My `minibuffer-category-p' suggestion was a draft only. It might be
beneficial to offer a more reusable function `minibuffer-category' which
returns the category, or even a function `minibuffer-metadata-get'.
Outside of the minibuffer the functions would return nil. Instead of
checking `minibuffer-completing-file-name', one could check (eq 'file
(minibuffer-category)).

(defun minibuffer-category ()
  (and minibuffer-completion-table
       (completion-metadata-get
        (completion-metadata
         (buffer-substring-no-properties
          (minibuffer-prompt-end) (point))
         minibuffer-completion-table
         minibuffer-completion-predicate)
        'category)))

(defun minibuffer-metadata-get (prop)
  (and minibuffer-completion-table
       (completion-metadata-get
        (completion-metadata
         (buffer-substring-no-properties
          (minibuffer-prompt-end) (point))
         minibuffer-completion-table
         minibuffer-completion-predicate)
        prop)))

Daniel