* bug#5511: Strange things happens with C-v in read-file-name [not found] <e01d8a51001271416i56a286ffy983fbca024284e75@mail.gmail.com> @ 2010-02-02 12:23 ` Lennart Borgman 2010-03-24 12:37 ` Lennart Borgman 0 siblings, 1 reply; 13+ 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] 13+ messages in thread
* Re: Strange things happens with C-v in read-file-name 2010-02-02 12:23 ` bug#5511: Strange things happens with C-v in read-file-name Lennart Borgman @ 2010-03-24 12:37 ` Lennart Borgman 2010-03-24 17:09 ` bug#5765: " Chong Yidong [not found] ` <87eij9r6hu.fsf@stupidchicken.com> 0 siblings, 2 replies; 13+ 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] 13+ 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 [not found] ` <87eij9r6hu.fsf@stupidchicken.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <87eij9r6hu.fsf@stupidchicken.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <87eij9r6hu.fsf@stupidchicken.com> @ 2010-03-24 18:28 ` Lennart Borgman [not found] ` <e01d8a51003241128x60fc5a2g5322c71225a4aa2e@mail.gmail.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <e01d8a51003241128x60fc5a2g5322c71225a4aa2e@mail.gmail.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <e01d8a51003241128x60fc5a2g5322c71225a4aa2e@mail.gmail.com> @ 2010-03-24 20:44 ` Chong Yidong [not found] ` <87iq8l1mbc.fsf@stupidchicken.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <87iq8l1mbc.fsf@stupidchicken.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <87iq8l1mbc.fsf@stupidchicken.com> @ 2010-03-25 1:17 ` Lennart Borgman [not found] ` <e01d8a51003241817u2ac17846mf370517dfdec5bfe@mail.gmail.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <e01d8a51003241817u2ac17846mf370517dfdec5bfe@mail.gmail.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <e01d8a51003241817u2ac17846mf370517dfdec5bfe@mail.gmail.com> @ 2010-04-29 1:23 ` Lennart Borgman [not found] ` <o2ke01d8a51004281823t88e495f8t18e175956941a684@mail.gmail.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <o2ke01d8a51004281823t88e495f8t18e175956941a684@mail.gmail.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <o2ke01d8a51004281823t88e495f8t18e175956941a684@mail.gmail.com> @ 2010-04-29 11:37 ` Kim F. Storm [not found] ` <877hnqpk08.fsf@kfs-lx.rd.rdm> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <877hnqpk08.fsf@kfs-lx.rd.rdm>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <877hnqpk08.fsf@kfs-lx.rd.rdm> @ 2010-04-29 15:42 ` Chong Yidong [not found] ` <8739ye1d08.fsf@stupidchicken.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <8739ye1d08.fsf@stupidchicken.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <8739ye1d08.fsf@stupidchicken.com> @ 2010-04-29 15:45 ` Lennart Borgman [not found] ` <g2oe01d8a51004290845na9909469x5cc5e7d3ce540810@mail.gmail.com> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <g2oe01d8a51004290845na9909469x5cc5e7d3ce540810@mail.gmail.com>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <g2oe01d8a51004290845na9909469x5cc5e7d3ce540810@mail.gmail.com> @ 2010-04-29 22:51 ` Stefan Monnier [not found] ` <jwv6339q3d3.fsf-monnier+emacs@gnu.org> 1 sibling, 0 replies; 13+ 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] 13+ messages in thread
[parent not found: <jwv6339q3d3.fsf-monnier+emacs@gnu.org>]
* bug#5765: Strange things happens with C-v in read-file-name [not found] ` <jwv6339q3d3.fsf-monnier+emacs@gnu.org> @ 2010-04-29 23:54 ` Lennart Borgman 2010-04-30 9:58 ` Kim F. Storm 0 siblings, 1 reply; 13+ 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] 13+ 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 0 siblings, 0 replies; 13+ 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] 13+ messages in thread
end of thread, other threads:[~2010-04-30 9:58 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <e01d8a51001271416i56a286ffy983fbca024284e75@mail.gmail.com>
2010-02-02 12:23 ` bug#5511: Strange things happens with C-v in read-file-name Lennart Borgman
2010-03-24 12:37 ` Lennart Borgman
2010-03-24 17:09 ` bug#5765: " Chong Yidong
[not found] ` <87eij9r6hu.fsf@stupidchicken.com>
2010-03-24 18:28 ` Lennart Borgman
[not found] ` <e01d8a51003241128x60fc5a2g5322c71225a4aa2e@mail.gmail.com>
2010-03-24 20:44 ` Chong Yidong
[not found] ` <87iq8l1mbc.fsf@stupidchicken.com>
2010-03-25 1:17 ` Lennart Borgman
[not found] ` <e01d8a51003241817u2ac17846mf370517dfdec5bfe@mail.gmail.com>
2010-04-29 1:23 ` Lennart Borgman
[not found] ` <o2ke01d8a51004281823t88e495f8t18e175956941a684@mail.gmail.com>
2010-04-29 11:37 ` Kim F. Storm
[not found] ` <877hnqpk08.fsf@kfs-lx.rd.rdm>
2010-04-29 15:42 ` Chong Yidong
[not found] ` <8739ye1d08.fsf@stupidchicken.com>
2010-04-29 15:45 ` Lennart Borgman
[not found] ` <g2oe01d8a51004290845na9909469x5cc5e7d3ce540810@mail.gmail.com>
2010-04-29 22:51 ` Stefan Monnier
[not found] ` <jwv6339q3d3.fsf-monnier+emacs@gnu.org>
2010-04-29 23:54 ` Lennart Borgman
2010-04-30 9:58 ` Kim F. Storm
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).