From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#43218: EWW handles default answer incorrectly when changing a select Date: Sun, 6 Sep 2020 10:06:01 -0700 (PDT) Message-ID: References: <86ft7wuoq0.fsf@hypra-xx> <878sdn22sf.fsf@gnus.org> <87imcrunvr.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34121"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43218@debbugs.gnu.org, Nicolas Graner To: Lars Ingebrigtsen , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 06 19:07:13 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 1kEy8H-0008mD-0f for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Sep 2020 19:07:13 +0200 Original-Received: from localhost ([::1]:37308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kEy8G-0000fT-11 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Sep 2020 13:07:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49168) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEy87-0000YW-Al for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2020 13:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35469) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kEy87-00044r-1x for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2020 13:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kEy86-000180-TV for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2020 13:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Sep 2020 17:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43218 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 43218-submit@debbugs.gnu.org id=B43218.15994119774263 (code B ref 43218); Sun, 06 Sep 2020 17:07:02 +0000 Original-Received: (at 43218) by debbugs.gnu.org; 6 Sep 2020 17:06:17 +0000 Original-Received: from localhost ([127.0.0.1]:47012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kEy7M-00016g-SJ for submit@debbugs.gnu.org; Sun, 06 Sep 2020 13:06:17 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:55634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kEy7K-00016S-VD for 43218@debbugs.gnu.org; Sun, 06 Sep 2020 13:06:16 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 086H4RMP115254; Sun, 6 Sep 2020 17:06:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=i7xJNsoiMim6VW94dxzUKHLvh5mmfqNxLNSoroGd70c=; b=zqDVZLskqTtJ1nD7tt6AOxN0T4+cKwnnirhb97wpXdxxd6hQBROOYYrOpNZgy6xZhg1+ HaDJ58yfhq3OdSt6H8Xx/O5B2LJ236ojNIoXmhwtCeHimAaX1QmJDsK1dnakv1STaorn pE76MpucI7G2c0PhQAquiARaLmmxPt1oE3fxBsnUffjg5ZFhKXM/J8AqapYWMAFoZiLY v2kz1nnZLZrYAmJIzshywzb9JRi9BHFD4LCEyohFaHUBhkhnMo2ouLMyO/uNei4KQ8fN KWLqLWdgqYSgNMuId4gsFTIb8Q7Ps26YkmevyCbGfQMIXCYJ1jy4kfIiHnztMIpUqG+0 SQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 33c3amkd10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 06 Sep 2020 17:06:09 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 086H650m160166; Sun, 6 Sep 2020 17:06:08 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 33cmktm1d0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 06 Sep 2020 17:06:08 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 086H639k000335; Sun, 6 Sep 2020 17:06:03 GMT In-Reply-To: <87imcrunvr.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5044.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9736 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009060174 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9736 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 mlxscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009060174 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:187362 Archived-At: > > Not sure how the prompting gets involved in this problem: if you decide > > to let the user choose only based on the text (i.e. "one" vs "one"), > > then there's not much the prompting can do to help: the minibuffer lets > > the users enter a string and that's that. > > If they type "one" which one of the two should you pick? >=20 > Yeah, that makes no sense. I was kinda sorta thinking about how ido > presents choices, but that's pretty much irrelevant in this case. No, it does make sense. Or rather, it can make sense. Obviously, if all a user has to go on is the display name of candidates, then she can't tell one from the other. But if other information, in addition to the display name, is communicated in some way, either by default or on demand, then it can make perfect sense. The point is that the `completing-read' behavior, which shows only the car of an alist entry (plus possibly an annotation), is quite limited. Examples of showing additional info: * In Icicles search, there may be multiple search hits with the same text, at different locations. (1) The order in *Completions* can tell you where they are, relatively. (2) You can hit a key to go to any search hit, to see exactly where it is, without that location being your final destination choice. * In Bookmark+, you can have "autofile" bookmarks, whose names are the nondir destination file names. That's convenient. But in the bookmark display list, or when jumping to a bookmark (completion) you can see what the destination file is. There are other examples, with different behaviors and use cases. The point is that the car of an alist entry (which is a string) does not, in general, carry all of the information about the alist entry. And that string is all that `completing-read' shows (plus possibly an annotation), and it is all that can be completed against or otherwise used to act on. There are ways for users to get the convenience of seeing only those display strings, but at the same time being able to identify/distinguish candidates that have the same display string but have other associated information (part of the full candidate). It is false to think that both the user and completion need necessarily be blind to such full information, i.e., such differences. After all, `completing-read' knows the full candidate. In vanilla Emacs it just simply ignores it for its job of completing. That info is essentially thrown away. (Note that this is another case where an alist is richer than a hash table or an obarray, which exclude duplicate keys.) ___ A related question is whether `completing-read' should remove duplicate candidates (where the notion of "same" compares the display strings). Obviously, if duplicates are removed then you never see more than one `foo' candidate, and you can't take advantage of the kinds of things I've mentioned. The answer to that "whether" question is that it depends on the reason for completion and the particular completion behavior required by the command that calls `completing-read'. In Icicles, variable `icicle-transform-function' is a function that transforms the set of completion candidates before they're displayed. By default, no transformation is done, but you can toggle this anytime during completion with `C-$'. When active, the default transformation is to remove duplicates. So by default, `C-$' toggles removal of duplicate candidates.