Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple key results in '@' #310

Closed
dhleong opened this issue Sep 24, 2013 · 25 comments
Closed

Apple key results in '@' #310

dhleong opened this issue Sep 24, 2013 · 25 comments
Labels

Comments

@dhleong
Copy link
Contributor

dhleong commented Sep 24, 2013

I don't have a perfect repro yet, but periodically I'll do an apple+shift+t to search for a class, or apple+shift+r to open a resource, or even a simple apple+s to save or apple+tab to switch to a different app, and random stuff will happen unexpectedly—it feels like something is being pasted, or maybe some action in my history is running, but I'm not exactly sure. I played with it a bit, and it's definitely right when I press down on the apple key.

I'm running on the latest unstable, just updated yesterday and it still happens. I'm running Kepler on OSX 10.8.4. There are no mappings or with the apple key in my .vrapperrc

@dhleong
Copy link
Contributor Author

dhleong commented Sep 24, 2013

The forward slash / to search also sometimes triggers this bug

@dhleong
Copy link
Contributor Author

dhleong commented Sep 25, 2013

The thing it pastes might be the contents of the pasteboard/clipboard, as opposed to the regular copy register

@dhleong
Copy link
Contributor Author

dhleong commented Sep 25, 2013

Honestly, guys, I have no idea what's even happening. I was on line 85 of a file in normal mode and hit a to append, and it jumped up to like 67 and inserted a bunch of crap (which may have coincidentally been—or WAS it a coincedence?—in my "a" register).

@dhleong
Copy link
Contributor Author

dhleong commented Sep 26, 2013

Hmm, might be on to something. I hit * just now find the next occurrence of the word under my cursor, and it inserted the contents of the pasteboard/clipboard, IE the "* register.

This ringing any bells for anyone?

@albertdev
Copy link
Member

I've got no idea what is happening.

Do you have a wireless keyboard by any chance or are you using a remote session? It sounds like some modifier keys get stuck or so?

@dhleong
Copy link
Contributor Author

dhleong commented Sep 26, 2013

Nope, and nope :( USB keyboard on the machine. It started happening after I updated my Vrapper install a while ago. If it helps, my previous configuration was on 8/2/2013 and had Vrapper Unstable 0.33.20130728, and currently I've got 0.35.201309141

I have the following Vrapper plugins installed: ipmotion.vim, Java Extensions, Split Editor, Surround.vim

@keforbes
Copy link
Contributor

I have no idea what could possibly cause the behavior you're seeing (especially since you don't really have a consistent way of reproducing it). However, about a month ago I had committed a small fix for a corner case feature. That fix apparently broke "<char> and possibly some other features. I reverted that commit but I hadn't updated the unstable update site since reverting it. I've now updated the unstable update site with a new build (0.35.201309281) which includes this revert. Maybe that will have some effect on the defect you're seeing. Let us know if it doesn't fix anything, though I'm afraid I'm clueless on what we could try next.

@dhleong
Copy link
Contributor Author

dhleong commented Sep 28, 2013

Thanks, I'll give it a shot once I get back into the office on Monday!
On Sep 28, 2013 3:58 PM, "keforbes" notifications@github.com wrote:

I have no idea what could possibly cause the behavior you're seeing
(especially since you don't really have a consistent way of reproducing
it). However, about a month ago I had committed a small fix for a corner
case feature. That fix apparently broke " and possibly some other
features. I reverted that commit but I hadn't updated the unstable update
site since reverting it. I've now updated the unstable update site with a
new build (0.35.201309281) which includes this revert. Maybe that will
have some effect on the defect you're seeing. Let us know if it doesn't fix
anything, though I'm afraid I'm clueless on what we could try next.


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25307305
.

@dhleong
Copy link
Contributor Author

dhleong commented Sep 30, 2013

Still occurs, if less notable so far.

I have noticed that pressing the apple key causes "@" to show up in the status bar. I don't use macros that often, but that could explain some of the weird behavior. No idea why the / would "sometimes" do anything unexpected, though.

@keforbes
Copy link
Contributor

@albertdev, is it possible this is related to the AltGr issue we had before? I don't know what keycode the apple key has but maybe vrapper is interpreting it as a combination of keys.

