Test for textEditor visible?


#1

For some reason I’m having a problem finding the answer to what should be pretty simple.

I just need to test if a textEditor is visible to the user.

For example.

  1. I have one Pane with 2 tabs open.
  2. I iterate on .observeTextEditor (editor) ->
  3. I need to check if the editor is behind or on top.

Previously I just used editorView.hidden (worked like a charm).


#2

If an editor isn’t visible to the user, it has display: none; set on the atom-text-editor element, so you could check for that. It would look something like:

atom.views.getView(editor).style.display isnt 'none'

#3

How about:

editor is atom.workspace.getActiveTextEditor()

I guess that wouldn’t work in a multi-pane setup, but almost every problem like this I’ve seen really just wanted to know that the user was actually in that editor.


#4

Well, that’s much more elegant. My solution has the same problem as @leedohm’s, so I’d say go with his


#5

Unfortunately for Jumpy, I need to get the info on all that are visible, I can jump many panes.


#6

Ok, so given this … I would probably use atom.workspace.observePanes to subscribe to the open panes and then pane.onDidChangeActiveItem to keep track of the active item in each pane if it is an editor. (Assuming that there is an active item per pane, not one active item across all panes.)


#7

I don’t see why @olmokramer’s solution wouldn’t work. There is also

atom.views.getView(editor).is ':visible'

#8

Wait, yeah, I think I misunderstood the problem with @leedohm’s approach. It should work just fine.


#9

Thanks so much guys @mark_hahn’s worked. So then I ended up going with @olmokramer’s. Test passes + feature works. Thanks. Display:none stuff was my first attempt, but I probably goofed it somehow (probably a few things). Glad it is so relatively easy.

Final line I went with:

return if editorView.style.display is 'none'

#10

A quick reminder on how :hidden and :visible works in jQuery. The hidden check is implemented with the following snippet:

element.offsetWidth is 0 and element.offsetHeight is 0

Then the visible check is just done with not hidden.


#11

@abe, Thanks.

BTW, Are there still plans to get off of jQuery?

That’s kind of why I went with .style.


#12

@DavidLGoldberg I think a lot of things was moved off jQuery, text editor, workspace, tabs, etc. Myself, I’ve updated the minimap and my color highlight package to take advantage of the model/view provider mechanism now available in Atom, so yes things are moving toward a no-jQuery world.

BTW, I take the opportunity offered by this discussion to point to my small libs atom-utils where I’ve just added a events delegation mixin that provides the same mechanism as jQuery.on wen called with a selector, but with a native implementation and the use of disposable.

I would like to extend this lib with other useful mixin/helpers for atom (maybe some visibility helpers for DOM element for instance), so if anyone have a specific need, some tricks to share, it’ll be a good thing we start aggregating all the ideas/concerns so that everyone doesn’t need to reinvent the wheel.


#13

@abe, how does your events delegation mixin differ from event-kit's Emitter?


#14

There were plans to get rid of space-pen and jQuery but I made a big stink (and kind of made a fool of myself) and they changed their minds. They will continue to support space-pen.


#15

@joefitzgerald It doesn’t really differ, it’s mostly for heavy views, or react views where either the amount of nodes and interactions, or the uncertainty of the DOM structure make it hard to handle all the listeners.
It’s a mixin that provides a subscription method that will perform the same tasks than jQuery delegation was doing, listening on a single node events and perform a comparison of the target with the defined selectors.

@mark_hahn Sure, and I’m still gonna use it for small views and quick prototyping. I remember seeing the discussion on github, I think it’s a good thing to keep it available as a starter for beginners. Even if it can lead to a lot of disasters. It’s also a good way to get fresh new ideas poping up as packages in the near future.


#16

Really? I know shadowing improves encapsulation but what disasters are you referring to?


#17

Personally, I want to get Jumpy off space-pen when I get a chance.

Not really using much from it. Never really did. Definitely leaned a little closer to the DOM, then some other packages.

The new api is pretty good. Shadow makes it a little harder to take some shortcuts I was doing, but safer if and when you need to I think.

I want to see how performance changes when I start using markers/decorators also should be fine (I hope!)

Is there a guide somewhere about how to extend decorators? I know with polymer we can extend elements.


#18

I think the first big disaster is performances. jQuery do a really good job making DOM manipulations consistent across platforms. But in this context, all the extra cost coming with all the compatibility layers is just not tolerable.
And it comes with a lot of idioms that we fight on the web for years now, like using a $(selector) expression without caching the resulting object when the DOM doesn’t change, relying on offset, width and outerWidth methods that do a lot of DOM and styles read or relying on non-standard selector like :visible, etc.
The other possible disaster I see comes from memory and event listeners, jQuery is not really fitted for heavily interactive UIs, and the fact that they already had to patch the ::on method in space-pen is telling.


#19

Yes, most of your comments are about performance. Let me repeat some of what I said in my old argument.

I’ve developed 16 packages. Most of them have views that consist of a few divs in a panel. And that panel is rendered only when the user enters a command. So performance is a non-issue. Forcing small-package developers and casual hacker users to learn a new, more complex way to do everything makes no sense.

I don’t want to lose the outlet feature. I don’t want to lose the awesome html rendering using the simple @div syntax.

Note that the new package-generator sample is useless as a starting template for a package. The old space-pen based sample was very usable. This is a big step backwards towards enticing newbies to contribute.


#20

As I already said, I’m not for dropping space-pen from Atom, it still has a use for beginners and small views that doesn’t have a big impact on performances. But OTOH I understand why they moved core views off jQuery, and I have found myself doing the same kind of move without feeling much pain at doing so.