66982Re: Weird behavior after ^ or ´
- Oct 30, 2012Hello Tony,
Tony Mechelynck schrieb:
> On 30/10/12 07:32, Jürgen Krämer wrote:it's probably more a question of the encoding than of the language which
>> Jürgen Krämer wrote:
>>> Christian Brabandt wrote:
>>>> It is for a German layout usually. But I can't reproduce it. And
>>>> possibly also compiler or architecture (32/64bit) dependent.
>>> yesterday, with the example given by Alex I could reproduce it on every
>>> try. Today I tried to construct another example, but it worked only
>>> randomly -- sometimes pressing the caret (or apostrophe or backtick) key
>>> followed by one or more presses of the space bar produced the correct
>>> character immediately, sometimes it was postponed until the next
>>> non-space key was pressed. When it was a letter that could be combined
>>> with the respective accent (like "a" or "e") this was done, in other
>>> cases like "m" or "," the caret and the letter were inserted separately.
> m or , don't accept a circumflex or acute accent IIUC. OTOH, c g h j s
> can have a circumflex in Esperanto, and IIRC w is a vowel in Welsh and
> can accept accents.
letter will be produced. I just wanted to use a key of which I was sure
that when pressed after the dead letter caret would produce the caret
and the corresponding character. "m" and "," are one of those.
The caret key followed by space bar should always produce a caret
character on its own, but sometimes it does not.
BTW, at least Gvim on Windows with enc=utf-8 and fenc=utf-8 does not
seem to produce one of the accented letters you listed, although
pre-composed characters exist for them in the Unicode standard.
>>> I had a look at the source code in gui_w48.c and gui_w32.c, but I couldOn Windows there are two messages (WM_DEADCHAR and WM_SYSDEADCHAR) which
>>> not determine where the dead letter key and the following key are
>>> combined into one character and wether this actually has to be done by
>>> the application or if it's done by Windows.
> the application ought to be able to accept characters from the keyboard,
> e.g. as text input, without even knowing (or caring) whether or not the
> current keyboard layout includes dead keys.
are sent to a program when Windows has processed dead letter keys. Gvim
reacts to both of them by setting a flag in int _OnDeadChar() function.
I don't know whether this behavior is superfluous, incomplete or wrong.
>> additional observation: whenever the caret is not inserted after pressingNo, it's only after a non-space key that the caret appears -- either on
>> the space bar and I use the mouse to switch to another program that allows
>> input, pressing the space bar there results in the caret being inserted.
>> It seems Gvim does not remove the dead letters from the input queue at the
>> correct moment.
> When gvim does not insert a caret after pressing the dead key then the
> space bar, what happens if you press the space bar again? (Does the
> caret appear?)
its own if it's a consonant or as part of an accented letter if it's a
> Or if you press some vowel key instead? (Does it insertAlternating between space bar and some letter key works correctly. It's
> an accented vowel, e.g. ê if you pressed the e key?) — Another
> expreiment: if you press the space bar and some letter key in rapid
> alternation, e.g. x x x x x x x x x x x x x x x x x x x x x , are all
> letters separated from each other by one space? (Though when I tried,
> using one hand for each, I noticed that my hand didn't always hit the
> keyboard in strict alternation.)
only the dead letter keys in combination with space bar that don't
always produce the spacing, non-combining character for the accent. And
when this happens (e.g., caret followed by space produces neither of
both), a second caret produces two carets.
>> A similar behavior can be seen if, e.g., in Notepad one presses the caretI fear it's a bug in Gvim. Windows has messages that can be handled by
>> key, immediately switches to another program by using the mouse, and then
>> presses the space bar: the caret is inserted in the other program, but I
>> guess this is to be expected.
> Sounds like a Windows bug in the keyboard driver to me (not properly
> combining the dead-key event with the keypress event for the following
> spacing key, at least in some circumstances, perhaps conditional on a
> call to some "is there a key waiting?" function not used by Notepad),
> but I could be wrong.
the application. Some hold the combined character in their parameters
(like WM_CHAR) and some -- WM_KEYDOWN and WM_KEYUP -- hold information
on which physical key was pressed. Gvim handles these messages inside
its process_message() function and I guess there can go something wrong
with setting and resetting the dead_key variable.
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>