From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] /srv/bzr/emacs/trunk r108646: * minibuffer.el(read-file-name-default): Bind `non-essential' to `t'. Date: Mon, 18 Jun 2012 07:58:20 -0700 Message-ID: References: <87k3z5ouz1.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1340031545 20690 80.91.229.3 (18 Jun 2012 14:59:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2012 14:59:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Michael Albinus'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 18 16:59:04 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SgdPw-0001cP-6n for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2012 16:59:00 +0200 Original-Received: from localhost ([::1]:53274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgdPw-0002YY-3s for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2012 10:59:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgdPk-0002Vn-9r for emacs-devel@gnu.org; Mon, 18 Jun 2012 10:58:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgdPe-0001Vy-U1 for emacs-devel@gnu.org; Mon, 18 Jun 2012 10:58:47 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:48432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgdPe-0001Ur-NU for emacs-devel@gnu.org; Mon, 18 Jun 2012 10:58:42 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5IEwaWj023288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jun 2012 14:58:37 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5IEwaX5023593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 14:58:36 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5IEwZTM027862; Mon, 18 Jun 2012 09:58:35 -0500 Original-Received: from dradamslap1 (/10.159.170.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Jun 2012 07:58:35 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac1NWx7v50suHO0VTx2Z0Piw6Dj5xQABZZSg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150986 Archived-At: > > Here's a recipe to reproduce the problem (revert the patch in > > minibuffer.el first): > > emacs -Q -l icomplete -f icomplete-mode > > C-x C-f /ssh:localhost:/ > > I don't see any problem here. Tramp requests a password, as expected > and as it should (since the user hit TAB, she clearly wants > completion). If I can chime in about the use case, though not about the implementation/fix - I think that for most users most of the time, the completions shown by Icomplete act mainly as background help. They are not "essential", and most users (or at least some users) would not want to be interrupted when entering a file name just to provide some password because their minibuffer input so far was recognized by Tramp/ange-ftp as possibly corresponding to a remote file. A user who does want Tramp to prompt for a password need only hit TAB to cause that. IOW, I think there is a difference in how much a user is actively requesting completion between hitting TAB and just letting Icomplete precomplete the current input. This is only about Icomplete preventing _its_ preparation of completion suggestions from prompting the user to access a remote file system. And if we think that some users do want Tramp to kick in during Icomplete, then we can provide a user option (e.g. in icomplete.el) to control the behavior. In sum, I think that most of the time an Icomplete user does not want Icomplete to be so eager/assertive/aggressive. (It is a bit like Eldoc.) Again, I am not speaking about the implementation or about things other than Icomplete. If I had to guess about Ido, for instance, it would be that users of Ido might typically want Tramp to interrupt for a password. But users should in general be able to ignore Icomplete's suggestions - it should be possible to treat Icomplete as background noise. It would be OK for that to be controlled by a user option.