* Strange things happens with C-v in read-file-name
@ 2010-01-27 22:16 Lennart Borgman
2010-02-02 12:23 ` bug#5511: " Lennart Borgman
0 siblings, 1 reply; 24+ messages in thread
From: Lennart Borgman @ 2010-01-27 22:16 UTC (permalink / raw)
To: Emacs-Devel devel
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5511: Strange things happens with C-v in read-file-name
2010-01-27 22:16 Strange things happens with C-v in read-file-name Lennart Borgman
@ 2010-02-02 12:23 ` Lennart Borgman
2010-03-24 12:37 ` Lennart Borgman
0 siblings, 1 reply; 24+ messages in thread
From: Lennart Borgman @ 2010-02-02 12:23 UTC (permalink / raw)
To: 5511
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Strange things happens with C-v in read-file-name
2010-02-02 12:23 ` bug#5511: " Lennart Borgman
@ 2010-03-24 12:37 ` Lennart Borgman
2010-03-24 17:09 ` bug#5765: " Chong Yidong
2010-03-24 17:09 ` Chong Yidong
0 siblings, 2 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-03-24 12:37 UTC (permalink / raw)
To: Emacs Bugs, Emacs-Devel devel
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.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 12:37 ` Lennart Borgman
@ 2010-03-24 17:09 ` Chong Yidong
2010-03-24 17:09 ` Chong Yidong
1 sibling, 0 replies; 24+ messages in thread
From: Chong Yidong @ 2010-03-24 17:09 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 5765, emacs-devel
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 12:37 ` Lennart Borgman
2010-03-24 17:09 ` bug#5765: " Chong Yidong
@ 2010-03-24 17:09 ` Chong Yidong
2010-03-24 18:28 ` Lennart Borgman
2010-03-24 18:28 ` Lennart Borgman
1 sibling, 2 replies; 24+ messages in thread
From: Chong Yidong @ 2010-03-24 17:09 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 5765, emacs-devel
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 17:09 ` Chong Yidong
@ 2010-03-24 18:28 ` Lennart Borgman
2010-03-24 20:44 ` Chong Yidong
2010-03-24 20:44 ` Chong Yidong
2010-03-24 18:28 ` Lennart Borgman
1 sibling, 2 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-03-24 18:28 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5765, emacs-devel
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?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 18:28 ` Lennart Borgman
@ 2010-03-24 20:44 ` Chong Yidong
2010-03-25 1:17 ` Lennart Borgman
2010-03-25 1:17 ` Lennart Borgman
2010-03-24 20:44 ` Chong Yidong
1 sibling, 2 replies; 24+ messages in thread
From: Chong Yidong @ 2010-03-24 20:44 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 5765, emacs-devel
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 20:44 ` Chong Yidong
@ 2010-03-25 1:17 ` Lennart Borgman
2010-04-29 1:23 ` Lennart Borgman
2010-04-29 1:23 ` Lennart Borgman
2010-03-25 1:17 ` Lennart Borgman
1 sibling, 2 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-03-25 1:17 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5765, emacs-devel
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.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-03-25 1:17 ` Lennart Borgman
@ 2010-04-29 1:23 ` Lennart Borgman
2010-04-29 1:23 ` Lennart Borgman
1 sibling, 0 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-04-29 1:23 UTC (permalink / raw)
To: Chong Yidong, Stefan Monnier, Kim F. Storm; +Cc: 5765, emacs-devel
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.)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-03-25 1:17 ` Lennart Borgman
2010-04-29 1:23 ` Lennart Borgman
@ 2010-04-29 1:23 ` Lennart Borgman
2010-04-29 11:37 ` Kim F. Storm
2010-04-29 11:37 ` Kim F. Storm
1 sibling, 2 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-04-29 1:23 UTC (permalink / raw)
To: Chong Yidong, Stefan Monnier, Kim F. Storm; +Cc: 5765, emacs-devel
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.)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 1:23 ` Lennart Borgman
@ 2010-04-29 11:37 ` Kim F. Storm
2010-04-29 11:37 ` Kim F. Storm
1 sibling, 0 replies; 24+ messages in thread
From: Kim F. Storm @ 2010-04-29 11:37 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 5765, Chong Yidong, Kim F. Storm, emacs-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 1:23 ` Lennart Borgman
2010-04-29 11:37 ` Kim F. Storm
@ 2010-04-29 11:37 ` Kim F. Storm
2010-04-29 15:42 ` Chong Yidong
2010-04-29 15:42 ` Chong Yidong
1 sibling, 2 replies; 24+ messages in thread
From: Kim F. Storm @ 2010-04-29 11:37 UTC (permalink / raw)
To: Lennart Borgman
Cc: 5765, Chong Yidong, emacs-devel, Stefan Monnier, 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 11:37 ` Kim F. Storm
@ 2010-04-29 15:42 ` Chong Yidong
2010-04-29 15:42 ` Chong Yidong
1 sibling, 0 replies; 24+ messages in thread
From: Chong Yidong @ 2010-04-29 15:42 UTC (permalink / raw)
To: Kim F. Storm; +Cc: 5765, Kim F. Storm, emacs-devel
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).
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 11:37 ` Kim F. Storm
2010-04-29 15:42 ` Chong Yidong
@ 2010-04-29 15:42 ` Chong Yidong
2010-04-29 15:45 ` Lennart Borgman
2010-04-29 15:45 ` Lennart Borgman
1 sibling, 2 replies; 24+ messages in thread
From: Chong Yidong @ 2010-04-29 15:42 UTC (permalink / raw)
To: Kim F. Storm
Cc: 5765, emacs-devel, Lennart Borgman, Stefan Monnier, Kim F. Storm
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).
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 15:42 ` Chong Yidong
@ 2010-04-29 15:45 ` Lennart Borgman
2010-04-29 22:51 ` Stefan Monnier
2010-04-29 22:51 ` Stefan Monnier
2010-04-29 15:45 ` Lennart Borgman
1 sibling, 2 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-04-29 15:45 UTC (permalink / raw)
To: Chong Yidong
Cc: 5765, Kim F. Storm, emacs-devel, Stefan Monnier, Kim F. Storm
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.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 15:45 ` Lennart Borgman
@ 2010-04-29 22:51 ` Stefan Monnier
2010-04-29 22:51 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Stefan Monnier @ 2010-04-29 22:51 UTC (permalink / raw)
To: Lennart Borgman
Cc: 5765, Chong Yidong, emacs-devel, Kim F. Storm, Kim F. Storm
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 15:45 ` Lennart Borgman
2010-04-29 22:51 ` Stefan Monnier
@ 2010-04-29 22:51 ` Stefan Monnier
2010-04-29 23:54 ` Lennart Borgman
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2010-04-29 22:51 UTC (permalink / raw)
To: Lennart Borgman
Cc: 5765, Chong Yidong, Kim F. Storm, emacs-devel, Kim F. Storm
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 22:51 ` Stefan Monnier
@ 2010-04-29 23:54 ` Lennart Borgman
2010-04-30 9:58 ` Kim F. Storm
2010-04-30 9:58 ` Kim F. Storm
0 siblings, 2 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-04-29 23:54 UTC (permalink / raw)
To: Stefan Monnier
Cc: 5765, Chong Yidong, emacs-devel, Kim F. Storm, Kim F. Storm
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 23:54 ` Lennart Borgman
@ 2010-04-30 9:58 ` Kim F. Storm
2010-04-30 9:58 ` Kim F. Storm
1 sibling, 0 replies; 24+ messages in thread
From: Kim F. Storm @ 2010-04-30 9:58 UTC (permalink / raw)
To: Lennart Borgman
Cc: 5765, Chong Yidong, emacs-devel, Stefan Monnier, 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 23:54 ` Lennart Borgman
2010-04-30 9:58 ` Kim F. Storm
@ 2010-04-30 9:58 ` Kim F. Storm
1 sibling, 0 replies; 24+ messages in thread
From: Kim F. Storm @ 2010-04-30 9:58 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 5765, Chong Yidong, Kim F. Storm, emacs-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-04-29 15:42 ` Chong Yidong
2010-04-29 15:45 ` Lennart Borgman
@ 2010-04-29 15:45 ` Lennart Borgman
1 sibling, 0 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-04-29 15:45 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5765, Kim F. Storm, emacs-devel, Kim F. Storm
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.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 20:44 ` Chong Yidong
2010-03-25 1:17 ` Lennart Borgman
@ 2010-03-25 1:17 ` Lennart Borgman
1 sibling, 0 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-03-25 1:17 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5765, emacs-devel
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.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 18:28 ` Lennart Borgman
2010-03-24 20:44 ` Chong Yidong
@ 2010-03-24 20:44 ` Chong Yidong
1 sibling, 0 replies; 24+ messages in thread
From: Chong Yidong @ 2010-03-24 20:44 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 5765, emacs-devel
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5765: Strange things happens with C-v in read-file-name
2010-03-24 17:09 ` Chong Yidong
2010-03-24 18:28 ` Lennart Borgman
@ 2010-03-24 18:28 ` Lennart Borgman
1 sibling, 0 replies; 24+ messages in thread
From: Lennart Borgman @ 2010-03-24 18:28 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5765, emacs-devel
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?
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-04-30 9:58 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-27 22:16 Strange things happens with C-v in read-file-name Lennart Borgman
2010-02-02 12:23 ` bug#5511: " Lennart Borgman
2010-03-24 12:37 ` Lennart Borgman
2010-03-24 17:09 ` bug#5765: " Chong Yidong
2010-03-24 17:09 ` Chong Yidong
2010-03-24 18:28 ` Lennart Borgman
2010-03-24 20:44 ` Chong Yidong
2010-03-25 1:17 ` Lennart Borgman
2010-04-29 1:23 ` Lennart Borgman
2010-04-29 1:23 ` Lennart Borgman
2010-04-29 11:37 ` Kim F. Storm
2010-04-29 11:37 ` Kim F. Storm
2010-04-29 15:42 ` Chong Yidong
2010-04-29 15:42 ` Chong Yidong
2010-04-29 15:45 ` Lennart Borgman
2010-04-29 22:51 ` Stefan Monnier
2010-04-29 22:51 ` Stefan Monnier
2010-04-29 23:54 ` Lennart Borgman
2010-04-30 9:58 ` Kim F. Storm
2010-04-30 9:58 ` Kim F. Storm
2010-04-29 15:45 ` Lennart Borgman
2010-03-25 1:17 ` Lennart Borgman
2010-03-24 20:44 ` Chong Yidong
2010-03-24 18:28 ` Lennart Borgman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.