GNU bug report logs - #5765
Strange things happens with C-v in read-file-name

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 5765 in the body.
You can then email your comments to 5765 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: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: Re: Strange things happens with C-v in read-file-name
Date: Wed, 24 Mar 2010 13:37:44 +0100

I have still got no answer to this one so I am cc:ing emacs devel list.


On Tue, Feb 2, 2010 at 1:23 PM, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
> I got no answer so I am sending a bug report. This is a very
> irritating bug that hits me all the time.
>
>
> ---------- Forwarded message ----------
> From: Lennart Borgman <lennart.borgman <at> gmail.com>
> Date: Wed, Jan 27, 2010 at 11:16 PM
> Subject: Strange things happens with C-v in read-file-name
> To: Emacs-Devel devel <emacs-devel <at> gnu.org>
>
>
> I do not know if this is a bug in Emacs sources from 2010-01-26 or
> something I had introduced in some way. However C-v does not work for
> me in the read-file-name prompt (C-x C-f) any more. Checking the key
> binding I get this in a normal buffer
>
>  C-v is bound to `cua-paste' in `cua--cua-keys-keymap'
>
> but in the C-x C-f prompt I get:
>
>  C-v is bound to `cua-scroll-up' in `global-map'
>
> I have no idea what has happened. However first I noticed some
> problems with Viper (eh, yes, I use viper-mode and cua-mode
> together...). I have customized viper so that C-v is not bound there,
> but for some reason it showed up bound (to quote-insert) which it was
> not before.
>
> I looked a bit but could not find out what has happened so I did a
> quick workaround for the viper problem. Then instead this cua-mode
> problem emerged.
>
> I do not know how to reproduce this from "emacs -Q" at the moment. And
> I can't see what is wrong. All keymaps looks as I expect them to do
> (including emulation-mode-map-alist). It just looks like
> emulation-mode-map-alist is bypassed.
>
> I can reproduce it with
>
>   emacs --no-desktop
>   C-x b somename RET RET
>   C-x C-f C-v
>
> The problem is there in the 2010-01-21 checkout (unpatched) but not in
> 2009-12-04 (patched). Unfortunately I have nothing in between there.
>
>
> Anyone have any idea what is going on here? Writing this message it is
> more and more clear to me there is some rather serious bug here. I
> just have no idea how to track it down.
>

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5765 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Wed, 24 Mar 2010 13:09:49 -0400

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

>> C-v does not work for me in the read-file-name prompt (C-x C-f) any
>> more.
>>
>> I do not know how to reproduce this from "emacs -Q" at the moment. And
>> I can't see what is wrong. All keymaps looks as I expect them to do
>> (including emulation-mode-map-alist). It just looks like
>> emulation-mode-map-alist is bypassed.
>>
>> I can reproduce it with
>>
>>  emacs --no-desktop
>>  C-x b somename RET RET
>>  C-x C-f C-v
>>
>> The problem is there in the 2010-01-21 checkout (unpatched) but not in
>> 2009-12-04 (patched). Unfortunately I have nothing in between there.

Please bisect your customizations to find the minimally reproducible
test case.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5765 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Wed, 24 Mar 2010 19:28:35 +0100

On Wed, Mar 24, 2010 at 6:09 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>
>>> C-v does not work for me in the read-file-name prompt (C-x C-f) any
>>> more.
>>>
>>> I do not know how to reproduce this from "emacs -Q" at the moment. And
>>> I can't see what is wrong. All keymaps looks as I expect them to do
>>> (including emulation-mode-map-alist). It just looks like
>>> emulation-mode-map-alist is bypassed.
>>>
>>> I can reproduce it with
>>>
>>>  emacs --no-desktop
>>>  C-x b somename RET RET
>>>  C-x C-f C-v
>>>
>>> The problem is there in the 2010-01-21 checkout (unpatched) but not in
>>> 2009-12-04 (patched). Unfortunately I have nothing in between there.
>
> Please bisect your customizations to find the minimally reproducible
> test case.

