Arvīds Kokinsin case anyone's wondering, the reason why we don't have magical "drag every number / sliders everywhere" mixed-mode text editing UI is that there's no way to specify the scale, range and curve of each constant, and no easy way to infer it from the context (you'd need to reverse-compute the specified ranges through math operations, including through function calls, some of which might have conditionals or even side effects)
while one could simplify the application of presets through a context menu (right click and choose among basic presets)
even something as simple as <number> * <number> means that if you drag one number, the scale of the other number should be adjusted accordingly, but only sometimes
personally I think that a software-hardware hybrid might make it more likely
e.g. a keyboard-adjacent vertical tactile-stepped scroll wheel just below the spacebar for easy thumb access* with narrow but identifiable-by-touch buttons indicating which digit should be adjusted
*-I know this excludes laptops, screw them lol, they're basically torture devices anyway (including macs)
usage = hold the digit(s) to adjust and rotate the wheel to make discrete adjustments
lol so now I'm working on a #VisualStudio extension where you can scroll a number up or down if you hold down Right Alt
got the basics working too but now it's only handling one digit for now (the last one or the one right before dot, if a dot was found), and spamming the undo history with each step
I could probably have number in-/decrementor as a separate testable function to speed up development of that part and focus on seeing what I can get out of VS wrt undo/selections
making some progress
here's number tweaking with the scroll wheel while holding right alt, optionally holding 5/6/7/8/9/0 to change which position should be tweaked
decided to just use the decimal type with string cleanup (trailing zeroes) to avoid having to do complex string manipulation myself
the number keys do not seem to trigger menu events that eat the "right alt up" event like the [B N M , . /] keys did, hopefully that won't change in the future (win11/vs>2017)
converted the preview to an "adornment" (as VS calls overlapping UI layers)
also added a preview indicating which digit would be modified by scrolling
this concludes the prototype work so all that's left to do is to polish the remaining rough edges and clean everything up
also didn't have room to mention previously - I've sidestepped the undo history merging issue when committing on each tiny edit by only committing when right alt is released instead
https://github.com/archo5/vsext_numtweak
here's the extension
it's limited to VS2017 for now because that's what I use (but you can change the version range in package config)
it should work for other versions as well (based on what the docs suggested) but I haven't bothered to test any
curious if anyone can come up with improvements
I'd like to upload a prebuilt package but I need to dogfood it first and the chances that others are still using VS2017 seem small
first design issue found while dogfooding - trailing dots
the need is primarily for floats and doubles in C-like languages
but another unexpected need was allowing the editing of the number inside filenames in the <name><num>.<ext> format
removing the dot in the process of making the number prettier would break the filename
all that is fixed by preserving a trailing dot if it was there before
already updated the repo