EDIT: thanks all for the feedback! Sorry there are not more levels, but if you check back in a week am adding a level editor!
but clicking on the hamburger menu it shows a link to “Motions”, which seems to be the first level/demo of the game
Which is to say, i'd love to see this in Helix. I also toy with custom editors, and observability of available commands is high priority for me, a generalized solution here would be an elegant solve for that. It would also adapt to new features nicely.
There are few minor things I don't agree as bad habits. For instance, Home/End should be allowed at least when you are in edit mode as they armonize with almost any other text input (not just editors, but also the text inputs/areas on websites).
For jumping around what's on screen, I think 'easymotion' ("jump anywhere on screen by pressing two characters") & variations are best in terms of how quickly they let you navigate for how easy it is to use.
To me, if my cursor is a few lines away from another line, the easiest way for me to get there is by either using h/j a few times, or looking at the absolute line number and doing that with gg.
Relative jumps are only useful to me in macros. Calculating a relative jump myself would 100% pull me out of the flow state where I just want to go up/down a few rows.
I have no proof of this, but I’d guess that the creator of this pattern didn’t feel the same way.
While I loved multi cursor with sublime. After I moved to Vim, I’ve never needed it. It’s either search~repeat or a macro. Now I’m using emacs, and it’s mostly occur-mode and macro. Grep edit is nice for bigger refactoring.
I tried evil mode, but it clashes with other keybinding in some places and I got unhappy with it. There's a philosophy conflict there. With vim, you're expected to have a command for an action and then bind it to a key. Your editing workflow is to compose those keys.
But with emacs, you're more expected to have a view and then a set of actions for that view. The power of emacs comes with how easy it is to integrate all those views together. For a programming workflow, you have the file explorer, the symbol explorer, the search result (single file and all files), the version control, the docs, the compilation|build window, the shell, the project tasks,... all together in the same place and linked to each other. With vim, you have to compose all those with a multiplexer and other tools (with conflicting bindings) to get there. Vim is still better for editing, but Emacs is better for workflows.
And yes, for a few lines it's fine, the plugin has this number configurable.
Over time, I started using things like 13dd or 7yy with more ease.
Of course, `set relativenumber` is always recommended.
> Calculating a relative jump myself would 100% pull me out of the flow state where I just want to go up/down a few rows.
Yeah, you can't be a purist about it. If you're hard-focused and jjjjj is the first thing that comes to mind, then that's fine. When you're doing lighter work is when you have the spare mental capacity to train and improve on your workflow.
Relative numbers are useful to save a few keystrokes. But in every other context, absolute numbers are what's relevant.
Or instead of 15j use another jump to command that accepts those letters as numbers
Or have some jump type of command that displays a-z labels 1 per row in the middle and you can jump without numbers and without shifting focus to the gutter
But yes, the most basic motion will still be more "intuitive"
First, you can hold down h or j and use visual clues to know when to stop. It's one keypress on the homerow, no reason to even glance at the keyboard. Eyes on the monitor = better focus. One keystroke.
Second, thinking in line numbers is one more piece of context to load up into your brain (find the line number), then act on (type out incantation), then context switch back to whatever you were doing before. By contrast, holding j until you're in the spot takes up almost zero working memory. You can think while it's happening! It's a small and subtle difference but that 200ms pause in thought process really does add up - not in wall time (jumping by line is probably "faster") but in contiguous focus time. Having to invoke any multi-part command is a distraction from your core work. Again, one lazy keystroke with immediate visual feedback > some complex combination of keystrokes.
An one small pitch for treesitter - rather than use j/k to navigate by line, set up some keybindings to jump by treesitter element (functions, methods, etc). I've got mine set to +/-. This lets you move in the same "dumb scrolling" way but by jumping to semantically-relevant parts automatically rather than line by line.
Sorry not meant to be a criticism. Maybe this is the last push for me to switch to using NeoVim.
I still keep vim configuration around but I've never felt the need for going back.
I switched few years ago, and the switch was instant.
Afaik Neovim is fully backward compatible, unless maybe for some obscure features.
'Built-in LSP' turned out to mean installing and configuring three pretty involved lua plugins at the time iirc. The experience really highlighted for me how un-seamless lua was in the project compared to vimscript. I found it to be a nightmare to configure and get used to. I came away wondering how it could possibly be such a pain, and baffled as to why it was claimed to be 'built-in' when getting ALE to work on vanilla vim took way less time, and felt way more in line with the rest of the program. Ironically it actually gave me an appreciation for vimscript that wasn't there before.
Eventually issues continued to kind of build up for me until I decided to just cut it. Everywhere I encountered lua felt crufty and difficult to work with, and those integrations made the concise, tight vim I'd gotten used to feel really nebulous and unweildy. I never quite got the treesitter syntax highlight to work correctly, and even when it did work having the highlighting dynamically change while typing frustrated me. I ended up slowly switching back to my old vim-compatible plugins one by one, until eventually I just went back to vim, since a lot of the neovim features that diverged from the original design philosophy bugged me and since I'd developed a strong aversion to anything involving lua in the program I wasn't getting anything out of using neovim.
However, this took way too long, and I've already deleted everything related to LSP and IDE-like features from kickstart, since I have IntelliJ for this, and I want to start fast. This might be totally missing the point of Neovim, so maybe I'm stubborn.
To be honest - mixed feelings. Everything works great after some effort, Telescope is cool, plugin ecosystem is amazing and active. But it is the small papercuts in the process that ruined the fun for me. It doesn't support 16-color terminals, so needs custom themes always. There is a Selenized theme available, but it fails to load as the main theme, I need to load another theme first and then reload that one, no idea why. Some of the colors don't load anyway (probably due to plugin load order), so I had to add an ugly `vim.defer_fn` to re-call highlights 1000ms after startup. What more, Telescope uses fzf for files but not for live grep, contrary how it works for Vim.
Also, there is a huge culture of not providing any keybinds by default, and instead configuring them manually, probably due to sheer amount of keyboard real estate already required by Vim, not to mention any of the LSP features or possible plugin conflicts. So many great plugins are useless with stock config (like blame.nvim) and really require forward thinking, how to put them under your keyboard.
I'll spend a few weeks there and see. Hopefully it gets better and better.
No way I am starting to count how many characters there are in front of my cursor just to have the satisfaction of typing "31-l"...
I am totally going to spam some 2w 3w llll until I reach the desired position.
https://stackoverflow.com/questions/12495442/what-do-the-f-a...
Example: d / foo, first foo will be highlighted, use CTRL-G to select the next one if not correct (repeat if necessary; CTRL-T cycles backwards), ENTER to delete until highlighted section.
Unfortunately CTRL-G is not implemented in IdeaVIM.
You don't have to. There are many ways to do a jump without counting. Some of the require plugins like flash.nvim, some do require pressing `;` multiple times
For numbers under 10, I usually hit the right amount. For numbers around 30, I might be off by one to five, but move on from then. When I want to remove similar prefixes from multiple non-consecutive lines, I might use things like 31x, go to the next instance (maybe continuing a search with n), and press period.
Honestly though, if you're moving forward 31 characters, there's often an easier approach, like 4w (move forward three Words). Again, at first I had to consciously think about which combination to use. Over time it becomes second nature.
I still use jjjj sometimes. It's imperfect, but at least it's the human that's the limiting factor, and not the software.
Moves to the top/bottom/middle of the viewport, and the. I'll jjjj/kkkk away! (or probably just search, mostly).
Thank you.
Once you get "near", then zeroing in on your target (eg: `fj`, `Fa` for "adjacent") can be the fastest/most accurate way to get to where you want to go.
Looks awesome, will not try!
This made the biggest difference, more than anything else. It forced me to use hjkl and never the arrow keys.
Everything else is a bonus that comes by itself later.
That's what hardtime solves.
By that, I mean the hjkl navigation keys are the first kind of navigation people want to do and are conveniently easily typed with the right hand in a traditional "home-row" position.
Next, very common editing commands are associated with home-row keys associated with the left hand; asd, with finding a character on the current line associated with f (and F for finding backward).
After those, other lesser used, but still very useful, commands are associated with the rows above and below the "home-row".
Finally, repeating any of these is bound to prefixed numbers, which are of course two rows above the "home-row" on a QWERTY keyboard.
Modifiers such as Shift, Ctrl, and others are approximately the same distance as the numeric row, unless one binds CapsLock to be Ctrl on most modern keyboards (note that Sun's keyboard got it right and had Ctrl in the position most keyboards now have CapsLock).
Interestingly enough, learning vim can often times follow the above distances from hjkl with great result.
To me, WASD for avatar movement makes sense even in the context of "right-handed bias" in that if a gamer is using a mouse, odds are they are right-handed and the mouse is positioned to the right of their keyboard.
And if a gamer is left handed, it's a minor inconvenience to shift the chair position such that their right hand manipulates WASD and their dominant left hand uses a mouse on the left side of their keyboard.
Of course, many modern games allow custom key bindings, so a left-handed gamer could use IJKL instead of WASD if they so chose.
alabhyajindal•1mo ago