I have not been able to do that. However I know that I get the same
problem with for example

  M-: (completing-read "my prompt: " '("a" "b"))

I can't find any involved variable that looks suspect. Could you maybe
come up with something to check?

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5765 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Wed, 24 Mar 2010 16:44:55 -0400

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

>> Please bisect your customizations to find the minimally reproducible
>> test case.
>
> I have not been able to do that. However I know that I get the same
> problem with for example
>
>   M-: (completing-read "my prompt: " '("a" "b"))
>
> I can't find any involved variable that looks suspect. Could you maybe
> come up with something to check?

If this is so simple to reproduce with customizations, I don't see why
it should be so difficult to bisect the customizations and find the
problem.  It's far easier than asking others to deduce the bug from
first principles.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5765 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Thu, 25 Mar 2010 02:17:49 +0100

On Wed, Mar 24, 2010 at 9:44 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>
>>> Please bisect your customizations to find the minimally reproducible
>>> test case.
>>
>> I have not been able to do that. However I know that I get the same
>> problem with for example
>>
>>   M-: (completing-read "my prompt: " '("a" "b"))
>>
>> I can't find any involved variable that looks suspect. Could you maybe
>> come up with something to check?
>
> If this is so simple to reproduce with customizations, I don't see why
> it should be so difficult to bisect the customizations and find the
> problem.  It's far easier than asking others to deduce the bug from
> first principles.


Of course I have tried that, but I could not find the problem. I
needed to do certain things after to make it happens.

Now I think I have found the problem. In ido-minibuffer-setup (in
ido.el) there is a line

    (setq cua-inhibit-cua-keys t)

I have had that commented out for long in my patched version of Emacs,
but forgot to tell about it. Some merging breaked this.

I see no reason why it should be there. Could it please be removed (or
commented out) if no one else sees a reason for it? (Then we have to
find another way to solve this bug.)

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>, "Kim F. Storm" <storm <at> cua.dk>
Cc: 5765 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Thu, 29 Apr 2010 03:23:35 +0200

Nothing happened to this so I am sending this again. Could this please
be fixed before the release?

Kim, could you perhaps comment on this? Could the line

   (setq cua-inhibit-cua-keys t)

be removed?


On Thu, Mar 25, 2010 at 3:17 AM, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
> On Wed, Mar 24, 2010 at 9:44 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
>> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>>
>>>> Please bisect your customizations to find the minimally reproducible
>>>> test case.
>>>
>>> I have not been able to do that. However I know that I get the same
>>> problem with for example
>>>
>>>   M-: (completing-read "my prompt: " '("a" "b"))
>>>
>>> I can't find any involved variable that looks suspect. Could you maybe
>>> come up with something to check?
>>
>> If this is so simple to reproduce with customizations, I don't see why
>> it should be so difficult to bisect the customizations and find the
>> problem.  It's far easier than asking others to deduce the bug from
>> first principles.
>
>
> Of course I have tried that, but I could not find the problem. I
> needed to do certain things after to make it happens.
>
> Now I think I have found the problem. In ido-minibuffer-setup (in
> ido.el) there is a line
>
>    (setq cua-inhibit-cua-keys t)
>
> I have had that commented out for long in my patched version of Emacs,
> but forgot to tell about it. Some merging breaked this.
>
> I see no reason why it should be there. Could it please be removed (or
> commented out) if no one else sees a reason for it? (Then we have to
> find another way to solve this bug.)
>

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

From: no-spam <at> cua.dk (Kim F. Storm)
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5765 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	emacs-devel <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	"Kim F. Storm" <storm <at> cua.dk>
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Thu, 29 Apr 2010 13:37:27 +0200

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> Nothing happened to this so I am sending this again. Could this please
> be fixed before the release?
>
> Kim, could you perhaps comment on this? Could the line
>
>    (setq cua-inhibit-cua-keys t)
>
> be removed?

IIRC, the reason for this was the following binding in ido file mode:

    (define-key map "\C-v" 'ido-toggle-vc)

If cua-mode is enabled, C-v is processed by cua (as paste), shadowing the
above command.

I guess nobody really uses that specific feature of ido.
I used to use it a lot back when I wrote ido, but never uses it these days.

So the best thing to do would be to remove the above binding - then you
can also remove the setting of cua-inhibit-cua-keys.

Or just remove the setting of cua-inhibit-cua-keys as you suggest; this
effectively makes the other binding a noop if cua-mode is enabled.

Kim




>
> On Thu, Mar 25, 2010 at 3:17 AM, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 9:44 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
>>> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>>>
>>>>> Please bisect your customizations to find the minimally reproducible
>>>>> test case.
>>>>
>>>> I have not been able to do that. However I know that I get the same
>>>> problem with for example
>>>>
>>>>   M-: (completing-read "my prompt: " '("a" "b"))
>>>>
>>>> I can't find any involved variable that looks suspect. Could you maybe
>>>> come up with something to check?
>>>
>>> If this is so simple to reproduce with customizations, I don't see why
>>> it should be so difficult to bisect the customizations and find the
>>> problem.  It's far easier than asking others to deduce the bug from
>>> first principles.
>>
>>
>> Of course I have tried that, but I could not find the problem. I
>> needed to do certain things after to make it happens.
>>
>> Now I think I have found the problem. In ido-minibuffer-setup (in
>> ido.el) there is a line
>>
>>    (setq cua-inhibit-cua-keys t)
>>
>> I have had that commented out for long in my patched version of Emacs,
>> but forgot to tell about it. Some merging breaked this.
>>
>> I see no reason why it should be there. Could it please be removed (or
>> commented out) if no one else sees a reason for it? (Then we have to
>> find another way to solve this bug.)
>>
>
>
>

-- 
Kim F. Storm  http://www.cua.dk

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: no-spam <at> cua.dk (Kim F. Storm)
Cc: 5765 <at> debbugs.gnu.org, emacs-devel <at> gnu.org,
	Lennart Borgman <lennart.borgman <at> gmail.com>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>, "Kim F. Storm" <storm <at> cua.dk>
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Thu, 29 Apr 2010 11:42:31 -0400

no-spam <at> cua.dk (Kim F. Storm) writes:

>> Nothing happened to this so I am sending this again. Could this please
>> be fixed before the release?
>>
>> Kim, could you perhaps comment on this? Could the line
>>
>>    (setq cua-inhibit-cua-keys t)
>>
>> be removed?
>
> IIRC, the reason for this was the following binding in ido file mode:
>
>     (define-key map "\C-v" 'ido-toggle-vc)
>
> If cua-mode is enabled, C-v is processed by cua (as paste), shadowing the
> above command.
>
> I guess nobody really uses that specific feature of ido.
> I used to use it a lot back when I wrote ido, but never uses it these days.
>
> So the best thing to do would be to remove the above binding - then you
> can also remove the setting of cua-inhibit-cua-keys.

Done.

(In the trunk, not in the branch; this is not serious enough to make an
exception to the regressions-only policy).

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5765 <at> debbugs.gnu.org, "Kim F. Storm" <storm <at> cua.dk>, emacs-devel <at> gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>, "Kim F. Storm" <no-spam <at> cua.dk>
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Thu, 29 Apr 2010 17:45:12 +0200

On Thu, Apr 29, 2010 at 5:42 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> no-spam <at> cua.dk (Kim F. Storm) writes:
>
>>> Nothing happened to this so I am sending this again. Could this please
>>> be fixed before the release?
>>>
>>> Kim, could you perhaps comment on this? Could the line
>>>
>>>    (setq cua-inhibit-cua-keys t)
>>>
>>> be removed?
>>
>> IIRC, the reason for this was the following binding in ido file mode:
>>
>>     (define-key map "\C-v" 'ido-toggle-vc)
>>
>> If cua-mode is enabled, C-v is processed by cua (as paste), shadowing the
>> above command.
>>
>> I guess nobody really uses that specific feature of ido.
>> I used to use it a lot back when I wrote ido, but never uses it these days.
>>
>> So the best thing to do would be to remove the above binding - then you
>> can also remove the setting of cua-inhibit-cua-keys.
>
> Done.
>
> (In the trunk, not in the branch; this is not serious enough to make an
> exception to the regressions-only policy).

Thanks.

But maybe it is serious enough for the release because CUA keys does
not work in the minibuffer at all without this change. (And I doubt it
can break anything.)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5765 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	"Kim F. Storm" <storm <at> cua.dk>, emacs-devel <at> gnu.org,
	"Kim F. Storm" <no-spam <at> cua.dk>
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Thu, 29 Apr 2010 18:51:55 -0400

> But maybe it is serious enough for the release because CUA keys does
> not work in the minibuffer at all without this change. (And I doubt it
> can break anything.)

It's been that way for a long time, so there's no hurry to fix it.


        Stefan

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5765 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	"Kim F. Storm" <storm <at> cua.dk>, emacs-devel <at> gnu.org,
	"Kim F. Storm" <no-spam <at> cua.dk>
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Fri, 30 Apr 2010 01:54:34 +0200

On Fri, Apr 30, 2010 at 12:51 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> But maybe it is serious enough for the release because CUA keys does
>> not work in the minibuffer at all without this change. (And I doubt it
>> can break anything.)
>
> It's been that way for a long time, so there's no hurry to fix it.


Normally I would agree with that reasoning, but not here. The reason
it has been this way for a long time is probably because cua-mode has
not got much attention. It has been kind of a second class citizen.
Perhaps no one really expected it to work. I think it would be good to
show that we care about this.

Doesn't this change only affect cua-mode users? I think those desire
this change.

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

From: no-spam <at> cua.dk (Kim F. Storm)
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5765 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	emacs-devel <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	"Kim F. Storm" <storm <at> cua.dk>
Subject: Re: bug#5765: Strange things happens with C-v in read-file-name
Date: Fri, 30 Apr 2010 11:58:17 +0200

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> On Fri, Apr 30, 2010 at 12:51 AM, Stefan Monnier
> <monnier <at> iro.umontreal.ca> wrote:
>>> But maybe it is serious enough for the release because CUA keys does
>>> not work in the minibuffer at all without this change. (And I doubt it
>>> can break anything.)
>>
>> It's been that way for a long time, so there's no hurry to fix it.
>
>
> Normally I would agree with that reasoning, but not here. The reason
> it has been this way for a long time is probably because cua-mode has
> not got much attention. It has been kind of a second class citizen.
> Perhaps no one really expected it to work. I think it would be good to
> show that we care about this.
>
> Doesn't this change only affect cua-mode users? I think those desire
> this change.

The basic question is: Is this a regression wrt 23.1 or not?

-- 
Kim F. Storm  http://www.cua.dk

Previous Next

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