* Caps Lock affects Ctrl+keys @ 2014-01-20 11:57 Yuri Khan 2014-01-20 14:47 ` Jude DaShiell ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Yuri Khan @ 2014-01-20 11:57 UTC (permalink / raw) To: help-gnu-emacs@gnu.org Hello list, I notice that, when I turn on Caps Lock, all Ctrl+letter combinations behave as if I pressed Ctrl+Shift+letter. My expectation is that Caps Lock should not affect any control modifiers (Ctrl, Meta, Super, Hyper), but should affect normal character input (no modifiers or just Shift) and might affect higher levels input (Level3, Level5 and any combinations thereof with or without Shift). $ emacs -Q M-: (read-key) RET press Ctrl+z # 26 (#o32, #x1a) (so far so good) M-: (read-key) RET press Ctrl+Shift+z # 33554458 (#o200000032, #x200001a) (ok) M-: (read-key) RET press Caps Lock to turn it on press Ctrl+z # 33554458 (#o200000032, #x200001a) (expected: 26 (#o32, #x1a)) M-: (read-key) RET with Caps Lock still on press Ctrl+Shift+z # 26 (#o32, #x1a) (expected: 33554458 (#o200000032, #x200001a)) This is on GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2), in Ubuntu 13.10, GUI mode. (In -nw mode, I get 26 no matter whether Shift is pressed and/or Caps is on, which is understandable because in that mode the terminal emulator handles all keyboard input.) Does anybody else observe this? Should I report a bug? Is there an easy workaround? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-20 11:57 Caps Lock affects Ctrl+keys Yuri Khan @ 2014-01-20 14:47 ` Jude DaShiell 2014-01-20 15:24 ` Yuri Khan [not found] ` <mailman.12400.1390231499.10748.help-gnu-emacs@gnu.org> 2014-01-20 20:38 ` Yuri Khan [not found] ` <mailman.12458.1390250342.10748.help-gnu-emacs@gnu.org> 2 siblings, 2 replies; 16+ messages in thread From: Jude DaShiell @ 2014-01-20 14:47 UTC (permalink / raw) To: Yuri Khan; +Cc: help-gnu-emacs@gnu.org On Mon, 20 Jan 2014, Yuri Khan wrote: > Hello list, > > I notice that, when I turn on Caps Lock, all Ctrl+letter combinations > behave as if I pressed Ctrl+Shift+letter. My expectation is that Caps > Lock should not affect any control modifiers (Ctrl, Meta, Super, > Hyper), but should affect normal character input (no modifiers or just > Shift) and might affect higher levels input (Level3, Level5 and any > combinations thereof with or without Shift). > > $ emacs -Q > > M-: (read-key) RET > press Ctrl+z > # 26 (#o32, #x1a) > (so far so good) > > M-: (read-key) RET > press Ctrl+Shift+z > # 33554458 (#o200000032, #x200001a) > (ok) > > M-: (read-key) RET > press Caps Lock to turn it on > press Ctrl+z > # 33554458 (#o200000032, #x200001a) > (expected: 26 (#o32, #x1a)) > > M-: (read-key) RET > with Caps Lock still on > press Ctrl+Shift+z > # 26 (#o32, #x1a) > (expected: 33554458 (#o200000032, #x200001a)) > > This is on GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2), > in Ubuntu 13.10, GUI mode. (In -nw mode, I get 26 no matter whether > Shift is pressed and/or Caps is on, which is understandable because in > that mode the terminal emulator handles all keyboard input.) > > Does anybody else observe this? Should I report a bug? Is there an > easy workaround? > No, the problem is in the Linux kernel emacs is by no means unique in this behavior. > jude <jdashiel@shellworld.net> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-20 14:47 ` Jude DaShiell @ 2014-01-20 15:24 ` Yuri Khan 2014-01-20 17:47 ` Jude DaShiell [not found] ` <mailman.12433.1390240051.10748.help-gnu-emacs@gnu.org> [not found] ` <mailman.12400.1390231499.10748.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 16+ messages in thread From: Yuri Khan @ 2014-01-20 15:24 UTC (permalink / raw) To: Jude DaShiell; +Cc: help-gnu-emacs@gnu.org On Mon, Jan 20, 2014 at 9:47 PM, Jude DaShiell <jdashiel@shellworld.net> wrote: >> >> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations >> behave as if I pressed Ctrl+Shift+letter. >> > No, the problem is in the Linux kernel emacs is by no means unique in > this behavior. Kernel? I don’t think so. xev(1) reports different output when I press Ctrl+Shift+Z and Ctrl+Z with Caps on. Firefox opens a new tab on Ctrl+T (and restores the last closed tab on Ctrl+Shift+T), no matter if Caps is on or off. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-20 15:24 ` Yuri Khan @ 2014-01-20 17:47 ` Jude DaShiell [not found] ` <mailman.12433.1390240051.10748.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 16+ messages in thread From: Jude DaShiell @ 2014-01-20 17:47 UTC (permalink / raw) To: Yuri Khan; +Cc: help-gnu-emacs@gnu.org On Mon, 20 Jan 2014, Yuri Khan wrote: > On Mon, Jan 20, 2014 at 9:47 PM, Jude DaShiell <jdashiel@shellworld.net> wrote: > >> > >> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations > >> behave as if I pressed Ctrl+Shift+letter. > >> > > No, the problem is in the Linux kernel emacs is by no means unique in > > this behavior. > > Kernel? I don?t think so. xev(1) reports different output when I press > Ctrl+Shift+Z and Ctrl+Z with Caps on. Firefox opens a new tab on > Ctrl+T (and restores the last closed tab on Ctrl+Shift+T), no matter > if Caps is on or off. > I'm using linux-speakup over here and I don't use g.u.i. stuff on Linux I have to do that at work and shouldn't have to at home. The only way I found to clear this state was to reboot the amd64 k8 athelon and that cleared it. If I don't do that, I have to hit shift and hold shift down for each lower case letter otherwise even if capslock is off and I am not holding the shift key down, the only thing that comes out is uppercase letters when I type letters and I first noticed this in another linux application having nothing to do with emacs. > jude <jdashiel@shellworld.net> ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <mailman.12433.1390240051.10748.help-gnu-emacs@gnu.org>]
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12433.1390240051.10748.help-gnu-emacs@gnu.org> @ 2014-01-20 18:24 ` Emanuel Berg 0 siblings, 0 replies; 16+ messages in thread From: Emanuel Berg @ 2014-01-20 18:24 UTC (permalink / raw) To: help-gnu-emacs Jude DaShiell <jdashiel@shellworld.net> writes: > I'm using linux-speakup Did you try that for this particular problem or do you use it habitually? I have been experimenting with stuff like that, notably emacspeak (a script that starts Emacs with a TTS extension), only it won't shut up because it is intended for blind people. While I can't, uh, visualize their situation(s), even to a blind person that's a lot of noise. Problem was that I couldn't configure it without having it loaded, and that made me crazy after just a few keystrokes and cursor movements. So I checked it out with 'aptitude show' and found that it was based on espeak, which is available in the Debian repos as a stand-alone-tool, and so I wrote es () { espeak -s 130 -k 20 -v en -f $1 -w `basename $1 .txt`.wav } to create sound files from text, and it should be a small task to setup defuns to interact with it. For a sound file example (and the text file used as input), check out [1]. I don't know if it can replace reading. It will certainly not be as enjoyable. But what do you do? All tricks to compensate for the loss of information intake should be explored... > over here and I don't use g.u.i. stuff on Linux I > have to do that at work and shouldn't have to at > home. Right on! > The only way I found to clear this state was to > reboot the amd64 k8 athelon and that cleared it. What? :) [1] http://user.it.uu.se/~embe8573/espeak_demo/ -- underground experts united: http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <mailman.12400.1390231499.10748.help-gnu-emacs@gnu.org>]
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12400.1390231499.10748.help-gnu-emacs@gnu.org> @ 2014-01-20 17:23 ` Emanuel Berg 2014-01-20 18:30 ` Yuri Khan [not found] ` <mailman.12445.1390242632.10748.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 16+ messages in thread From: Emanuel Berg @ 2014-01-20 17:23 UTC (permalink / raw) To: help-gnu-emacs Yuri Khan <yuri.v.khan@gmail.com> writes: >> No, the problem is in the Linux kernel emacs is by >> no means unique in this behavior. > > Kernel? I don't think so. xev(1) reports different > output when I press Ctrl+Shift+Z and Ctrl+Z with Caps > on. Firefox opens a new tab on Ctrl+T (and restores > the last closed tab on Ctrl+Shift+T), no matter if > Caps is on or off. Some information on this, see if you can figure it out: In keymaps(5), there is some information what to do with caps: > Which of the actions bound to a given key is taken > when it is pressed depends on what modifiers are in > effect at that moment. The keyboard driver supports > 9 modifiers. These modifiers are labeled (completely > arbitrarily) Shift, AltGr, Control, Alt, ShiftL, > ShiftR, CtrlL, CtrlR and CapsShift. Each of these > modifiers has an associated weight of power of two > according to the following table: > modifier weight > Shift 1 > AltGr 2 > Control 4 > Alt 8 > ShiftL 16 > ShiftR 32 > CtrlL 64 > CtrlR 128 > CapsShift 256 # swap control and caps keycode 58 = Control keycode 29 = Caps_Lock # always enable on caps, disable on either shift keycode 42 = Uncaps_Shift # left shift keycode 54 = Uncaps_Shift # right shift keycode 58 = Caps_On # caps Note: Get the keycodes with 'showkey', then update changes to the remap file with 'sudo loadkeys'. If 'showkey' complains it can't get access to the console it means you are running it for example in tmux, if so use 'sudo showkey' (every time) or 'sudo chmod u+s /usr/bin/showkey' to make it work ever since. With 'showkey -s', it doesn't seem to be possible to get what you describe. -- underground experts united: http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-20 17:23 ` Emanuel Berg @ 2014-01-20 18:30 ` Yuri Khan [not found] ` <mailman.12445.1390242632.10748.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 16+ messages in thread From: Yuri Khan @ 2014-01-20 18:30 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs@gnu.org On Tue, Jan 21, 2014 at 12:23 AM, Emanuel Berg <embe8573@student.uu.se> wrote: > > Some information on this, see if you can figure it out: > > In keymaps(5), there is some information what to do > with caps: > […] > > Note: Get the keycodes with 'showkey', then update > changes to the remap file with 'sudo loadkeys'. I’m in X, I thought I was clear enough. Why or how are keymaps(5)/showkey(1)/loadkeys(1) relevant? ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <mailman.12445.1390242632.10748.help-gnu-emacs@gnu.org>]
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12445.1390242632.10748.help-gnu-emacs@gnu.org> @ 2014-01-20 18:53 ` Emanuel Berg 0 siblings, 0 replies; 16+ messages in thread From: Emanuel Berg @ 2014-01-20 18:53 UTC (permalink / raw) To: help-gnu-emacs Yuri Khan <yuri.v.khan@gmail.com> writes: >> Some information on this, see if you can figure it >> out: In keymaps(5), there is some information what >> to do with caps: > > I'm in X, I thought I was clear enough. Why or how > are keymaps(5)/showkey(1)/loadkeys(1) relevant? If you read the keymaps man page, it sure looks like it is impossible (the "CapsShift") - this of course does not imply that the kernel cannot do it in principle, it just doesn't (what I can read) in that case. How X does its I/O, and how this relates to the kernel, I don't know. -- underground experts united: http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-20 11:57 Caps Lock affects Ctrl+keys Yuri Khan 2014-01-20 14:47 ` Jude DaShiell @ 2014-01-20 20:38 ` Yuri Khan [not found] ` <mailman.12458.1390250342.10748.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 16+ messages in thread From: Yuri Khan @ 2014-01-20 20:38 UTC (permalink / raw) To: help-gnu-emacs@gnu.org On Mon, Jan 20, 2014 at 6:57 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote: > I notice that, when I turn on Caps Lock, all Ctrl+letter combinations > behave as if I pressed Ctrl+Shift+letter. OK, I looked at the code. In xterm.c, function handle_one_xevent, a KeyPress event is received, with state == 0x06 (LockMask | ControlMask) and keycode == 52 (<AB01> according to xkb/keycodes/evdev). Then, XmbLookupString is called on this event, producing keysym == 0x5a ('Z') and storing a single 0x1a character to copy_bufptr. The latter is ignored because the “if (keysym >= 32 && keysym < 128)” branch is taken, producing an event {kind: ASCII_KEYSTROKE_EVENT, code: 0x5a, modifiers: ctrl_modifier}. The LockMask bit is lost at this point. Then, under the “done:” label, the kbd_buffer_store_event_hold function from keyboard.c is called, which in turn calls make_ctrl_char, which sees 0x5a and sets the shift_modifier. After this, no further processing, in Lisp or in C, can detect that the Shift key was not in fact pressed. The problem stems from the concept that keyboard input is a stream of (extended) characters and any modifier keys just add modifier bits to those characters. I do not think it can be fixed or worked around without a significant rethinking of the input model. This is unfortunate because, as a user, I expect Caps Lock to only affect character input, not command bindings. As it is, turning on Caps Lock upsets any key bindings that involve Shift. This includes cua-mode’s C-x and C-c, and any user-defined bindings (in my case, C-S-z = redo and C-S-u = insert-char). Related: When I switch XKB groups (e.g. activate Russian layout), I lose all C-letter and M-letter bindings, because they then produce Cyrillic letters with the respective modifiers. E.g. with US English QWERTY as primary and Russian ЙЦУКЕН as secondary, pressing Ctrl+W produces C-ц instead of C-w. I work around this with an ugly key-translation-map hack. ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <mailman.12458.1390250342.10748.help-gnu-emacs@gnu.org>]
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12458.1390250342.10748.help-gnu-emacs@gnu.org> @ 2014-01-20 22:55 ` Emanuel Berg 2014-01-21 2:10 ` Emanuel Berg 1 sibling, 0 replies; 16+ messages in thread From: Emanuel Berg @ 2014-01-20 22:55 UTC (permalink / raw) To: help-gnu-emacs Yuri Khan <yuri.v.khan@gmail.com> writes: > OK, I looked at the code. OK, great job! > The LockMask bit is lost at this point. Can you see a reason for this? Are there too few bits? Or isn't it needed, the what it is now, having "uppercased" the letter, its job done? > Then, under the “done:” label, the > kbd_buffer_store_event_hold function from keyboard.c > is called, which in turn calls make_ctrl_char, which > sees 0x5a and sets the shift_modifier. OK, so the problem is, shift isn't shift because the shift *key* is pressed, shift is shift because the char is *uppercase*? -- underground experts united: http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12458.1390250342.10748.help-gnu-emacs@gnu.org> 2014-01-20 22:55 ` Emanuel Berg @ 2014-01-21 2:10 ` Emanuel Berg 2014-01-21 5:07 ` Yuri Khan ` (3 more replies) 1 sibling, 4 replies; 16+ messages in thread From: Emanuel Berg @ 2014-01-21 2:10 UTC (permalink / raw) To: help-gnu-emacs Yuri Khan <yuri.v.khan@gmail.com> writes: > This is unfortunate because, as a user, I expect Caps > Lock to only affect character input, not command > bindings. As it is, turning on Caps Lock upsets any > key bindings that involve Shift. This includes > cua-mode’s C-x and C-c, and any user-defined bindings > (in my case, C-S-z = redo and C-S-u = insert-char). Just thought of one thing, there is a caps-mode.el, written by a man on this list, which is great, because it gives you caps lock functionality, but *buffer local* (and thus obviously contained to Emacs). All mistakes with caps is when you set it, type (in caps), then move to somewhere else, and type something else, and for some reason you always think it won't stick, but it does. So it is great to have that mode and I think it won't influence shift, because what it does is substitute-key-definition on the self-insert-command chars, so shift should float a parallel current. Because I see you are a C programmer, you might even want to check out a post on that I wrote some time ago, with some modifications to caps-mode, where it auto-disables after one word, so you can write a #define MONEY 0 with just one press of the caps key (preferably bounded to invoke caps-mode, not bothering with the physical keyboard state). -- underground experts united: http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-21 2:10 ` Emanuel Berg @ 2014-01-21 5:07 ` Yuri Khan [not found] ` <mailman.12490.1390280831.10748.help-gnu-emacs@gnu.org> ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Yuri Khan @ 2014-01-21 5:07 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs@gnu.org On Tue, Jan 21, 2014 at 9:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote: > > Just thought of one thing, there is a caps-mode.el, > written by a man on this list, which is great, because > it gives you caps lock functionality, but *buffer > local* (and thus obviously contained to Emacs). Nice. I had to s/last-command-char/last-command-event/ in github:emacsmirror/caps-mode version, but otherwise it works and preserves control combinations. It even works with Cyrillic letters, thanks to the use of [remap self-insert-command] and (upcase last-command-event). This is a bit clumsy because I have to have different keys to turn on caps in Emacs and in the rest of my environment, but will do for a while. > Because I see you are a C programmer, you > might even want to check out a post on that I wrote > some time ago, with some modifications to caps-mode, > where it auto-disables after one word, so you can write > a #define MONEY 0 with just one press of the caps key > (preferably bounded to invoke caps-mode, not bothering > with the physical keyboard state). Actually in C++ we prefer preprocessor macros to be hard to type ;] Anyway, I’d better bind an easy key to “upcase symbol to the left of point”. In fact I am working with a file where I need caps in some of the columns but not in others. I might take the idea of caps-mode and add a condition, so that it does the right thing for my case. ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <mailman.12490.1390280831.10748.help-gnu-emacs@gnu.org>]
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12490.1390280831.10748.help-gnu-emacs@gnu.org> @ 2014-01-21 17:38 ` Emanuel Berg 0 siblings, 0 replies; 16+ messages in thread From: Emanuel Berg @ 2014-01-21 17:38 UTC (permalink / raw) To: help-gnu-emacs Yuri Khan <yuri.v.khan@gmail.com> writes: > Nice. I had to > s/last-command-char/last-command-event/ in > github:emacsmirror/caps-mode version, but otherwise > it works and preserves control combinations. It even > works with Cyrillic letters, thanks to the use of > [remap self-insert-command] and (upcase > last-command-event). That's interesting. I wonder if the programmers thought of that of if it is a consequence of good design on multiple parts. > This is a bit clumsy because I have to have different > keys to turn on caps in Emacs and in the rest of my > environment, but will do for a while. That's always the drawback when you solve things that you wish system-wide on the application level. But that's where Emacs is somewhat a special case, because you can do so many things with Emacs, so setting things up in Emacs (not trivial but perhaps not the most difficult thing in the world) can pay off big if one's Emacs use propagates to still new fields of activity. When I setup caps-mode.el, I thought it wouldn't matter otherwhere because I only type otherwise in zsh, and there I wouldn't need uppercased words. But that proved to be incorrect: * The computer world is filled with acronyms: gui, cpu, smtp, dram, mud, mmorpg, irc, ... though I could get used to it, they don't look the same. * Also, while I prefer readme.txt, some old-schoolers say that files intended for humans should look like README instead. * And, not the least, the env vars - HOME, PATH, etc. So I wonder if something like caps-mode.el can be found and setup on the terminal/multiplexer/shell level. I have already rerouted the caps key to produce a goofy Unicode char, which Emacs fetches and evaluates to activating the caps mode, and when I hit that key in tty/tmux/zsh, that char appears (or actually a diamond, as it is U+0111, which apparently is stretching it for the poor driver, or perhaps it isn't even printable) - but anyway it appears, so what's saying I can't do the same dance once again? To do it there (the shell, or on top of whatever) would be feasible, but to do it like 20 times if you use that many applications and cannot solve it at a lower level, then you have to use the caps key a whole lot to make it worth it :) -- underground experts united: http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-21 2:10 ` Emanuel Berg 2014-01-21 5:07 ` Yuri Khan [not found] ` <mailman.12490.1390280831.10748.help-gnu-emacs@gnu.org> @ 2014-01-24 14:38 ` Yuri Khan 2014-01-24 15:56 ` Stefan Monnier [not found] ` <mailman.12684.1390574300.10748.help-gnu-emacs@gnu.org> 3 siblings, 1 reply; 16+ messages in thread From: Yuri Khan @ 2014-01-24 14:38 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs@gnu.org On Tue, Jan 21, 2014 at 9:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote: > Just thought of one thing, there is a caps-mode.el, > written by a man on this list, which is great, because > it gives you caps lock functionality, but *buffer > local* (and thus obviously contained to Emacs). Does anyone happen to know what is the canonical repository for caps-mode? I’d like to submit a couple of patches that fix the following: * the use of obsolete last-command-char variable, * caps-mode ignores the state of overwrite-mode and always inserts. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Caps Lock affects Ctrl+keys 2014-01-24 14:38 ` Yuri Khan @ 2014-01-24 15:56 ` Stefan Monnier 0 siblings, 0 replies; 16+ messages in thread From: Stefan Monnier @ 2014-01-24 15:56 UTC (permalink / raw) To: help-gnu-emacs > Does anyone happen to know what is the canonical repository for > caps-mode? I’d like to submit a couple of patches that fix the > following: > * the use of obsolete last-command-char variable, > * caps-mode ignores the state of overwrite-mode and always inserts. FWIW I've been using the following hack occasionally. Never bothered to distribute it. Stefan (defvar caps-lock-commands '(self-insert-command isearch-printing-char) "List of commands that are subject to `caps-lock-mode'.") (define-minor-mode caps-lock-mode "Make self-inserting keys invert the capitalization." :global t (if caps-lock-mode (add-hook 'pre-command-hook #'caps-lock--pch) (remove-hook 'pre-command-hook #'caps-lock--pch))) (defun caps-lock--pch () (when (memq this-command caps-lock-commands) (setq last-command-event (condition-case nil (let ((up (upcase last-command-event))) (if (eq up last-command-event) (downcase last-command-event) up)) (error last-command-event))))) ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <mailman.12684.1390574300.10748.help-gnu-emacs@gnu.org>]
* Re: Caps Lock affects Ctrl+keys [not found] ` <mailman.12684.1390574300.10748.help-gnu-emacs@gnu.org> @ 2014-01-24 15:22 ` Dan Espen 0 siblings, 0 replies; 16+ messages in thread From: Dan Espen @ 2014-01-24 15:22 UTC (permalink / raw) To: help-gnu-emacs Yuri Khan <yuri.v.khan@gmail.com> writes: > On Tue, Jan 21, 2014 at 9:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote: > >> Just thought of one thing, there is a caps-mode.el, >> written by a man on this list, which is great, because >> it gives you caps lock functionality, but *buffer >> local* (and thus obviously contained to Emacs). > > Does anyone happen to know what is the canonical repository for > caps-mode? I’d like to submit a couple of patches that fix the > following: > * the use of obsolete last-command-char variable, > * caps-mode ignores the state of overwrite-mode and always inserts. Don't know, but I changed my copy to use last-command-event. Right now I have a need to use caps-mode in XEmacs. It runs without complaint but doesn't work, I get lower case regardless of the mode. I haven't looked in detail yet to find the issue with XEmacs. -- Dan Espen ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-01-24 15:56 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-20 11:57 Caps Lock affects Ctrl+keys Yuri Khan 2014-01-20 14:47 ` Jude DaShiell 2014-01-20 15:24 ` Yuri Khan 2014-01-20 17:47 ` Jude DaShiell [not found] ` <mailman.12433.1390240051.10748.help-gnu-emacs@gnu.org> 2014-01-20 18:24 ` Emanuel Berg [not found] ` <mailman.12400.1390231499.10748.help-gnu-emacs@gnu.org> 2014-01-20 17:23 ` Emanuel Berg 2014-01-20 18:30 ` Yuri Khan [not found] ` <mailman.12445.1390242632.10748.help-gnu-emacs@gnu.org> 2014-01-20 18:53 ` Emanuel Berg 2014-01-20 20:38 ` Yuri Khan [not found] ` <mailman.12458.1390250342.10748.help-gnu-emacs@gnu.org> 2014-01-20 22:55 ` Emanuel Berg 2014-01-21 2:10 ` Emanuel Berg 2014-01-21 5:07 ` Yuri Khan [not found] ` <mailman.12490.1390280831.10748.help-gnu-emacs@gnu.org> 2014-01-21 17:38 ` Emanuel Berg 2014-01-24 14:38 ` Yuri Khan 2014-01-24 15:56 ` Stefan Monnier [not found] ` <mailman.12684.1390574300.10748.help-gnu-emacs@gnu.org> 2014-01-24 15:22 ` Dan Espen
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).