vim_racer

Relative line numbers are finally configurable through the settings icon now

Just a note, I've looked into this a bit more and it's technically possible. It would just require some redundancy and extra logic to keep everything in sync.

The donate feature has a goal now to replace dynamo db with a sql db because it will make development and maintenance easier.

Just wanted to mention that I've made those settings configurable now, and it'll default to the normal vim line numbers. Feedback shifted this one up the priority list!

Ideally, I could fix the mousing clicking and add targets that you need to delete.

I'm actually curious who would win that race. Because you're right; mouse users have a huge advantage right now, but no one just clicks on code haha!

I think adding the ability to order by different columns would be good.

I'm actually not 100% sure if I can achieve that with dynamo db and my current data structure though. It has a great free tier, but the query language and limitations are very foreign to me.

If I wanted to sort by timeTaken, I had to set it to be one of the two keys. This also has the unfortunate consequence of blocking duplicate times.

It might just be my implementation that is strange, or the dynamo is significantly less featureful than an SQL server.

Oh that's a huge find thank you. I wasn't sure what was missing.

I think I'm working off a white list, so I should just be able to add that to it.

Oh that's a great suggestion! I was adding a bit to the description, but I should provide an example too.

There are some things that make the fake scores really obvious.

It's going to be a challenge to protect the leaderboard against fake scores. There weren't a whole lot of them before, but it's starting to increase as the site grows.

Another variation on that is relative in both modes, but my current cursor line has the absolute. That's what I tend to roll with!

Thats a good point! I'll have a better description by the next release.

I'm conflicted about keypress count because I really want the focus to be about speed. VimGolf does a great job of covering those types of puzzles/scenarios. The differentiator here is speed. I'm hoping that I'll be able to do some sort of data analysis on key strokes. An interesting finding might be that www is faster than f<a character>.

One of my hypothesis was that searching with 'f' and 'F' is not as efficient as simply navigating with more commong motions like w, e, h, j etc. I've already been proved wrong, Although, I should phrase it like "many top performers use 'f' and 'F'." Which would suggest that they might be fast, or using them isn't too much of a detriment

Sorry about that! Something seems to be broken with my publishing pipelines. It used to be a graceful switch. Now I have to manually invalidate a cache. Seems to only happen on some publishes.

I'll make the line numbers absolute by default soon.

It's just a shallowish vim, so there's mostly only key bindings. I'd like to support more in the future though.

I think the library just has key bindings, so it wouldn't even have a vimrc.

The library seems great at the time, but I might need to look into alternatives in the future.

Another user mentioned this too. I'll be adding settings to let users turn relative lines off.

I might just have to add a :q easter egg some day.

Are there any other configurations that people want to have? I can try to do a number of them manually.

I've got this feedback quite a few times, so I'm going to bump configurations up on the roadmap. I think proper vimrc configs might be impossible unless I swap out some of my libraries.

I should provide the ability to disable relative lines though

Hmmm, thats interesting. Right now it just shows every character press, regardless of what it was to achieve.

You'd be interested in something a bit more organized, so you can see how they got specifically from one target to the next. I do have a ton on the roadmap right now, but that has been added as well!

That has been a tough bug to fix. From a configuration standpoint, deleting should be impossible. The VIM keybindings library seems to override that.

I do really appreciate you mentioning it though because it helps in prioritization.

I've heard that feedback before, but I couldn't quite understand what was wrong. I'd really appreciate your help in troubleshooting.

My understanding is that Shift + G should be absolute positioning, so 12G will bring you to the twelfth line.

I do deviate slightly from default VIM in that relative lines are one, so the line count starts at 0, respective to your cursor. Is there a chance that this plays into your experience of the bug?