Esc for backing out of a file, into search field
Completed
Hi,
I'd like the behaviour of the esc-button in nvALT which backed out of a file and closed it, ending up in the search field ready for a new search.
That behaviour made it feel you "closed" a file, written it to disk and then ready for a new search.
-
At the risk of firing off a mindless "me too!", I have to say that muscle memory constantly moves my left pinky over to my (remapped) ESC key whenever I finish or am done with a note. I wouldn't be upset if this never made it into nvUltra, but I wouldn't be upset if it did, either.
0 -
Oh gosh yes! This is a behavior I would *love* to see ported over from nvALT. It feels so *natural* to me now.
0 -
Yeah, it's still in my muscle memory too. The reason it hasn't been implemented at this point is the extensive work we've done on autocomplete (triggered by escape when the editor is focused). That's also triggered by F5, so it's feasible that the escape key could still move focus. We'll take in under consideration.
0 -
Well, count me as an enthusiastic vote in favor of that. ;)
0 -
Escape can now optionally be mapped to autocomplete or to moving focus back to search.
0 -
Yay!! Thanks!
0 -
> Escape can now optionally be mapped to autocomplete or to moving focus back to search.
Exactly what I was looking for! I can't seem to find the option, where is it?
0 -
It was only added 5 days ago, and there hasn't been a new release since then. It will be in the next update.
1 -
I don't like the way ESC is working.
I reflexively press ESC a lot, and it's not fun when I lose my current text window for typing.
Command + L brings me back to search, but I'm not expecting to close a document when I press ESC.
That's not intuitive behavior and I believe it should be disabled by default.
I have to jump through hoops to reopen the file, scroll down to my last position, and start were I was just working.It's frustrating.
I'm not sure I like autocomplete either. I'd like ESC not to clear out my current file when I type it with muscle memory from working in Xcode all day.0 -
I'd be curious to hear more users weigh in on this. The current behavior is based on the way that most people are used to Notational Velocity/nvALT working, which is a more likely analog than Xcode. But I'd like nvUltra to appeal to a broader base than just former nvALT users, so I'm curious about this.
What _is_ expected behavior for you when you press escape in the two different scopes (search bar, edit window)?
0 -
I came across this feedback thread because I came to the forum today to report this behaviour has a bug. :) For myself, it is certainly unexpected for the Esc key, within a text editing context, to close out the file and wipe out the search field, leaving one perhaps with no easy way back to where they were (considering non-default sort orders). So at the very least, I think *that* particular problem needs to be addressed one way or another---perhaps Esc merely moves the focus to the search field but leaves the text selected, so in other words it becomes a synonym for `⌘L`. nvAlt users can retain their reflex with minimal adaptation, and meanwhile those that reflexively hit Esc in a text editing context for whatever reason aren't faced with a loss of their workflow every time they do it.As for why one might press Esc in a text editor, off the top of my head:
* It is one way of backing out of an auto-completion.
* It is how you close the Find panel (actually that is the first way I stumbled across this, I thought the focus was in it, but it wasn't), and in some programs it is how you close the Find panel even when the focus *isn't* in it. So that's an expectation problem there.
* (There may be other examples along these lines.)
* In some programs it is a way of *triggering* auto-completion, making the cancellation aspect symmetrical. A few years back that was even a system-wide behaviour for doing so (thankfully Apple changed that as having a system-wide auto-complete shortcut for Esc had many of the same problems this behaviour has: it's too aggressive of an assumption; I had issues with it for many of these same reasons). Either way, it's probably left some people with a reflex even if it doesn't do anything without a modifier in most programs, these days.
* As with Paul Solt, for some of us hitting Esc is just an anonymous reflex (maybe it comes from decades of using Vim, in my case), I sometimes just hit Esc when I'm done typing and want to read. It's probably compounded by the fact that I duplicate Esc down to the Caps Lock key as well---I use it that much. It's how I close dialogue boxes in a cancel condition, etc.
* And on the vein: in *most* cases the Esc key doesn't disrupt or hurt anything, it's very often the *safe* button to press. If you cancel a dialogue with it for example, at most you just have to start initiating the process you started again.So that's some of the problems of expectation that I can think of. To solutions, again maybe it's as simple as making it work like `⌘L`. Another approach would be to add this as a menu command so that it can be rebound for those that do not like it. E.g. I might use `⌘⌥L` because that is a logical alternative behaviour.
1 -
AmberV makes fair points. I would be in favor of having ESC behave like ⌘L when in the text editor, as once it's in the search field it will clear the selection, meaning completely clearing out of a note is just two escapes instead of one (and returning to previous edit point is just a matter of hitting return instead of another escape).
I would also reiterate that enabling Map Escape Key to Autocompletion under Pro settings changes the behavior to match that of the former system-wide autocomplete escape binding, while still maintaining its behavior in the file list and search fields.
0 -
Done.
0
Please sign in to leave a comment.
Comments
13 comments