From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ryan Thompson Newsgroups: gmane.emacs.bugs Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files Date: Tue, 06 Jun 2017 00:06:44 +0000 Message-ID: References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@yandex.ru> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> <0edc70e8-2b43-887d-1c5d-022eb430dd44@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1147c9eabfec0505513f65ed" X-Trace: blaine.gmane.org 1496707698 7820 195.159.176.226 (6 Jun 2017 00:08:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Jun 2017 00:08:18 +0000 (UTC) To: Dmitry Gutov , Drew Adams , 27158@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 06 02:08:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI22f-0001ix-N7 for geb-bug-gnu-emacs@m.gmane.org; Tue, 06 Jun 2017 02:08:13 +0200 Original-Received: from localhost ([::1]:35630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dI22k-000746-Qq for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Jun 2017 20:08:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dI22Y-00073o-VO for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 20:08:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dI22U-0008UG-U4 for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 20:08:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55606) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dI22U-0008UC-OU for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 20:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dI22U-0004uG-Fr for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2017 20:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ryan Thompson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jun 2017 00:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27158 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27158-submit@debbugs.gnu.org id=B27158.149670762318791 (code B ref 27158); Tue, 06 Jun 2017 00:08:02 +0000 Original-Received: (at 27158) by debbugs.gnu.org; 6 Jun 2017 00:07:03 +0000 Original-Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI21X-0004t0-2U for submit@debbugs.gnu.org; Mon, 05 Jun 2017 20:07:03 -0400 Original-Received: from mail-it0-f41.google.com ([209.85.214.41]:38132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dI21V-0004sW-2q for 27158@debbugs.gnu.org; Mon, 05 Jun 2017 20:07:01 -0400 Original-Received: by mail-it0-f41.google.com with SMTP id r63so94450134itc.1 for <27158@debbugs.gnu.org>; Mon, 05 Jun 2017 17:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thompsonclan-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=y4KewuLLCow8FURGRuBzIV6OTzRocyIWAyXE0IZMeDU=; b=e/eHS0d5k8dbb9PlvGFARew2LF6L8Gq0s3+Z1vMEmVlXLSvz2uTN/6nK6d5XPYpBq9 dlPaueYm+KwWquXCZnO7MRQV/rcPbH1uszMqxW7cKo2075rFfwFxJW/wA80CD5r9TKTw bjdIvPK9qWD/StQyhxSNS1V2VPu/iK0S5HaHmepBtUFjul8aveFKhCEtRbtvicxXtmj8 XL4RXckOGhIvhCiU86IQjLvcwhAKtobXSpNw7pR8k8XSukTjvkfahtceXwavN0gxfTfu S6cLnmsjWPk1dvccQFswRfIPiMNjvExKPPpGgsyoYHGCCPydRwIB4NpNAr9fd830jWpD eLBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=y4KewuLLCow8FURGRuBzIV6OTzRocyIWAyXE0IZMeDU=; b=OZEtcG2seeGVfN4LbDZIcbWEYN8xXZCJNxaVj16LTQYNt9zRIqfRxEHwLGIv22FRYU ff7ylTqV8mjCKfK+qnCvwjbIxylCL6nhYIhvgsm7DRra0HARxKfurhDiV7rU1YQ7W1Fj muQ7Zb7u06QSS27LkmPtplkiEC+PgSByLZpP/4DeoLgrGQylJhFXAk5WhPEvX2VMYZgZ 0w9SFvuMq+TS0k4njVseVTpgQGf8ERgrY9E5u7epcNMf7cSH7pcm+u+dyz1ifikOkxYr sWPu6NwZ/mE3Mgpg1QnX/pFJTBmR1hPKWaGZ5jeqfO+M6Fmkc+Oz7pBENuGVnDP5QFcw V84A== X-Gm-Message-State: AODbwcBsQ71OuyeABpA5xV/yW7DEmRKjy0SzRFDmShEp4EOP02/QcvKL HbqLOIjIm1q07Y/f3xl93MLLCY+u6ZAy X-Received: by 10.36.39.139 with SMTP id g133mr14753738ita.65.1496707615414; Mon, 05 Jun 2017 17:06:55 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133332 Archived-At: --001a1147c9eabfec0505513f65ed Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 7:01 PM Dmitry Gutov wrote: > Does it work well in the "don't want any default" case? > It does the same thing as completing-read-default, which is that it allows you to enter an empty string by pressing RET and assumes that the calling function is expecting that to happen. In particular, this means that any code that wrongly assumed that setting REQUIRE-MATCH would guarantee returning an element of COLLECTION is now equally broken in both standard completion and ido completion, as opposed to being spuriously "fixed" by ido ignoring the spec of completing-read. 'prepend-empty-string' sounds like what I'd expect; > 'append-empty-string' doesn't sounds particularly useful (what's the > goal here?); 'Any other value' kind of looks like over-engineering. > I wasn't sure if any of those made sense other than prepend-empty-string and nil, but they were 2 lines of code each, and I can remove them later (I haven't made a release for this yet). The idea behind append-empty-string was that you might to make it possible to return the empty string even though REQUIRE-MATCH is non-nil, but you don't want it to be the default. The function thing was just "I dunno, maybe someone needs someone else." I'll probably remove them if I don't find a use for them. They're not used at the moment. Anyway, I'm finding it to work pretty well without requiring a distinction between commands that do or do not expect the empty string. I merged that branch into my bleeding-edge branch and fixed a bunch of bugs, and I'm going to test it for a while before releasing. --001a1147c9eabfec0505513f65ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Jun 5, 2017 at 7:01 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
= Does it work well in the "don't want any default" case?
=C2=A0
It does the same thing as completing-read-= default, which is that it allows you to enter an empty string by pressing R= ET and assumes that the calling function is expecting that to happen. In pa= rticular, this means that any code that wrongly assumed that setting REQUIR= E-MATCH would guarantee returning an element of COLLECTION is now equally b= roken in both standard completion and ido completion, as opposed to being s= puriously "fixed" by ido ignoring the spec of completing-read.

'prepend-empty-string&= #39; sounds like what I'd expect;
'append-empty-string' doesn't sounds particularly useful (what&= #39;s the
goal here?); 'Any other value' kind of looks like over-engineering.=

I wasn't sure if any of those made= sense other than prepend-empty-string and nil, but they were 2 lines of co= de each, and I can remove them later (I haven't made a release for this= yet). The idea behind append-empty-string was that you might to make it po= ssible to return the empty string even though REQUIRE-MATCH is non-nil, but= you don't want it to be the default. The function thing was just "= ;I dunno, maybe someone needs someone else." I'll probably remove = them if I don't find a use for them. They're not used at the moment= .

Anyway, I'm finding it to work pretty well w= ithout requiring a distinction between commands that do or do not expect th= e empty string. I merged that branch into my bleeding-edge branch and fixed= a bunch of bugs, and I'm going to test it for a while before releasing= .
--001a1147c9eabfec0505513f65ed--