From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#34070: 27.0.50; icomplete-mode candidate cycling broken for C-x C-f Date: Thu, 17 Jan 2019 07:46:08 -0800 (PST) Message-ID: <154c946e-28c9-4afa-865a-ac15d2e83bce@default> References: <83h8ebdy61.fsf@gnu.org> <83d0ozdwfz.fsf@gnu.org> <83a7k3dto5.fsf@gnu.org> <4dd122fb-61b5-4605-9290-bde726598907@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1547739957 15040 195.159.176.226 (17 Jan 2019 15:45:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Jan 2019 15:45:57 +0000 (UTC) Cc: monnier@iro.umontreal.ca To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 34070@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 17 16:45:53 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk9ra-0003kh-TO for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Jan 2019 16:45:51 +0100 Original-Received: from localhost ([127.0.0.1]:46905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk9th-0004jj-N5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Jan 2019 10:48:01 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk9sm-0004Av-24 for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 10:47:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gk9sl-0007uw-61 for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 10:47:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35941) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gk9sl-0007uV-1p for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 10:47:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gk9sk-0006Fu-IP for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 10:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jan 2019 15:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34070 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 34070-submit@debbugs.gnu.org id=B34070.154773999024002 (code B ref 34070); Thu, 17 Jan 2019 15:47:02 +0000 Original-Received: (at 34070) by debbugs.gnu.org; 17 Jan 2019 15:46:30 +0000 Original-Received: from localhost ([127.0.0.1]:35222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk9sD-0006F3-KT for submit@debbugs.gnu.org; Thu, 17 Jan 2019 10:46:30 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:52000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk9s1-0006EM-3V for 34070@debbugs.gnu.org; Thu, 17 Jan 2019 10:46:27 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0HFhYXl021223; Thu, 17 Jan 2019 15:46:11 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-2018-07-02; bh=jUQEysy/MiHi2XqtILNpkraKSIpwahvPe+X40/KWH0o=; b=17HHejOF6Lp86OaiLeyStTkqEZNsRepOHnNO6t8/KLYss51LhfVjehk0y3FNTu+tEY2S tHxZ5mTTt4/xo3OhlgsEyXnVEddRhjVvzN8gXXntA9nw9VOKJOAyXktAEc9f9TLTXUKB sm7r6KqLIwkfgRc2A2+rovPo7xASQfxo0BIEguq+4wqfl3WiGXgU0OPut8bMLu6G1Vy7 WBTlkmLbNteFm7SGPxLmzyw3Sw3tiX0jN1CxMIlAExpEDtW9QOZ+P1qz6eyAFNH9lFqh 2653kS19uxWnMOjsIAzWmVEB35faO+7VbLOUQXBpW3cRmN8Ql8qzT0zMzif7De5GDb/f Jw== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2pybjsgqh6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Jan 2019 15:46:10 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0HFkANG025458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Jan 2019 15:46:10 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0HFk9OT030126; Thu, 17 Jan 2019 15:46:09 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4783.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9138 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=934 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901170113 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: 209.51.188.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:154519 Archived-At: > while still honouring the original intention of Drew's change: > 65797b1d7 "Make icomplete respect `completion-ignored-extensions'" > the new patch does two things: > 1. Still fixes the candidate cycling (i.e. this bug) > 2. Leaves the current directory as a candidate, i.e. "./" is *not* > filtered from the prospects list (but "../" is). >=20 > Number 2 can be seen as "new" behaviour, but then Drew's patch also > silently introduced new behaviour by filtering out "./" and "../", > which are *not* in completion-ignored-extensions. Reading bug > #12939... this seems to have gone unnoticed. >=20 > If someone thinks this is a problem we can make this configurable > (though I think the default should be what I suggest, since it > makes C-x C-f'ing directories much easier). I can't speak to whether `.' or `..' should (always? sometimes?) be filtered out for Icomplete completion of file-name candidates. I think you're right that the intention of my patch was just to respect `completion-ignored-extensions'. That was the "new" behavior to be introduced, and not silently. But why is it that `completion-pcm--filename-try-filter' adds `.' and `..' to its filter, so they too are excluded? I guess it's because they are not candidates returned by `try'? Assuming there's a good reason why `c-p--f-t-f' does that, and if that's not appropriate for Icomplete in all or most cases, then I guess `c-p--f-t-f' wasn't a perfect match for Icomplete. ;-) But maybe someone should take a look at `c-p--f-t-f' more generally? If `.' or `..' is appropriate for file-name completions sometimes (e.g. in Icomplete), then do some of the current uses of `c-p--f-t-f' also manifest the same bug that you are adding here? E.g., is removal of `.' and `..' always appropriate for `completion-basic-try-completion', `completion-pcm-try-completion' and `completion-substring-try-completion'? (Note too that you are adding to this bug, which was purportedly about broken cycling. Is this additional change necessary to fix the cycling problem, or should it be the subject of a new bug report?) BTW, see also bug #13322, companion to bug #12939. It should never have been closed, IMHO. BTW2, as stated in bug #12939, `completion-pcm--filename-try-filter' is the wrong name. It should not use `--'. It's not "internal" in any way, or at least it should not be considered so. Internal to what? It's not internal to `completion-pcm' (whatever that might be/mean now) or to `minibuffer.el'. It's as general and useful as any other Lisp function - no reason to try to signal to users that it is (also) used to build some basic Emacs behavior. Users can well make use of such a function. Misuse of the label "internal" is akin to Trump trying to "build that wall".