Path: csiph.com!goblin3!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: Expand first before asking the question "Display all xxx possibilities?"
Date: Fri, 7 Aug 2020 11:19:24 -0400
Organization: ITS, Case Western Reserve University
Lines: 32
Approved: bug-bash@gnu.org
Message-ID: <mailman.1141.1596813578.2739.bug-bash@gnu.org>
References: <871rkoslni.5.fsf@jidanni.org> <f507d245-af9c-3c41-9c19-acff9735e703@case.edu> <rgf0sa$c3f$1@ciao.gmane.io> <fa0e51f8-6ee3-c80e-d6d0-9be9561667e5@iki.fi> <81399d97-eba6-17ca-fd2b-7fbb420c8314@case.edu> <b932b572-2c2e-7edd-09c6-70f0089890be@iki.fi> <a0047c9f-5d9f-fa87-1bfc-bb62e2f0da11@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: chet.ramey@case.edu
To: Ilkka Virta <itvirta@iki.fi>, Chris Elvidge <celvidge001@gmail.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQwQ2hldCBSYW1l eSAoQ2FzZSBzdGFuZGFyZCkgPGNoZXQucmFtZXlAY2FzZS5lZHU+iF8EExECAB8FAkPi19EC GwMHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJELtYafBk6nSrelkAn31Gsuib7GcCZHbv5L5t VKYR9LklAJ4hzUHKA49Z0QXR+qCb80osIcmPSbkBDQRBDrBvEAQAkK6TAOKBEM+EC4j6V/7o /riVZqcgU5cid2qG9TXdwNtD9a3kvA/ObZBO93sX59wc6Bnwo4VJxsOmMlpGrAjJsxNwg3QH akEtf8LXRbVpj5xStdmBdQZUhIQyalo/2/TZq5OijtddUQcL5cs70hTv/FpT3wUvr2Xr8rjF 41IFEz8AAwcD/A0CZEGlzIrT5WCBnl6xBog/8vKiUCbarByat3d1mL6DbizvKNXQRTC9E/vE dENAWCQCjr75Bu55xT8n3SXGtWdDC5xmZ/P3OBYORP8yl8H8I1FIosWOFirbIeYdZPq8SPD1 HL+EXo9zSiHVrrZRJ19ooCKKbSdXHFCY+aJG+0KZiEkEGBECAAkFAkEOsG8CGwwACgkQu1hp 8GTqdKvjcACfZlkVCDwaz/NTO9cy3t69oWpVPNwAnRwe0qk/WL/gfhH346xh5B3HFbFN
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
In-Reply-To: <b932b572-2c2e-7edd-09c6-70f0089890be@iki.fi>
Content-Language: en-US
Received-SPF: pass client-ip=129.22.103.227; envelope-from=chet.ramey@case.edu; helo=mpv1-2015.case.edu
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID: <a0047c9f-5d9f-fa87-1bfc-bb62e2f0da11@case.edu>
X-Mailman-Original-References: <871rkoslni.5.fsf@jidanni.org> <f507d245-af9c-3c41-9c19-acff9735e703@case.edu> <rgf0sa$c3f$1@ciao.gmane.io> <fa0e51f8-6ee3-c80e-d6d0-9be9561667e5@iki.fi> <81399d97-eba6-17ca-fd2b-7fbb420c8314@case.edu> <b932b572-2c2e-7edd-09c6-70f0089890be@iki.fi>
Xref: csiph.com gnu.bash.bug:16733

On 8/6/20 10:11 AM, Ilkka Virta wrote:
> On 6.8. 15:59, Chet Ramey wrote:
>> On 8/6/20 8:13 AM, Ilkka Virta wrote:
>>> I think they meant the case where all the files matching the given
>>> beginning have a longer prefix in common. The shell expands that prefix to
>>> the command line after asking to show all possibilities.
>>
>> Only if you set the "show-all-if-ambiguous" readline variable explicitly
>> asking for this behavior. Readline's default behavior is to complete up to
>> the longest common prefix, then, on the next completion attempt, to note
>> that there weren't any additional changes to the buffer and ask if the user
>> wants to see the alternatives. Dan wants a change in the behavior that
>> variable enables.
> 
> Right, sorry.
> 
> I do have it set because otherwise there's a step where tab-completion only
> produces a beep, and doesn't do anything useful. I didn't realize causes
> partial completion to be skipped too.

It's not `skipped'. The partial match gets inserted before you go back to
line editing, when you can actually do something with it. There's no real
good HCI reason to insert it first only to have it scroll off the screen
as readline displays the possible matches, then insert it again before
going on. And say you decline to see the possible matches -- the partial
match gets inserted before you go back to editing anyway.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/