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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12797 in the body.
You can then email your comments to 12797 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Sun, 04 Nov 2012 12:58:54 +0530

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).  The problem is slightly exacerbated on
my end because of my patch to icomplete.el which shifts the field
separator from "," to " | ".  

I frequently type backspace at the prompt only to be disappointed that
the prompt doesn't back out to parent directory but only deletes a char.

1. I can defalias it

    (defalias 'read-file-name 'ido-read-file-name)

2. One can mark it separately thus (as ido already does for some
   functions)

    (put 'read-file-name 'ido 'ido-read-file-name)

I am not sure which of the options is best.  (2) might be better of the
two options but it needs extra handling elswhere.

Can someone install the needful, so that I don't keep tripping over
differences in the implementation.

In GNU Emacs 24.3.50.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2012-11-03 on debian-6.05
Bzr revision: 110779 dmantipov <at> yandex.ru-20121103055917-30uwiia169kunlk2
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
  value of $LANG: en_IN
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

Message #8 received at 12797 <at> debbugs.gnu.org (full text, mbox):

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

> 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?

> 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.


        Stefan

Message #11 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: 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

Message #14 received at 12797 <at> debbugs.gnu.org (full text, mbox):

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

>>> 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).

To clarify: I have not stated any opinion on what you suggest, for the
simple reason that I do not know/understand what it is.
Are you reporting a bug in ido, a bug in icomplete, requesting new
features in icomplete?

>>> 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.

No, I just don't understand what they're about.
E.g. why/when do you need them?  Why are they a problem?  Would you want
them to be included in Emacs?  If not, are you saying that it should
be easier to do it in one's .emacs?

> 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.

AFAIK, the default completion is fairly consistent.
The iswitchb completion is inconsistent by nature: it's specific to
buffer completion.
So, this is requesting a change in ido?


        Stefan

Message #17 received at 12797 <at> debbugs.gnu.org (full text, mbox):

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

I have tried my level best to make myself understood.  I cannot do any
better than what I have noted in earlier mails.

In summary, 

there are differences between how ido reads file name at C-x C-f prompt
and how `read-file-name' reads file name while doing C-c C-a.  The
differences are subtle and it is annoying.

The suggestion was to map `read-file-name' calls to `ido-read-file-name'
within ido.el so that a typical user (that is me!) is not annoyed.
-- 

Message #20 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Mon, 05 Nov 2012 18:50:03 -0500

> there are differences between how ido reads file name at C-x C-f prompt
> and how `read-file-name' reads file name while doing C-c C-a.  The
> differences are subtle and it is annoying.

By "how `read-file-name' reads file name while doing C-c C-a" you mean
when ido-mode is enabled and read-file-name-function is set to something
like ido-read-file-name?
So, this would be a bug (or missing feature maybe) in IDO, right?

> The suggestion was to map `read-file-name' calls to `ido-read-file-name'
> within ido.el so that a typical user (that is me!) is not annoyed.

Hmm... so maybe I misunderstood and you meant C-c C-a is used in
ido-mode but without redirecting read-file-name to ido-read-file-name?


        Stefan

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 06 Nov 2012 09:33:32 +0800

On 2012-11-06 07:50 +0800, Stefan Monnier wrote:
> By "how `read-file-name' reads file name while doing C-c C-a" you mean
> when ido-mode is enabled and read-file-name-function is set to something
> like ido-read-file-name?
> So, this would be a bug (or missing feature maybe) in IDO, right?

Only if one specifically asks for ido-everywhere which changes
read-file-name-function.

Leo

Message #26 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 06 Nov 2012 10:16:21 +0530

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> there are differences between how ido reads file name at C-x C-f prompt
>> and how `read-file-name' reads file name while doing C-c C-a.  The
>> differences are subtle and it is annoying.
>
> By "how `read-file-name' reads file name while doing C-c C-a" you mean
> when ido-mode is enabled and read-file-name-function is set to something
> like ido-read-file-name?

I see a `read-file-name-function' (which I hadn't noticed before).

> So, this would be a bug (or missing feature maybe) in IDO, right?

Not a bug.  Definitely a desirable.  Yes.

>> The suggestion was to map `read-file-name' calls to `ido-read-file-name'
>> within ido.el so that a typical user (that is me!) is not annoyed.
>
> Hmm... so maybe I misunderstood and you meant C-c C-a is used in
> ido-mode but without redirecting read-file-name to ido-read-file-name?

Correct.

Message #29 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 06 Nov 2012 10:50:18 +0530

Leo <sdl.web <at> gmail.com> writes:

