Number of active selections?


Is there no way to have Atom display the number of actives selections? Such as when you select a word and invoke “find all matches”?

In Sublime it mentions that I have 5 selection areas, so I matched the selection 5 times. It’s useful to know, in case the number is way higher or lower than you expected… it prevents user errors.


I don’t know of one, but it sounds like an interesting idea for a package.


I would be glad to contribute to this and so write my first atom package :smiley: I’m putting myself on work right now…


Sorry to bother, but may I ask what’s the expected behavior when no selection is present (i.e. only 1 cursor with a selection of length 0)? Is it preferable to hide the status or display “No selection regions”?
Also, are cursors to be considered selections as well? If not, are they to be listed separately or just ignored?


I vote for hiding it to avoid clutter. Also make sure the display of the number and any text is tiny. My status bar is often out of space. Maybe just “S3” or something?


I agree, hide it


Maybe I could insert some kind of customizability in the Settings pane, so that you could insert something like “S%n” if you prefer, while someone else might like “%n selections”…


I finished the prototype for this package, I would greatly appreciate if someone could test it, provide some feedback… and explain me how to write specs for such a package :grin:
I am not yet publishing it because I want to write specs for it first.


I like it! :smile: I especially love the configurable string! Brilliant!

A few minor things though:

  • It shows the length of the selection inside parentheses right before the cursor/selection counter. It’s a little confusing because it doesn’t tell me it’s the selection length, and it only shows the length of the last selection. Maybe you could also let the user configure the string that’s shown. Also, I don’t really care for the length most of the time, so I would like to disable it. Disregard this, I assumed it was your package doing this, but apparently it’s not.
  • The selection-counter-status element isn’t hidden when it’s empty.
  • It doesn’t show the cursor count when there are no selections. Shouldn’t it be showing
    cursors: %c, selections: 0
  • It counts a selection as both a cursor and a selection. Maybe subtract the number of selections from the number of cursors shown in the status bar?
  • I think a human-readable default for the string (something like cursors: %c, selections: %s) would be better.
  • It would be nice if the cursor counter and the selection counter were separate elements. That way the spacing between them would be consistent with the spacing between other elements in the status bar.


Thanks for the feedback! I’m gonna address your observations as soon as I get access to my workstation!


I tried to address most of your requests. I updated the repository, so you should be able to notice the changes by pulling.
I deliberately kept the two countings as one element not to overdo the implementation, I really wanted to keep this first release simple. As for hiding the element, I set the display to none when no string is to be shown… Hope this to be suffcient! As for the specs, do you think they would be superfluous for such a package?


Awesome, it works great! Yeah, the separate counter elements is just nitpickery :stuck_out_tongue: but it’s something I would like

As for specs, it’s always nice to have them, and I think a package like this should be easily testable using the TextEditor::addSelectionForBufferRange API. I’ve never written a spec for a package myself though, and I’m fine that way (though I keep planning to do it sometime).


Ok, great! I’m releasing it to apm, then! Maybe the separate elements could be added in some update… Thanks for the help guys!


I’d highly recommend learning to write specs for your packages. Here’s what things look like without specs:

  1. You make a change to your code
  2. You load Atom with the dev version of your code
  3. You fiddle around with the package to see that everything seems right (2-30 minutes depending on the size of the change and your thoroughness)
  4. You cross your fingers and publish

Here’s how things look once you’ve gotten proficient in writing tests:

  1. You write some tests
  2. You make a change to your code
  3. You execute apm test (5 seconds to a couple minutes depending on the size of your package)
  4. You publish, secure in the knowledge that you didn’t miss anything

Here’s the list of tests I have for my soft-wrap-indicator package, which I suspect is comparable in size to what you’re building:

  • it ‘has the text “Wrap”’
  • it ‘hides the indicator when there is no open editor’
  • it ‘shows the indicator’
  • it ‘is not lit when the grammar is not soft wrapped’
  • it ‘is lit when the grammar is soft wrapped’
  • it ‘is lit when the soft wrap setting is changed’
  • it ‘is lit when the grammar is changed to a soft wrapped grammar’
  • it ‘toggles the soft wrap value’
  • it ‘removes the indicator’

It takes 1.5 seconds to run them. To do even these nine tests manually would take at least a few minutes, if I remembered them all. But here’s the list of 28 tests I have for a slightly more complex package, tabs-to-spaces:

  • it ‘creates the commands’
  • it ‘destroys the commands’
  • it ‘does not change an empty file’
  • it ‘does not change spaces at the end of a line’
  • it ‘does not change spaces in the middle of a line’
  • it ‘converts one tab worth of spaces to a tab’
  • it ‘converts almost two tabs worth of spaces to one tab and some spaces’
  • it ‘changes multiple lines of leading spaces to tabs’
  • it ‘leaves successive newlines alone’
  • it ‘changes mixed spaces and tabs to uniform whitespace’
  • it ‘does not change an empty file’
  • it ‘does not change tabs at the end of a string’
  • it ‘does not change tabs in the middle of a string’
  • it ‘changes one tab to the correct number of spaces’
  • it ‘changes two tabs to the correct number of spaces’
  • it ‘changes multiple lines of leading tabs to spaces’
  • it ‘changes mixed spaces and tabs to uniform whitespace’
  • it ‘does not change an empty file’
  • it ‘does change tabs at the end of a string’
  • it ‘does change tabs in the middle of a string’
  • it ‘changes one tab to the correct number of spaces’
  • it ‘changes two tabs to the correct number of spaces’
  • it ‘changes multiple lines of leading tabs to spaces’
  • it ‘changes mixed spaces and tabs to uniform whitespace’
  • it ‘will untabify before an editor saves a buffer’
  • it ‘will tabify before an editor saves a buffer’
  • it ‘respects the overridden configuration’
  • it ‘does not modify the contents of the user configuration file’

This is the test set for 138 lines of code (including comments). It takes about 2.7 seconds to run them. I don’t know how long it would take to run them manually, but it is more than a couple minutes for certain. And I’m pretty sure I’d find excuses to not do them all, opening me up for missing something and having to issue a patch release, maybe even more than one (though I suppose that would significantly boost my download numbers :laughing:).

Yes, there is a learning curve to writing tests … but it saves you lots of time and some stress in the long run.

Mocking required dependencies for testing

Awesome insights on your experience, thanks! Unfortunately I had already published the package when I read your message, but I will start to write specs as soon as possible.

Btw, cool use of CSS with your soft-wrap-indicator :smiley:


This is quite the powerful list!

So far, my excuse for being lazy with unit tests is that I’m not sure that the whole thing will work if the unit test works. But then when I think about unit tests, I think about a huge software I’m writing at work where adding a unit test feels like a drop in the ocean. Thank you for yanking me out of this mindset.


You’re both welcome! If anyone ever needs help trying to figure out the right way to test something or the right set of tests to cover a feature, let me know. I’m happy to help out :grinning:


Wow! I ask a question Friday, and before Monday someone has added the feature by way of a package! This is the reason Atom is a great tool, it’s such a great community.

Thanks, @frabert


I don’t see how you can trust your tests so much that you don’t even have to try it as a user before publishing.


Yes, both lists are a simplification of the process for the sake of not boring people. The point being that all the verification of the things you think you didn’t change are left to the tests.