GNU bug report logs - #27158
25.2; Eliminating old usage of completing-read from built-in files

Previous Next

Full log

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

From: Ryan Thompson <rct <at> thompsonclan.org>
To: Drew Adams <drew.adams <at> oracle.com>, Dmitry Gutov <dgutov <at> yandex.ru>,
 27158 <at> debbugs.gnu.org
Subject: Re: bug#27158: 25.2; Eliminating old usage of completing-read from
 built-in files
Date: Wed, 31 May 2017 15:44:15 +0000

[Message part 1 (text/plain, inline)]

>
> But if an explicit DEFAULT arg is the solution then your
> completion system need only set arg DEFAULT to "" when
> it is nil, no?  Or set it to the first completion candidate
> when it is nil or "".  Or ... <whatever floats your boat>.
>

The problem is that there is no one solution that floats everyone's boat.
Whatever you choose, someone sinks (i.e. has broken completion). The only
way to float everyone's boat is for the completion function to check which
function called it and then change its behavior based on prior knowledge of
what each caller expects. Consider the following two functions:

(defun pick-a-fruit ()
  (interactive)
  (let* ((default "banana")
         (prompt (format "Pick a fruit (default %s): " default))
         (collection '("apple" "banana" "cherry"))
         (selection (completing-read prompt collection nil t)))
    (when (string= selection "")
      (setq selection default))
    (message "You selected %s" selection)))

(defun pick-a-tool ()
  (interactive)
  (let* ((prompt "Pick a tool: ")
         (collection '("hammer" "screwdriver" "drill"))
         (selection (completing-read prompt collection nil t)))
    (message "You selected %S" selection)))

The fruit function expects completing-read to return an empty string
to indicate that the default should be used, while the tool function
expects completing-read to always return an element from the
collection no matter what. Technically, the tool function is wrong,
because completing-read is documented to return an empty string even
when REQUIRE-MATCH is non-nil. But there are plenty of functions that
use this pattern and expect it to work, because they don't know about
this edge case, and it would be nice to be able to support them in a
custom completion system without breaking the functions that use the
former pattern. As it is, you have to choose one or the other to
break, or else imeplement caller-dependent behavior to give everyone
what they expect, which is messy.

As I said, though, treating DEF = nil as equivalent to DEF = "" might
form the basis for an acceptable compromise. It will still break the
pick-a-tool case, but it will be clearer why it's breaking, since the
empty string will be presented explicitly as the first completion
option. I'll test it out.

[Message part 2 (text/html, inline)]

Previous Next

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