GNU bug report logs - #12797
24.3.50; mml-atttach-file (C-c C-a) and ido

Previous Next

Full log

View this message in rfc822 format

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 12797 <at> debbugs.gnu.org
Subject: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Sun, 04 Nov 2012 20:18:13 +0530

Stefan Monnier <monnier <at> IRO.UMontreal.CA> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.