As you probably know if you write text in multiple languages and use Emacs, Emacs has its own input method system independent of Windows (or other operating systems). Input methods can be toggled with toggle-input-method command. When Windows language changes, Emacs receives a <language-change> keypress. I would like then to bind <language-change> to toggle-input-method. Unfortunately, if I do just
(global-set-key (kbd "<language-change>") 'toggle-input-method)
both Windows language and input method will be toggled. So I need something like
(defvar safe-language-change-flag nil)
(defun safe-language-change ()
(interactive)
(setq safe-language-change-flag (not safe-language-change-flag))
(when safe-language-change-flag
(toggle-input-method)
(send-key (kbd "<language-change>"))))
(global-set-key (kbd "<language-change>") 'safe-language-change)
What I can't seem to find is a function call which would send a key to the operating system (or change the system language in another way).
Just to make sure, you want this to happen: You change the language in the OS. Emacs gets this event, sends a keypress back to the OS, and then un-changes the language.
You may be able to call an external utility to do this.
I'm not sure why you want to do this, though.
If you've changed the OS's language, then let the OS handle the input method. If you don't want to use your OS's input method, then do toggle-input-method inside emacs, and don't bother worrying about the OS's state.
Am I missing something?
If you don't want to use your OS's input method, then do toggle-input-method inside emacs, and don't bother worrying about the OS's state.
This is precisely the result I want to get. The difficulty is that I find myself switching the OS input method instead all the time because "press Shift to switch language" is a part of my finger memory by now.
Related
I've read most of the manual and am slowly getting my head around the things I need to make major-modes, etc. I've not ran into anything that explains the loop/cycle that Emacs goes through to apply the major mode (or minor-mode even).
For example: I type if while in go-mode and suddenly if is syntax-highlight. I know that just typing common letters amounts to self-insert-command. So how does emacs then react to the change in the buffer unless either self-insert-command fires and event or just changing the buffer fires and event?
W.r.t syntax highlighting, this is triggered by any change to the buffer, no matter which command is used. To do this, the package taking care of keeping the highlighting up-to-date (typically jit-lock on behalf of font-lock) uses after-change-functions. See C-hv after-change-functions RET and also check the corresponding documentation in the Emacs Lisp reference manual (reachable from the "Help" menu).
I'm writing a command interpreter like BASH, and a \ followed by a newline implies a continuation of the input stream; how can I implement that in Win32?
If I use the console mode with ENABLE_LINE_INPUT, then the user can't press backspace in order to go back to the previous line; Windows prevents him from doing so. But if I don't set ENABLE_LINE_INPUT, then I have to manually reposition the cursor, which is rather tedious given that (1) the user might have redirected the input stream, and that (2) it might be prone to race conditions, and I'd rather have Windows do it if I can.
Any way to have my newline and eat it too?
Edit:
If this would require undocumented CSRSS port requests, then I'm still interested!
Assuming you want this to run in a window, like command prompt does by default, rather than full screen, you could create a GUI application with a large textbox. Users would type into the textbox, and you could parse whatever was entered, and output to the same box (effectively emulated the Win32 Console).
This way whatever rules you want to set for how the console behaves is completely up to you.
I might be mistaken is saying this, but I believe that the Win32 Console from XP onward works exactly like this, and it just listens for output on stdout; there shouldn't be any reason you can't do the same.
Hope this was helpful.
I'm using curses to develop a small console application.
I have a main loop section which waits for user input, it uses the getstr function, of course this waits for the user to press enter.
I would like to capture the up and down and tab keypresses. I suppose this can't be done with getstr.
Anyone have any idea how to do this?
EDIT: I've tried using STDIN.getc wihch blocks the application from running, and getch doesn't catch the arrow keys.
EDIT #2: I'm trying this code on Windows. It seems that Curses.getch works for Linux, but on Windows I get no key sent for the up arrow.
You need to set the "cbreak" mode of the tty so that you get keypresses immediately. If you don't do this, the Unix terminal-handling system will buffer the input until a newline is received (i.e., the user hits ENTER), and the input will all be handed to the process at that point.
This isn't actually Ruby- or even curses-specific; this is the way all applications work that run through a Unix tty.
Try using the curses library cbreak() function to turn on this mode. Don't forget to call nocbreak() to turn it off before you exit!
For reading a single character, STDIN.getc will return a Fixnum of the ASCII code of the character. Quite possibly you'll find STDIN.read(1) to be more convenient, since it returns a one-character string of the next character.
However, you'll find that the "up/down" keys,if by that you mean the arrow keys, are actually a sequence of characters. On most ANSI-like terminal emulators these days (such as xterm), the up arrow will be "\e[A" (that \e is an escape character) for example. There are termcap (terminal capability) databases to deal with this sort of thing, and you can access them through curses, but intially you may find it easiest just to experiment with interpreting these directly; you're not very likely to run into a terminal using anything other than ANSI codes these days.
you want getch rather than getstr. also see curt sampson's comment about the arrow keys not being a single character.
I'm playing around with making a simple terminal-based game with Ruby, and I'm currently trying to come up with a way of reading input from the terminal.
So far I've been using gets, but I'd like to have the game react instantly without requiring a newline (so you don't need to press a key, THEN enter).
I've figured out I need to put the terminal in non-canonical mode, and I'm assuming I can do that by calling $stdin.ioctl. The problem is, I'm not sure what arguments or flags I should be passing to this, and the documentation and searches just lead to information about the underlying C function.
Can anyone tell me what I should be calling $stdin.ioctl with? I'm using Terminal.app/tcsh on OSX Leopard.
Edit: This is what I ended up using, thanks to MarkusQ:
%x{stty -icanon -echo}
key = STDIN.read(1)
Your problem is outside of ruby.
Easiest answer: wrap your IO in %x{stty -raw echo} and %x{stty -raw echo} to change the mode with stty.
You'll probably want to do and ensure an exit handler to make certain the mode is set back when you exit.
-- MarkusQ
I'm using ccl/openmcl on Mac OS X. (latest versions of both). When the lisp prompt is displayed, using the cursor keys to navigate the current line results in escape codes, rather than movement, eg:
Welcome to Clozure Common Lisp Version 1.2-r9226-RC1 (DarwinX8664)!
? (^[[D
Here I've pressed the ( key, and then the left cursor key.
When I run ccl/openmcl on a Debian Etch box, the cursor behaves as expected, and moves the insert point one position left.
I guess this is some sort of terminal configuration option?
If Clozure CL doesn't provide native readline/editline/whatever support or is configured not to use it, you can run it with rlwrap, for example:
rlwrap openmcl
rlwrap can be obtained via MacPorts or directly from http://utopia.knoware.nl/~hlub/rlwrap/.
i know that i'm not answering the question with this, but you should not spend much time directly using a lisp repl.
using emacs and slime is a much more convenient way of interacting with a lisp. you have an inspector and a debugger at hand, you can jump to the source code of the functions, etc.