This would be a bit easier to understand had the example used text that was unrelated to vim itself.
(seems to occur quite often with tutorials/documentation where the author has the topic they're showcasing top of mind, and naturally, but unnecessarily, uses the topic itself in examples, making it confusing for new readers to distinguish concept from arbitrary example)
For anyone wondering what's going on, "How do I\nexit vim?" is completely arbitrary text. This VimGraph function accepts this (or any other) text as an input, and shows the keys you could press to get from one place in the text to another using vim. The example limits the keys to just three (k, l, and w) presumably to not let things get too cluttered. (there's a curious 'crown' shaped key, which I suspect is a rendering bug where a 'w' and 'l' have been placed on top of one another).
I believe that's mostly for fun. Coding agents wouldn't need to interact via the same interfaces humans use, they'd be given a tool to read and write files and they'd be fine with that.
I'm curious about something a bit different. Given a vim buffer, and picking two caret locations in it, I'd like a tool that shows only the paths to getting there with my current Vim setup (including all the plugins).
After 10 years of using vim, I rarely use L and H. For horizontal moving it's almost always F or S (vim-sneak).
More often than L and H, I use { and }, which jumps across paragraphs (i.e. blocks of lines separated by blank lines).
I've found that most of my code consists of 3-5 line blocks, and { and } feel like a nice medium-range navigation tool, because oftentimes CTRL+D jumps too far.
The downside is that both of these jumps go into the jump table, so they will clutter your CTRL+O history a bit.
This post has many upvotes, but all the comments ask questions about the usefulness of this, without any justifying response so far. I have the same question, and I wonder what's going on with this post?
I'd like to submit this has no practicality from a Vim tutorial perspective. However, from the perspective of anyone wanting to learn about graph theory and who understands the concepts of typing efficiency incorporated in Vim key movements, this could be very interesting.
Kind of like many other things using Wolfram - a personal notebook that someone found interesting or useful, take it or leave it.
Analyzing the typing experience in vim by looking at pure keystrokes would be a mistake if you don't understand the tradeoffs and benefits of having a modal system and operating the editor without leaving the home row or needing a mouse.
Good remappings/config would also significantly alter your experience.
In the example, why would you even move with single chars and not words or to the end of line? I think it's definitely a poor example because the point of the diagram/investigation is not clearly described.
I can see value in this. I use which-key already and could see a graph, al be it a differently arranged graph, being a useful visual aid. Perhaps a static (printed?) Cheat-sheet or even a dynamically generated visual - though not sure how effective it would be in a TUI :)
> Illustrates the relationship between the maximum keystroke distance required to navigate between two letters in a text and the number of randomly inserted newlines:
I'd love to see a comparison between Vim and Kakoune or Helix.
nomilk|3 months ago
(seems to occur quite often with tutorials/documentation where the author has the topic they're showcasing top of mind, and naturally, but unnecessarily, uses the topic itself in examples, making it confusing for new readers to distinguish concept from arbitrary example)
For anyone wondering what's going on, "How do I\nexit vim?" is completely arbitrary text. This VimGraph function accepts this (or any other) text as an input, and shows the keys you could press to get from one place in the text to another using vim. The example limits the keys to just three (k, l, and w) presumably to not let things get too cluttered. (there's a curious 'crown' shaped key, which I suspect is a rendering bug where a 'w' and 'l' have been placed on top of one another).
fragmede|3 months ago
samlinnfer|3 months ago
A shout out to quick-scope (https://github.com/unblevable/quick-scope) possibly the best named vim plugin.
thornton|4 months ago
Forgive my ignorance!
qsort|4 months ago
tantalor|3 months ago
utopiah|4 months ago
mastermedo|3 months ago
I'm curious about something a bit different. Given a vim buffer, and picking two caret locations in it, I'd like a tool that shows only the paths to getting there with my current Vim setup (including all the plugins).
After 10 years of using vim, I rarely use L and H. For horizontal moving it's almost always F or S (vim-sneak).
busfahrer|3 months ago
I've found that most of my code consists of 3-5 line blocks, and { and } feel like a nice medium-range navigation tool, because oftentimes CTRL+D jumps too far.
The downside is that both of these jumps go into the jump table, so they will clutter your CTRL+O history a bit.
But I think I'm weird in this regard.
ctenb|3 months ago
jiehong|3 months ago
uticus|3 months ago
I'd like to submit this has no practicality from a Vim tutorial perspective. However, from the perspective of anyone wanting to learn about graph theory and who understands the concepts of typing efficiency incorporated in Vim key movements, this could be very interesting.
Kind of like many other things using Wolfram - a personal notebook that someone found interesting or useful, take it or leave it.
isaacremuant|3 months ago
Good remappings/config would also significantly alter your experience.
In the example, why would you even move with single chars and not words or to the end of line? I think it's definitely a poor example because the point of the diagram/investigation is not clearly described.
NoSalt|3 months ago
Jenk|3 months ago
uticus|3 months ago
I'd love to see a comparison between Vim and Kakoune or Helix.
pona-a|3 months ago
stogot|3 months ago
sheerun|3 months ago
foofoo12|3 months ago
jgoode19|3 months ago
[deleted]