Cannot capture core:move-to-top


#1

I have a home-made read-only editor that inherits ScrollView. It is very simple, just a tall div inside a scroll div. It scrolls fine with the scrollbar or mouse wheel.

I have a scrollToTop method overriding the ScrollView one and it doesn’t get called from a ctrl-home keypress. The binding resolver shows the core:move-to-top event with a grayed-out x.

Since the resolver showed a context of .workspace .editor I tried giving my view a class of editor. This matches a normal source file sibling view (which does get the keypress). The resolver still shows the gray x. I also tried putting in an event handler in my activate method with no luck.

atom.workspaceView.command "core:move-to-top", => fileScroll.scrollToTop()

I suspect that somehow my view cant be a context for keypress events even though I can select it with a tab or simple click just like any other editor.

Is there any way to tell which views can be contexts for events and which can’t?


Git Log package: Graphs your commits
#2

I can’t get any key binding to work with my view. I added my own binding to replace the core binding and both are grayed out. I made sure mine was more specific but I could tell from the resolver that wasn’t the problem. My code now matches the a test package from the Package Generator which works.

When the key binding manager (or whatever it is called) looks for a context to match for a key, how does it find it? The key is actually bound to a little invisible input box so it can’t use the normal event scheme. Is there some way for me to find out what context is active when a key is pressed? It would be really nice to show the current context in the resolver dialog.

I guess I’ll start reading the core code to try and understand this. Happy Joy Joy.


#3

Have you taken a look at this topic that speaks about specifically this kind of problem?


#4

Thanks. That explained the need for the html attribute tabindex to make a div accept keypresses. This was a surprise to me because I had no idea a div could do that. So now keypresses work in my “editor”.

Tabindex also fixed my being able to accept the core:move-to-top command. I had to put the class editor on my view but that is kind of logical since I am a kind if editor. Now if a user overrides the ctrl-home key in the real editor it will also override mine. I don’t even need anything in my keymaps cson file.

Unfortunately using the class editor broke a lot of other code aimed at real editors but I am hopeful I can fix those.


#5

You are not only a robot but you seem to have an encyclopedia of posts in your brain. How do you find these posts? You’ve found ones I spent a lot of time searching for.


#6

I prefer @batjko’s answer:

:wink:

But to be serious, a lot of times I remember some turn of phrase or who posted what I’m looking for. So I do the most appropriate of the following:

  • Use the Search icon to search for the phrase I remember
  • Use the Search icon to search for the phrase plus additional keywords
  • Find the person’s profile who posted what I’m looking for, then use the Search icon there to search just their posts (which is how I found @batjko’s snarky post :laughing: I searched his history for “web server”)

Plus, I have a really good memory for certain kinds of things … specifically things I read.

But @batjko’s answer is still more fun :grinning:


#7

For accuracy I should mention that adding editor to my view was totally unnecessary and I recommend that others not do it. To my surprise just adding tabindex="-1" caused all the scroll navigation keys to work on my view. Apparently the ScrollView class I inherited started working when tabindex was added. I now have no code at all to handle any commands and it just works. So tabindex is the magic bullet that fixes everything.

A strange aside …

When I press ctrl-home in a normal editor I get the green check mark in the resolver. This makes sense since the context for that key is .workspace .editor. But when ctrl-home is used in my editor the resolver shows a gray x, even though the key works. I assume this is gray because my view doesn’t have the class editor and is not in the .workspace .editor context. So the key shouldn’t be working at all! This tells me that ScrollView is cheating somehow and not using the keybinding resolver facility. Shame shame on whomever coded it.


#8

Don’t forget that there is also the .native-key-bindings class that would make Ctrl+Home (among other keys) work.


#9

I have a horrible memory. I had forgotten all about native-key-bindings. I had also forgotten that tabindex was mentioned in the post you linked.

In any case, native-key-bindings doesn’t seem to change anything. The resolver still shows the keys as gray even though they work.

Mind you, I’m not complaining. Everything works great now.


#10

I was actually just suggesting that there is probably some code in ScrollView that acts as native-key-bindings does as an explanation for why the key works without .workspace .editor applying. I mean, it does scroll views after all :grinning:


#11

Oh yes, when I was young I also thought that. There must be code in ScrollView, I thought. So there I was, young and optimistic, and I git cloned the source code and I opened it and I searched and

and

Hm.