VimGraph
resources.wolframcloud.com
resources.wolframcloud.com
(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).
A shout out to quick-scope (https://github.com/unblevable/quick-scope) possibly the best named vim plugin.
Forgive my ignorance!
I've been trying that with smaller models and had to make some adjustments (e.g. they all really wanted to include the filename twice). So I just make a small tweak and bam suddenly I can edit code with small fast cheap models.
In short, it's developing in the wrong direction.
I switched from Mathematica to Matlab in my work; it was the best investment of time in the entire project
``` Here is a 35 keystrokes solution that beat your 36 keystrokes solution ! <89 keystrokes> ```
And then it keeps looping in the same way if you ask it about the seahorse emoji (or sometimes just lie about the keystrokes number).
In fact that's not surprising, what is rather surprising is that some of the solutions actually work (>= 100 keystrokes)
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).
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.
I've been using { and } more as well. Mostly to navigate paragraphs of prose, but sometimes for code too.
When I experimented with scrolling, I found it hard not to lose understanding where I just scrolled from. What helped immensely was defining a top and bottom margin and using vim-smoothie.
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.
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.
If you expand the "Scope" section you'll see more examples. The reason the initial example is restricted is probably because of how noisy those other graphs are when all (or more) movement commands are available. They make poor initial examples.
Conveying information through images is all about making something understood, not about graph completeness.
I'd love to see a comparison between Vim and Kakoune or Helix.