Re: bug#5765: Strange things happens with C-v in read-file-name

[no-spam@cua.dk (Kim F. Storm)]

Lennart Borgman <lennart.borgman@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@gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 9:44 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>>> Lennart Borgman <lennart.borgman@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