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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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