@albertdev
Copy link
Member

@keforbes Anything is possible, but I don't own a Mac.

@dhleong If you press the Apple key several times in a row with a second between each press, do you see Vrapper putting the @ symbol in the status bar every other time?

@dhleong
Copy link
Contributor Author

dhleong commented Oct 1, 2013

Yep, and it executes stuff in a register on the other time. I hit qq to
record some stuff into that register, then hit the apple key twice in a row
and it executed that q register, if I remember correctly.
On Oct 1, 2013 4:50 AM, "albertdev" notifications@github.com wrote:

@keforbes https://github.com/keforbes Anything is possible, but I don't
own a Mac.

@dhleong https://github.com/dhleong If you press the Apple key several
times in a row with a second between each press, do you see Vrapper putting
the @ symbol in the status bar every other time?


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25434007
.

@dhleong
Copy link
Contributor Author

dhleong commented Oct 1, 2013

Anything I can do to test the keycode for you?

Not sure if this is what you're looking for, but this StackOverflow shows the command key as 0x37

@albertdev
Copy link
Member

If you can debug Vrapper, you'd want to put a breakpoint in VimInputInterceptorFactory on line 162 and then tell us all the values of the event variables' fields.

@keforbes
Copy link
Contributor

keforbes commented Oct 2, 2013

This is the one defect I'd really like to fix before we release 0.36.0 this weekend. I'm surprised there aren't any other Mac users having similar issues. Maybe no other Mac users are using the unstable builds.

@dhleong, we're mostly interested in if that event claims that Ctrl and/or Alt are pressed. Then we can hopefully figure out what keycode to map it to internally. That's basically how we had to handle the AltGr key on German keyboards.

@dhleong
Copy link
Contributor Author

dhleong commented Oct 2, 2013

Okay, just for you guys I pulled the changes and spun up my debugger with
the breakpoint. The event object says (copied directly from Eclipse):

character
data null
doit true
end 0
keyCode 4194304
keyLocation 16384
start 0
stateMask 0
text null

Also:

shiftKey false
altKey false
ctrlKey false

Right now in my debug instance, hitting the apple key acts as "@" 100% of
the time, and it does it on key down so if I apple+tab out, the "@" will
still be in the status bar when I tab back in. The first time, I think I
was able to repro the weirdness by recording stuff into the "q" register
(qqdWq) and then hitting "apple,apple." But, quitting the debug instance
and restarting didn't do it, so maybe I recorded it into "@" instead... not
sure.

My Eclipse here is still Juno, not Kepler. Hope this helps!

On Tue, Oct 1, 2013 at 11:40 PM, keforbes notifications@github.com wrote:

This is the one defect I'd really like to fix before we release 0.36.0
this weekend. I'm surprised there aren't any other Mac users having similar
issues. Maybe no other Mac users are using the unstable builds.

@dhleong https://github.com/dhleong, we're mostly interested in if that
event claims that Ctrl and/or Alt are pressed. Then we can hopefully
figure out what keycode to map it to internally. That's basically how we
had to handle the AltGr key on German keyboards.


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25511521
.

@albertdev
Copy link
Member

@dhleong
Aha! Thanks a lot! You did forget to copy the "character" field, though I can only guess that Eclipse fills it with "@".

It does seem the KeyCode is unique, and there is actually an SWT constant for it: SWT.COMMAND, so the "Apple key" in your description was just a red herring.

Now, what would you like to do with it? The easiest way going forward is to simply ignore the Apple key, and any Eclipse shortcuts you trigger using it will simply never invoke Vrapper. Is that OK for you?

@dhleong
Copy link
Contributor Author

dhleong commented Oct 2, 2013

Actually the character field was empty... Not sure if that changes
anything. I just selected the rows and did a copy paste, so whatever is
there is whatever was in the table.

Sorry for the confusion.... I've always called it the apple key because (at
least at some point) it had the apple logo on it, but it is also called
command, and maybe meta.

I'm perfectly okay with it being ignored. I don't use it in regular vim for
anything that I can think of. Does vim have any commands that use a "meta"
key?
On Oct 2, 2013 2:56 AM, "albertdev" notifications@github.com wrote:

