[SOLVED] Cursor should not be there always with selections on macOS


#1

I do not know how this works on Windows. I do no remember how it works on Linux Gnome or KDE or other windowing environments. However, on macOS, when you select text, the cursor disappears.
This is because the cursor represents a range of text that has a position but a length of zero.
A non-zero length means a selection and then it means there is no cursor displayed.
A disjointed multiple selection works the same way.
I know TextMate and Sublime do this right, but in Atom this is very awkward.

It how can we make this behave properly?


#2

Disable the “Show Cursor on Selection” option in Settings -> Editor.


#3

Perfect! Thank you so much. I hope this helps the next person to locate the same solution.


#4

Atom doesn’t use any platform-based GUI frameworks, so it doesn’t fully behave like the native applications of any system.


#5

I would like to believe that, but it’s actually slightly specious.
It uses Electron, which uses Chromium, which on macOS does use the Cocoa text system on some level, it is not actually avoidable, though it does allow you to customize and override its behavior like crazy.

In other words, there’s literally no way that it doesn’t use what is part of each platform, even if it doesn’t have direct API exposure, it has to interact with it on some level in order to interop so well. (see Java GUI apps for examples of broken interop at that level, while Qt is really quite good, but not perfect at it).


#6

Atom doesn’t use any GUI frameworks to render text. That all happens via HTML/CSS/JS.

Atom is not designed like a native application for any operating system, and therefore it is not appropriate to apply expectations from any one operating system. Atom does what it does because the developers wanted it that way, not because of a system library. If you believe that a change in Atom’s functionality would be beneficial for its users, it would be most appropriate to make an argument for why you believe a feature change would benefit all users, rather than focusing on a specific GUI toolkit.


#7

Is it really not designed to behave like a native application?
If so, why bother having any native window or menubar interaction?
I am not just splitting hairs, the hooks into the native system provided facilities are there in WebKit, in Chromium, in Electron. On some level, not everything of course.

But one must acknowledge that in a GUI it is really reasonable to expect behaviors that are common to any given platform on which it is running.
Otherwise you end up with Eclipse, Vim and Emacs. All are great tools but some of their learning curve and idiosyncracies are derived from their platform inconsistencies.

In the case of a cursor remaining displayed while text is selected, I would challenge you to show me where that is a normal and expected UI behavior on any OS.


#8

It doesn’t have to, and I could build a fork of Atom without a native menubar if I wanted to.

But one must acknowledge that in a GUI it is really reasonable to expect behaviors that are common to any given platform on which it is running.
Otherwise you end up with Eclipse, Vim and Emacs.

People use Eclipse, Vim, and Emacs religiously. There are editors for every OS that are customized to that OS, and there are editors that don’t look and feel like any OS. I like that my experience in Atom is roughly the same across different operating systems.

In the case of a cursor remaining displayed while text is selected, I would challenge you to show me where that is a normal and expected UI behavior on any OS.

If you’re not beholden to resemble any OS, it shouldn’t be a problem if you resemble no OS at all.


#9

Yes you could fork Atom with no native menubar, and you’d have a terrible app on most platforms.

Denial of platform UX/UI conventions just because is not really productive, but rather counterproductive for the users and the app.

Indeed not beholden to, but unless the deltas are really better, you end up increasing cognitive dissonance in users without a return for it.
Although Vim and Emacs are indeed fabulous, they are so in spite of the given platform they run on. Emacs because it truly outdates them all. Eclipse suffers a lot from the same issues in the Java way of being built under AWT and Swing in spite of resulting in a substandard UX much of the time.
Atom has a lot of that due to its Electron roots, but generally does overcome it. Real stinkers are usually around keyboard shortcut soup. Shortcuts are kind of subtly very hard to come up with good ones, but good ones tend to be platform consistent. That’s a similar spot where Emacs and Vim fall over. Mac users learn keyboard shortcuts more than most and the control key would be last if the fn wasn’t there. Emacs keys are based on Lisp machines’ keyboards, whose key layouts resembled the modifier key layout on US English Mac layouts. Classic Emacs shortcuts on modern machines is pretty brutal in many cases.
But if you need to use Vim/vi or Emacs on multiple platforms frequently, because they’re often there by default, you learn and roll with the defaults.

Vim has a notoriously large learning curve, often worse than Emacs due to the utter sea of complexity.

Eclipse, for what it’s worth does try hard to be platform consistent within the confines of what its frameworks would let. Cross platform tools and frameworks often do miss little things that matter. I have filed many bugs for them. JetBrains fixes a lot of what’s wrong there, but not when it is AWT/Swing at fault.

Tcl/Tk although it ships with Macs and always has, is more like a looks-like than an acts like.

Qt probably does the best of crossplatform frameworks to work fairly natively everywhere, but still feels odd much of the time.

You see, these issues, they’re fundamentally what’s wrong with most of the web. It is improving but only thanks to major investment in UI frameworks.