[mini.operators] gh - to hex motion idea

[felpafel]

Hello, I have a suggestion to make regarding MiniOperators.

Introduction

My most used feature in the plugin is by far the evaluation motion (g=), specially when I'm debugging. Instead of reaching to python or even calc.exe, I can dump any math expression with hex and binary numbers and the plugin can give me back the answer. However, when I'm subtracting memory addresses, the decimal representation, given after evaluation, has little to no meaning, forcing me to use another tool to do the decimal to hex conversion.

Solution

Create the following motions: (I used my own motion implementation to make the demo video)

• gh motion, like go hex, e.g. 255 -> 0xff;
• gH motion, like go HEX, e.g. 255 -> 0XFF;
• gb motion, like go bin, e.g. 255 -> 0b11111111;

The intended workflow is to after an evaluation motion the user can do an ghiw and have the answer converted to hex. In addition, 0x/0X and 0b/0B are valid number representations in Lua, so the user can do another g= motion, if they desire.

Implementation

I included only the "parsing" code, since MiniOperators already has the entire engine for capturing/handling motions.

Hex

The hex implementation is just a 1 line code, since string.format already has hexadecimal formatting builtin.

-- # is used to add the prefix `0x`
string.format('%#x', n) -- `0xff`
string.format('%#X', n) -- `0XFF`

string.format does not convert 0 to '0x0' but to '0'.

Bin

The bin implementation requires a function to do the conversion, since there is no builtin method.

local to_binary = function(n)
  if type(n) ~= 'number' then
    n = tonumber(n)
  end
  if n == 0 then
    return '0b0'
  end
  local binary = ''
  while n > 0 do
    binary = (n % 2) .. binary
    n = bit.rshift(n, 1)
  end
  return '0b' .. binary
end

This solution assumes that neovim is built with luajit, but bit.rshift(n, 1) can be changed to math.floor(n / 2) if the luajit assumption is bad.

Why I think this is a good idea?

The hex conversion is trivial and supported by Lua. When working with colors, memory addresses, etc. the hexadecimal representation is the standard way to represent numbers and often they are easier to reason about. And since g= force all evaluations to decimal representation, it's good to have a way back to hexadecimal representation.

Demo

poc.mp4

[echasnovski]

Thanks, this looks interesting!

Instead of 'mini.operators', I think this will have a better fit in the planned 'mini.cycle' (or possibly 'mini.convert') module dedicated to "cycling through alternatives with pre-defined rules". This particular case can be framed as "cycle through different number representations".

Your examples will be handy, thanks!

[felpafel]

Thanks for your reply!

I agree with you, this can fit better in something like 'mini.convert', and justify having bin, oct, dec and hex all together.