@dhleong https://github.com/dhleong
Aha! Thanks a lot! You did forget to copy the "character" field, though I
can only guess that Eclipse fills it with "@".

It does seem the KeyCode is unique, and there is actually an SWT constant
for it: SWT.COMMAND, so the "Apple key" in your description was just a
red herring.

Now, what would you like to do with it? The easiest way going forward is
to simply ignore the Apple key, and any Eclipse shortcuts you trigger using
it will simply never invoke Vrapper. Is that OK for you?


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25516728
.

@keforbes
Copy link
Contributor

keforbes commented Oct 2, 2013

Personally, I think mapping it to Ctrl would be more useful. Mac basically uses the apple key the way windows uses the ctrl key. Also, back when I owned a Mac I remember the actual ctrl key on the apple keyboard was a lot smaller and harder to hit. That's just my two cents though, it's been years since I owned a Mac.

@dhleong
Copy link
Contributor Author

dhleong commented Oct 2, 2013

@keforbes It's true that it's basically like ctrl, but all the Macs I've
used recently have had comfortable ctrl keys that I use for different
things (ctrl+tab to flip between tabs, for example). Also, MacVim (the osx
equivalent of gvim) let's you use the apple key for stuff like apple+s to
save, which is the default behavior in eclipse (and everywhere else in the
os), so I'd rather it stay consistent with that.
On Oct 2, 2013 9:06 AM, "keforbes" notifications@github.com wrote:

Personally, I think mapping it to Ctrl would be more useful. Mac
basically uses the apple key the way windows uses the ctrl key. Also, back
when I owned a Mac I remember the actual ctrl key on the apple keyboard was
a lot smaller and harder to hit. That's just my two cents though, it's been
years since I owned a Mac.


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25536490
.

@keforbes
Copy link
Contributor

keforbes commented Oct 2, 2013

Sounds good to me, let's just ignore SWT.COMMAND.

@albertdev
Copy link
Member

@keforbes @dhleong
I think I know now why macro's were invoked: the character field of the VerifyEvent was actually set to \x00 (because it is a modifier key). The changes I implemented for Ctrl-keys translate the 0 character to "@" because that's the character that Ctrl-@ would normally have.

If we have any other problems where a key is interpreted as "@" in the future, we might have to look there...

For now I added the Command-key keyCode to the ignore list and pushed the change. We're now ready for a release candidate I guess?

@dhleong
Copy link
Contributor Author

dhleong commented Oct 2, 2013

Thanks!
On Oct 2, 2013 12:27 PM, "albertdev" notifications@github.com wrote:

@keforbes https://github.com/keforbes @dhleonghttps://github.com/dhleong
I think I know now why macro's were invoked: the character field of the
VerifyEvent was actually set to \x00 (because it is a modifier key). The
changes I implemented for Ctrl-keys translate the 0 character to "@"
because that's the character that Ctrl-@ would normally have.

If we have any other problems where a key is interpreted as "@" in the
future, we might have to look there...

For now I added the Command-key keyCode to the ignore list and pushed the
change. We're now ready for a release candidate I guess?


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25553453
.

@keforbes
Copy link
Contributor

keforbes commented Oct 3, 2013

I've updated the unstable update site with a new build (0.35.201310021) which includes this fix. And yes @albertdev , this would be a release candidate for 0.36.0.

@dhleong, please let us know if you have any issues with this fix. Thanks!

@dhleong
Copy link
Contributor Author

dhleong commented Oct 3, 2013

Apple key seem to be working again. Thanks!

I'll let you know if I run into other issues :)

On Wed, Oct 2, 2013 at 8:08 PM, keforbes notifications@github.com wrote:

I've updated the unstable update site with a new build (0.35.201310021)
which includes this fix. And yes @albertdev https://github.com/albertdev, this would be a release candidate for 0.36.0.

@dhleong https://github.com/dhleong, please let us know if you have any
issues with this fix. Thanks!


Reply to this email directly or view it on GitHubhttps://github.com//issues/310#issuecomment-25587841
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants