* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
@ 2012-11-04 7:28 Jambunathan K
2012-11-04 13:58 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Jambunathan K @ 2012-11-04 7:28 UTC (permalink / raw)
To: 12797
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@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-04 7:28 bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido Jambunathan K
@ 2012-11-04 13:58 ` Stefan Monnier
2012-11-04 14:48 ` Jambunathan K
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2012-11-04 13:58 UTC (permalink / raw)
To: Jambunathan K; +Cc: 12797
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-04 13:58 ` Stefan Monnier
@ 2012-11-04 14:48 ` Jambunathan K
2012-11-05 3:19 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Jambunathan K @ 2012-11-04 14:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12797
Stefan Monnier <monnier@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-04 14:48 ` Jambunathan K
@ 2012-11-05 3:19 ` Stefan Monnier
2012-11-05 20:22 ` Jambunathan K
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2012-11-05 3:19 UTC (permalink / raw)
To: Jambunathan K; +Cc: 12797
>>> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-05 3:19 ` Stefan Monnier
@ 2012-11-05 20:22 ` Jambunathan K
2012-11-05 23:50 ` Stefan Monnier
0 siblings, 1 reply; 15+ messages in thread
From: Jambunathan K @ 2012-11-05 20:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12797
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.
--
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-05 20:22 ` Jambunathan K
@ 2012-11-05 23:50 ` Stefan Monnier
2012-11-06 1:33 ` Leo
2012-11-06 4:46 ` Jambunathan K
0 siblings, 2 replies; 15+ messages in thread
From: Stefan Monnier @ 2012-11-05 23:50 UTC (permalink / raw)
To: Jambunathan K; +Cc: 12797
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-05 23:50 ` Stefan Monnier
@ 2012-11-06 1:33 ` Leo
2012-11-06 5:20 ` Jambunathan K
2012-11-06 4:46 ` Jambunathan K
1 sibling, 1 reply; 15+ messages in thread
From: Leo @ 2012-11-06 1:33 UTC (permalink / raw)
To: 12797
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-05 23:50 ` Stefan Monnier
2012-11-06 1:33 ` Leo
@ 2012-11-06 4:46 ` Jambunathan K
1 sibling, 0 replies; 15+ messages in thread
From: Jambunathan K @ 2012-11-06 4:46 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12797
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-06 1:33 ` Leo
@ 2012-11-06 5:20 ` Jambunathan K
2013-07-09 4:06 ` Leo Liu
0 siblings, 1 reply; 15+ messages in thread
From: Jambunathan K @ 2012-11-06 5:20 UTC (permalink / raw)
To: 12797
Leo <sdl.web@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
>
>
>
>
>
--
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2012-11-06 5:20 ` Jambunathan K
@ 2013-07-09 4:06 ` Leo Liu
2013-07-09 4:51 ` Jambunathan K
0 siblings, 1 reply; 15+ messages in thread
From: Leo Liu @ 2013-07-09 4:06 UTC (permalink / raw)
To: Jambunathan K; +Cc: 12797-done
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2013-07-09 4:06 ` Leo Liu
@ 2013-07-09 4:51 ` Jambunathan K
2013-07-09 5:39 ` Leo Liu
0 siblings, 1 reply; 15+ messages in thread
From: Jambunathan K @ 2013-07-09 4:51 UTC (permalink / raw)
To: 12797
Leo Liu <sdl.web@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 ...
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2013-07-09 4:51 ` Jambunathan K
@ 2013-07-09 5:39 ` Leo Liu
2013-07-09 6:37 ` Jambunathan K
2013-07-09 6:38 ` Jambunathan K
0 siblings, 2 replies; 15+ messages in thread
From: Leo Liu @ 2013-07-09 5:39 UTC (permalink / raw)
To: Jambunathan K; +Cc: 12797
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2013-07-09 5:39 ` Leo Liu
@ 2013-07-09 6:37 ` Jambunathan K
2013-07-09 6:38 ` Jambunathan K
1 sibling, 0 replies; 15+ messages in thread
From: Jambunathan K @ 2013-07-09 6:37 UTC (permalink / raw)
To: Leo Liu; +Cc: 12797
Leo Liu <sdl.web@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2013-07-09 5:39 ` Leo Liu
2013-07-09 6:37 ` Jambunathan K
@ 2013-07-09 6:38 ` Jambunathan K
2013-07-09 15:36 ` Leo Liu
1 sibling, 1 reply; 15+ messages in thread
From: Jambunathan K @ 2013-07-09 6:38 UTC (permalink / raw)
To: Leo Liu; +Cc: 12797
Leo Liu <sdl.web@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido
2013-07-09 6:38 ` Jambunathan K
@ 2013-07-09 15:36 ` Leo Liu
0 siblings, 0 replies; 15+ messages in thread
From: Leo Liu @ 2013-07-09 15:36 UTC (permalink / raw)
To: Jambunathan K; +Cc: 12797
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)
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-07-09 15:36 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-04 7:28 bug#12797: 24.3.50; mml-atttach-file (C-c C-a) and ido Jambunathan K
2012-11-04 13:58 ` Stefan Monnier
2012-11-04 14:48 ` Jambunathan K
2012-11-05 3:19 ` Stefan Monnier
2012-11-05 20:22 ` Jambunathan K
2012-11-05 23:50 ` Stefan Monnier
2012-11-06 1:33 ` Leo
2012-11-06 5:20 ` Jambunathan K
2013-07-09 4:06 ` Leo Liu
2013-07-09 4:51 ` Jambunathan K
2013-07-09 5:39 ` Leo Liu
2013-07-09 6:37 ` Jambunathan K
2013-07-09 6:38 ` Jambunathan K
2013-07-09 15:36 ` Leo Liu
2012-11-06 4:46 ` Jambunathan K
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).