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

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

[Lennart Borgman]

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

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

[Lennart Borgman]

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

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

[Chong Yidong]

Lennart Borgman <lennart.borgman@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.

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

[Lennart Borgman]

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

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

[Chong Yidong]

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.

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

[Lennart Borgman]

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

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

[Lennart Borgman]

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

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

[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

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

[Chong Yidong]

no-spam@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).

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

[Lennart Borgman]

On Thu, Apr 29, 2010 at 5:42 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> no-spam@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.)

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

[Stefan Monnier]

> 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

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

[Lennart Borgman]

On Fri, Apr 30, 2010 at 12:51 AM, Stefan Monnier
<monnier@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.

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

[Kim F. Storm]

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

> On Fri, Apr 30, 2010 at 12:51 AM, Stefan Monnier
> <monnier@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