I noticed that when a process starts for the first time, it statically reads some system parameter info only once and keeps it until terminated
which means,
that if there is some modification to the system parameters already read by the process, they wouldn'y reflect until the process is restarted.
e.g. Launch Notepad and type ';' key on the keyboard. Now change the input language from the langauge toolbar to Spanish. Now again hit the key ';'. Though the Input langauge has been changed to Spanish, the keys are still English (as seen by pressing ';' key).
Ideally on pressing ';' afer the input language is changed to Spanish, we should have noticed 'ñ'.
When we restart Notepad, we notice that ';' results in 'ñ' which means that the Notepad process needed to be restarted to take effect.
Is there some way where the process is not needed to be restarted to reflect the change in the Input method?
Thanks
If a process cares to, it can listen for notifications of changes to various system-wide settings. The wm_SettingChange message comes to mind.
It's a fool's errand to try to make some other process honor setting changes if it hasn't been written to do so. If a program isn't already listening for change notifications and acting upon them, you can't make it act differently.
Notepad probably isn't a good example; it's a pretty simple program, so it doesn't necessarily cover all the details that a good Windows program should.
The "answer" you gave, to refine your question, talks about changing the system's default input language with SystemParametersInfo. When you call that function, it will broadcast the wm_SettingChange message. To be notified of the change, other programs need to listen for that message; do that the same way you listen for any other window messages in your programming environment.
When you receive that message, the wParam parameter will be either spi_GetDefaultInputLang or spi_SetDefaultInputLang; I don't know which. That's you cue to call SystemParametersInfo to find out the new value of the setting. Based on what I've just read in "Languages, Locales, and Keyboard Layouts", you should call ActivateKeyboardLayout using the HKL value you get from SystemParametersInfo.
The process that changes the default input language cannot force other processes to use it. Until they choose for themselves to change their input languages, they will continue using whatever was the language when they started running. That's the distinction between the default setting and the current setting.
Related
I am writing a small shell in Rust on Linux as an exercise and I wanted to implement command history as well as cursor moving (i.e. moving back the cursor to edit a typo in the command).
I did not find a way in the Rust standard library to handle arrow key events, but I found the Termion crate which handles key events.
However, handling key events with Termion means entering "raw mode" for stdout, which overrides "legacy" functionalities, as described in this article about the crate:
Without raw mode, you cannot write a proper interactive TTY application. Raw mode gives you complete control over the TTY:
It disables the line buffering: As you might notice, your command-line application tends to behave like the command-line. The programs will first get the input when the user types \n. Raw mode makes the program get the input after every key stroke.
It disables displaying the input: Without raw mode, the things you type appear on the screen, making it insufficient for most interactive TTY applications, where keys can represent controls and not textual input.
It disables canonicalization of the output: For example, \n represents “go one cell down” not “break the line”, for line breaks \n\r is needed.
It disables scrolling.
I find this solution a bit overkill, as I want to retain most of the "legacy" I/O functionalities. Is there another way to handle arrow key input, or will I need to use the raw mode?
There are several crates that provide line editing features for interactive programs. Here are a few that I found by searching crates.io for "readline" (the name of a C library):
rustyline seems to be the most popular on crates.io.
liner
linefeed
linenoise-rust is a set of Rust bindings to the linenoise library written in C.
I haven't used any of them, so this list is not a recommendation. Take a look at a few of them and choose one that suits your needs.
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 programming a Windows console application in plain C and using PeekConsoleInput/ReadConsoleInput to get keystrokes from the user and process them.
I need to get the current state of the Caps Lock, Scroll Lock, and Num Lock keys when the program starts, before the user has entered anything. Meaning there would be no KEY_EVENTs in the message queue to process.
Is this possible to do? If so, how? I've looked at most of the functions in wincon.h and nothing seems appropriate.
You can call GetAsyncKeyState three times, and it will usually work, but there are a few cases where it still won't work for you. The arguments for your three calls would be VK_CAPITAL, VK_SCROLL, and VK_NUMLOCK.
POSIX 2008 says:
A program that uses these functions should be written to catch all
signals and take other appropriate actions to ensure that when the
program terminates, whether planned or not, the terminal device's
state is restored to its original state.
about using tcgetattr() and tcsetattr() to change the terminal device's state. In general, which signals need to be handled and what "other appropriate actions" must be taken? If this cannot be answered in general, which signals/actions are appropriate when using tcgetattr() and tcsetattr() to turn off terminal echo?
The point of the comment is that tcsetattr will change the properties of the enclosing terminal. Thus, if you write a program that disables terminal echo and that program exits without resetting the value, then it will be disabled for the duration of the session (unless another program explicitly re-enables it).
The appropriate thing to do is, if you are going to change an attribute, save all of the old values before you change them (and then roll back the changes before exiting). This can be done in a signal handler, which is what the recommendation focuses on.
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.