From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wanrong Lin Newsgroups: gmane.emacs.bugs Subject: bug#39484: 26.3; try-completion bug Date: Wed, 28 Oct 2020 11:47:34 -0400 Message-ID: <962e72d1-451f-7725-a22c-e35b4a5784b1@gmail.com> References: <874kmf1peq.fsf@gnus.org> <87361zbi5x.fsf@igel.home> <87h7qfzdf8.fsf@gnus.org> <87y2jr9zwt.fsf@igel.home> <8fed8748-8331-5ca7-6c91-108c27945bb2@gmail.com> <87tuuf9xgp.fsf@igel.home> <87ft5y3i17.fsf@igel.home> <87tuuevgl2.fsf@gnus.org> <87zh461yas.fsf@igel.home> <87lffqvfvk.fsf@gnus.org> <87v9eu1xon.fsf@igel.home> <87tuuetxbb.fsf@gnus.org> <87lffq1snn.fsf@igel.home> <44009e48-c8b7-72c1-b505-4308d84c24e7@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37461"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 Cc: Lars Ingebrigtsen , Andreas Schwab , 39484@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 28 16:54:21 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXnmF-0009d7-Qs for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 16:54:19 +0100 Original-Received: from localhost ([::1]:41158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXnmE-0006pP-On for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 11:54:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXngA-00015R-U7 for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 11:48:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38663) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXngA-0002A2-KR for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 11:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXngA-0003Gs-I2 for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 11:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Wanrong Lin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Oct 2020 15:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39484 X-GNU-PR-Package: emacs Original-Received: via spool by 39484-submit@debbugs.gnu.org id=B39484.160390007312557 (code B ref 39484); Wed, 28 Oct 2020 15:48:02 +0000 Original-Received: (at 39484) by debbugs.gnu.org; 28 Oct 2020 15:47:53 +0000 Original-Received: from localhost ([127.0.0.1]:50209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXng1-0003GT-8U for submit@debbugs.gnu.org; Wed, 28 Oct 2020 11:47:53 -0400 Original-Received: from mail-pf1-f171.google.com ([209.85.210.171]:36981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXnfy-0003GG-N3 for 39484@debbugs.gnu.org; Wed, 28 Oct 2020 11:47:51 -0400 Original-Received: by mail-pf1-f171.google.com with SMTP id 126so3161808pfu.4 for <39484@debbugs.gnu.org>; Wed, 28 Oct 2020 08:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=zvzZl0c9n3iLuTHkTkhMI9iK4YRfUBchk70w9vxh85Q=; b=NHzoDAiMV6SuRX9roE5DNcV194RbBKThsv7qIW2rDegPv7S+ycBbGOijsf2eTW6Wvw xhtPXHZCBwBdAn1CdQNCaoRx4+vsnHgD3PMmQNJXA0awb0yX8iIcqwo0u5T384/KcvZE MeOjpVkiGrtrFTD6G7LyOTW7vFPg7l/7AeDbapGFQ/usvMtSdspp28b7ATtvpW1sxE2D rX4OpJ2S/0kCVLtTyZK/PwcaPPX39JUDzS0i3Ib61hxB1qddad5XaHJNFexV2wte7LE4 MrzlWKUnGEtF8Zhe+ciGJ9WwJAhxddgaqTzvmwVBxUoJ2e/yWZFXkb5me2LRn/2+WIHd HZNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=zvzZl0c9n3iLuTHkTkhMI9iK4YRfUBchk70w9vxh85Q=; b=W0DnxQBlaDEzzpQomjM16mvaifT8zlbmBdvnTU/yrG7s+zifBsx2JOti8hZ2DGDQyv WjiCAqDPEHQskqnSlWPtfNdT+6p/ed5aXNWtQz6SPWok1yT8zQ5uBhPg7hek6tnLLHo6 aS3oDQ8a1pxPgcKQ6b/FnR/8lBl+45yzr3In+7hMT+hvB7mr6k9j8AY81NfSWk2uVe/0 76Y2tGB27hmZk1qgwQPVCIPZl84Gd6Lv36KdzOR846vv79yUKwyNYXN2VQb407H+daYn APZuFnVWdNkeZpZS1UVk/q+XKpSFNd1pC8EtlK5sZbeGhIalCn7tNLQTCjJRRRDZf9S2 vVaw== X-Gm-Message-State: AOAM530O6SVZL2YCpJ/SRgLn49bEHT4X9yB4FHsMuVblyCni1T5hp2YD KSWrLeYdu4zcEXgnlykcc+jgmPv9m5NZEg== X-Google-Smtp-Source: ABdhPJztz+eNz+y2uYo9kEdzEcFknXXQujEWm4k1PtUYsfuN95EyCeRZTSIvwHMkYF7mJFxZF8JhIQ== X-Received: by 2002:a63:4c55:: with SMTP id m21mr7228851pgl.305.1603900064463; Wed, 28 Oct 2020 08:47:44 -0700 (PDT) Original-Received: from [192.168.2.19] (c-71-226-226-185.hsd1.nj.comcast.net. [71.226.226.185]) by smtp.googlemail.com with ESMTPSA id t15sm57055pjq.3.2020.10.28.08.47.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 08:47:43 -0700 (PDT) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191891 Archived-At: The examples I gave are real life situations. I discovered this issue from an unexpected behavior with ido. The "bug" has real negative consequences, at least for me. As for this: "It does it by refraining from mix-and-match: either the whole result comes from the user input or the whole result comes from *one* of the candidates." It still sounds quite arbitrary to me, as I failed to understand why it is bad if the whole result comes from *all* of the candidates if that happens to be possible. I will try to give a version which I think is better (up to debate, of course) For the user input x, return a string y (or nil if impossible) so that it satisfies all three conditions below: 1. x is a prefix of y, ignoring case. 2. y is the maximum common prefix, ignoring case, among all candidates 3. y is the *exact* (including case) prefix of at least one of the candidates Wanrong On 10/28/2020 10:45 AM, Stefan Monnier wrote: >> 1. Return value is not ideal. You can argue it is still not wrong, but >> I think we can improve. > Indeed, it can be improved, but we should not try to be too clever about > it, because some choices might seem obvious in some circumstances but > would result in rather poor answers in other cases. > > So rather than hypothetical cases like what we've seen here, I'm much > more interested in real life situations. > > The current design is trying to be conservative, in the sense that it > tries to avoid returning a poor result, at the cost of sometimes failing > to return a better result. It does it by refraining from mix-and-match: > either the whole result comes from the user input or the whole result > comes from *one* of the candidates. > > There are cases where `completion-try-completion` (as opposed to > `try-completion`) doesn't actually follow this rule correctly, and it's > been a source of suboptimal results. > > > Stefan >