> On 2012-11-06 07:50 +0800, Stefan Monnier wrote:
>> By "how `read-file-name' reads file name while doing C-c C-a" you mean
>> when ido-mode is enabled and read-file-name-function is set to something
>> like ido-read-file-name?
>> So, this would be a bug (or missing feature maybe) in IDO, right?
>
> Only if one specifically asks for ido-everywhere which changes
> read-file-name-function.

Thanks for the suggestion.  I now have this in my customizations.

  (custom-set-variables
   '(ido-everywhere t)
   '(ido-mode (quote both) nil (ido)))

Retrospectively, I see that choice of `everywhere' is unfortunate.  It
is ambiguous.  So a `both' in `ido-mode' is not the same as
`everywhere'.  The "somewhere" - which is reading file names, as opposed
to visiting it etc - is what everywhere accounts for but both leaves
out.

A user is very unlikely to note subtle differences.

I have hard time understanding what (ido-everywhere) does. 

My recommedation is to have `ido-everywhere' set to t by default or be
set automatically (via a custom set function) whenever `ido-mode' is
changed.

ps: I still don't understand everywhere means.  So I will leave the
proposed change to others.

> Leo
>
>
>
>
>

-- 

Message #34 received at 12797-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 12797-done <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 09 Jul 2013 12:06:29 +0800

On 2012-11-06 13:20 +0800, Jambunathan K wrote:
> Thanks for the suggestion.  I now have this in my customizations.
>
>   (custom-set-variables
>    '(ido-everywhere t)
>    '(ido-mode (quote both) nil (ido)))
>
> Retrospectively, I see that choice of `everywhere' is unfortunate.  It
> is ambiguous.  So a `both' in `ido-mode' is not the same as
> `everywhere'.  The "somewhere" - which is reading file names, as opposed
> to visiting it etc - is what everywhere accounts for but both leaves
> out.
>
> A user is very unlikely to note subtle differences.
>
> I have hard time understanding what (ido-everywhere) does. 
>
> My recommedation is to have `ido-everywhere' set to t by default or be
> set automatically (via a custom set function) whenever `ido-mode' is
> changed.
>
> ps: I still don't understand everywhere means.  So I will leave the
> proposed change to others.

There are some cleanups to do in ido. But let's leave them for later.

Leo

Message #37 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 09 Jul 2013 10:21:28 +0530

Leo Liu <sdl.web <at> gmail.com> writes:

> There are some cleanups to do in ido. But let's leave them for later.

You could have also left "closing the bug" for later!  Anyways ...

Message #40 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 09 Jul 2013 13:39:15 +0800

On 2013-07-09 12:51 +0800, Jambunathan K wrote:
> You could have also left "closing the bug" for later!  Anyways ...

Unless the cleanup bug is closely related, it might be better put it in
a different bug report. Or it will sit here for years to come.

Leo

Message #43 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 09 Jul 2013 12:07:11 +0530

Leo Liu <sdl.web <at> gmail.com> writes:

> On 2013-07-09 12:51 +0800, Jambunathan K wrote:
>> You could have also left "closing the bug" for later!  Anyways ...
>
> Unless the cleanup bug is closely related, it might be better put it in
> a different bug report. Or it will sit here for years to come.

The cleanup report says only one thing - Make ido-everywhere the
default.  There are references to cleanups but that is not the crux of
the report.

Are you duty-bound to close or fix the bug?  I don't understand where
the friction is ...

> Leo

Message #46 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 09 Jul 2013 12:08:04 +0530

Leo Liu <sdl.web <at> gmail.com> writes:

> On 2013-07-09 12:51 +0800, Jambunathan K wrote:
>> You could have also left "closing the bug" for later!  Anyways ...
>
> Unless the cleanup bug is closely related, it might be better put it in
> a different bug report. Or it will sit here for years to come.

The bug report says only one thing - Make ido-everywhere the default.
The bug is result of a concrete use case and not something abstract.

There are references to cleanups but that is not the crux of the report.
Are you duty-bound to close or fix the bug?  I don't understand where
the friction is ...

> Leo

Message #49 received at 12797 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 12797 <at> debbugs.gnu.org
Subject: Re: bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
Date: Tue, 09 Jul 2013 23:36:38 +0800

On 2013-07-09 14:38 +0800, Jambunathan K wrote:
> Make ido-everywhere the default.

Maybe you can discuss with others (emacs-devel or emacs-help) if default
to ido-everywhere is a good idea. I cannot reach this conclusion from
glancing over the bug thread.

If you feel strongly that this bug should be re-opened, re-open it. I
have no objection.

Leo (time is up)

Previous Next

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