From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.bugs Subject: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido Date: Sun, 04 Nov 2012 20:18:13 +0530 Message-ID: <874nl54e6q.fsf@gmail.com> References: <87d2ztrfm1.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1352040427 9792 80.91.229.3 (4 Nov 2012 14:47:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Nov 2012 14:47:07 +0000 (UTC) Cc: 12797@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 04 15:47:16 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TV1To-0004Ki-60 for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2012 15:47:16 +0100 Original-Received: from localhost ([::1]:58214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TV1Tf-0000Bw-Hc for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2012 09:47:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TV1Tc-0000Bh-Qg for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2012 09:47:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TV1Tb-0000is-Bb for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2012 09:47:04 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TV1Tb-0000io-4R for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2012 09:47:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TV1WU-0006Rb-IH for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2012 09:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jambunathan K Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Nov 2012 14:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12797 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12797-submit@debbugs.gnu.org id=B12797.135204056024718 (code B ref 12797); Sun, 04 Nov 2012 14:50:02 +0000 Original-Received: (at 12797) by debbugs.gnu.org; 4 Nov 2012 14:49:20 +0000 Original-Received: from localhost ([127.0.0.1]:48217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TV1Vn-0006Qc-HQ for submit@debbugs.gnu.org; Sun, 04 Nov 2012 09:49:19 -0500 Original-Received: from mail-pa0-f44.google.com ([209.85.220.44]:55951) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TV1Vl-0006QV-CW for 12797@debbugs.gnu.org; Sun, 04 Nov 2012 09:49:18 -0500 Original-Received: by mail-pa0-f44.google.com with SMTP id fb11so3373828pad.3 for <12797@debbugs.gnu.org>; Sun, 04 Nov 2012 06:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=AXJ7Ai6ztVZcTC1TA0jnZjxX32vWeXMBWaGwKOkZsos=; b=zXu8JUkEAbKp0QB6hiuwARo+xXmo72solxn0Oz1IdoI88RUOVZtx+O3ScTb5nWnUt1 1CZyItxGZjYUmODgqWeDMfVxY4m+rinRDa9ojItK7HWjaMvM9Z4+UtQJuXN8t2bM97ah IIuZp3Y8lPnVQ3UtQV2ifyyqsxLn4cuXHvqUmAlY6VCcWIGGcBX2brTj0DRnVy7IXuv1 CxHSRV5dz1XOC0+Vo13wEcfyNkHDLuC4VfqmPwnz7fQNHq5nW8dL6BPuLy9MZk/RDhO2 i/qsz2lnkg+ZOLmjjHGvRyAmOiIQfybLLmgg7T9vYWtIVJFM42/qlATURg4GRrTHQfBR dm/Q== Original-Received: by 10.68.192.5 with SMTP id hc5mr23053585pbc.16.1352040376192; Sun, 04 Nov 2012 06:46:16 -0800 (PST) Original-Received: from debian-6.05 ([115.242.229.28]) by mx.google.com with ESMTPS id vk5sm7671946pbc.34.2012.11.04.06.46.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Nov 2012 06:46:15 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sun, 04 Nov 2012 08:58:02 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:66434 Archived-At: Stefan Monnier writes: >> When I am attaching files to mails via C-c C-a, I am fooled in to >> thinking that the intereface for reading file is not that of ido but the >> default one (Emacs + icomplete). > > I do not know why you feel this way. Can you be more precise? Try it out. (May be you don't rely ido much? May be this is the reason my "experience" seems a bit "out of place" to you?) I gave example of BACKSPACE (which you have stripped). Here are two more data points: 1. With icomplete.el, ido provides very helpful feedback on what level of directory is filled. ido DOES NOT include the trailing "/" in completion but icomplete.el (or more precisely the completion candidates) includes the trailing "/". So when I am `minibuffer-force-complete'-ing I get confused on what directory it is filling. What I am saying is /tangentially related/ to this comment in minibuffer.el and my point is that the visual feedback is not good enough and that what ido does is more sensible. ,---- |;; If completing file names, (car all) may be a directory, so we'd now |;; have a new set of possible completions and might want to reset |;; completion-all-sorted-completions to nil, but we prefer not to, |;; so that repeated calls minibuffer-force-complete still cycle |;; through the previous possible completions. `---- 2. There is also another subtle behavioural difference. To understand look at when icomplete.el display is triggered. It is triggered only when there is something to chew on at the prompt. The disadvantage of "display-help-only-when-there-is-something-typed' is that I get no indications that caller has provided some defaults which I can fill in. In contrast, ido.el always provides instantaneous feedback. I have commented out relevant lines in `icomplete.el' to get instantaneous feedback. ,---- from `icomplete-exhibit' | (if (and ;; (> (point-max) (minibuffer-prompt-end)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ;; buffer-undo-list ; Wait for some user input. | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | (or | ;; Don't bother with delay after certain number of chars: | (> (- (point) (field-beginning)) icomplete-max-delay-chars) | ;; Don't delay if alternatives number is small enough: | (and (sequencep minibuffer-completion-table) | (< (length minibuffer-completion-table) | icomplete-delay-completions-threshold)) | ;; Delay - give some grace time for next keystroke, before | ;; embarking on computing completions: | (sit-for icomplete-compute-delay))) `---- >> Can someone install the needful, so that I don't keep tripping over >> differences in the implementation. > > Your bug report did not make it clear what are "the needful", > I'm afraid. I have indicated two needfuls - defalias (which needs to be undefaliased if ido is turned off) or the (put .. 'ido ..) stuff. Unfortunately, you have deemed it as insubstantial. ps: I am arguing for consistency of file-reading/completion experience. A user cannot be concerned with who provides the interface - ido, iswitchb or anything else. > Stefan