is the boards that are going over the memory limit expected?
the code this adds to base without enabling anything is almost nothing...

On NixOS with avr-gcc (GCC) 8.5.0 I get this on develop:

jones/v1:via        * The firmware is too large! 29126/28672 (454 bytes over)
keebio/bamfk1:via   * The firmware is too large! 28692/28672 (20 bytes over)

jones/v1:via is oversized even on master (40 bytes over); keebio/bamfk1:via on master barely fits (10 bytes free). So these boards are already broken on develop even without your changes, and are probably broken even on master with some different compiler versions.

Let me know if there is anything I can do to help the process along

Okay so a bit of a major update to how pointing mode maps are working.

Pointing mode maps now use action_exec to process key presses (basically the same code as for encoders) which enables the ability to use more than basic keycodes (such as QMK keycodes etc.). Not much changes at the keymap level other than the new POINTING_NUM_DIRECTIONS instead of hard coding 4 to avoid issues and now POINTING_MODE_MAP_COUNT is handled automatically and now only a POINTING_MODE_MAP_ENABLE = yes is needed in rules.mk).

Documentation has not been fully updated yet.

Still needs proper testing but I have been able to compile it without issue.

Okay should be cleaned up now. Sorry for anyone who picked it up while it was a bit of a mess for a bit there.
need to be better about maintaining my git exclusions and keeping my local repo up to date and based on latest develop.

Okay there was a bit more than documentation to fix up, but should be working as intended now.
POINTING_MODE_MAP_COUNT is now properly handled automatically at compile time (i.e. not intended for users to modify or define) pointing_mode_map_count(void) is meant for modifying map count if needed as a hidden feature similarly to encoders.

Argh another keyboard is going oversize again is this expected? (the code should not add much size without enabling things unless I missed something)
Also what is keeping this code from going into develop? is there anything that still needs to be addressed?

I have some feedback:

First off, thank you very much, alabastard, this is great!

I tested the changes and have been running them on my productive keyboard for a combined 35 hours without trouble, though I did not try pointing mode maps yet.
It does what is advertised and does it well. Thanks to the expansive documentation, it was easy to integrate. I found no side effects that the docs didn't warn me about.

However, I found one small issue (or two tiny related ones, depending on how you look at it). The down and left directions of caret scrolling, volume, and history modes are swapped, and the order of the parameters for the relevant pointing_tap_codes are not in vimkeys order as documented.

I've submitted a PR to the source fork that hopes to address this minor issue.
Alabastard#1

First off, thank you very much, alabastard, this is great!

You are very welcome! I am just happy when someone uses my code :)

I tested the changes and have been running them on my productive keyboard for a combined 35 hours without trouble, though I did not try pointing mode maps yet. It does what is advertised and does it well. Thanks to the expansive documentation, it was easy to integrate. I found no side effects that the docs didn't warn me about.

This is great! glad it is working out there in the wild and that the docs were for the most part pretty clear/thorough!

However, I found one small issue (or two tiny related ones, depending on how you look at it). The down and left directions of caret scrolling, volume, and history modes are swapped, and the order of the parameters for the relevant pointing_tap_codes are not in vimkeys order as documented.

I've submitted a PR to the source fork that hopes to address this minor issue. Alabastard#1

Thanks for bringing this to my attention!
Also thanks for taking the effort to submit the PR!
However there is an issue with the PR you submitted in that you introduce a bug but you caught some bugs which thanks for that (I'll give more details in response to your PR).

Relabelled for q2 pending further work by alabastard. I've tested what's in place so far and works well but appreciate the feedback in the chain above.

Thank you for moving this to q2 sorry I've been slow haven't had as much time as I would like to work on this each day but progress is being made.

Unfortunately the changes will require major updates to any code that uses this. A lot of function/define names have changed and many functions have been removed as they are no longer necessary.

This will hopefully simplify interaction with pointing modes and improve functionality as well. I will push an update as soon as I can compile and test.

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

Okay finally testing the latest changes and updating the documentation should push the changes really soon
Currently I have implemented the requested features along with the major rework:

• Give consistent naming convention to all functions
• Change precision to a per device setting that can be adjusted rather than a separate mode
• General Cleanup of the code to remove some of the functions which are no longer needed
• Reorganize primary data struct so all per device data is in the same struct
• Allow for pointing mode types which currently allow for switching between tapping and holding type modes as well as 4 way vs D-pad
  • Holding modes currently hold a key down until the next movement of the pointing device (this works with both the 4-way and D-pad mode types) (in D-pad modes horizontal and vertical presses are tracked independently)
  • Also still adding in catches for this to prevent orphaned held keys (timers and cleanup on layer switching etc.)
  • D-pad mode will send both horizontal and vertical key presses (as taps or key holds depending on the mode type) when the pointing device reports a diagonal movement (a diagonal movement has a rather abstract definition based on what I think could be efficiently calculated will be shown in the documentation)
  • 4-way is the default and will just send a key press when movement is primarily in one of the four directions
• Focus the feature on using mode maps for all modes that involve key presses

Currently Requested features that were not included are:

• Allow for the syncing of mode maps to keyboard layers if desired (similarly to how encoders work) (Planned)
• Allow for making 8-way maps to allow for sending unique keys for diagonal movements (Not planned at the moment)

Apologies for the delay should have the update this soon
Was having issues with the holding behavior being a bit janky... I was considering removing it due to the bloat it can add (two extra 16 bit variables per device) but I think I'll just get it working as intended with cleanup on mode change and timeout so someone with a track pad can test and see if they like it (perhaps I should have this as an option?)

Okay I'm back from my health crisis/the dead to finish this up I have resolved the conflicts just need to move keycode stuff appropriately and then I should be good to push the update.

@Alabastard welcome back and good to hear that you are doing better. Leave a comment when you have updated the PR - I intent to give it a review once the merge conflicts are resolved.

Still working on this should have update soon.

Okay I am actually pretty happy with the state of the code right now just going through the docs to adjust to the changes while I am testing the code. Will push an update as soon as docs are updated.

Currently there are still two requested features missing:

1. Option to force syncing of pointing modes to layer state
   -Not sure how to do this in a way that is not annoying when there are multiple devices
   -could force it for single device only
2. Allow for 8-way directional support for keys with unique keycodes on diagonal movements
   -Diagonals is supported only for D-PAD type modes that will press both horizontal and vertical keys on diagonal movement
   -Additionally this will reduce the maximum number of maps to 32 as it only is using one row of the matrix

Currently there are still two requested features missing:

I'd vote for getting it merged as is, the extra features can always be sorted later and those will be a smaller (easier) pull request to review.

Okay finally doing a full update and just running into some issues with keycodes as soon as I can set a new range I'll get this up

edit:
New range selected but I need to make some adjustments to account for the extended wheel reports (should be able to use my old code if it is handled the same way as my old implementation)

Really close here I'm hoping to get all this done over the holidays

Update:
New Code is compiling finally after a greater than expected number of changes to how the json needs to be setup and cleaning up the keycodes (currently I have added them as 0.07 let me know if I need to change that to 0.06).
Once I get it tested on a keyboard I will push the update, hopefully tomorrow.

Testing has been a lot more of a slog than I expected especially with getting the data driven config done correctly but progress is being made.

Okay running tally of everything that has been tested, fixed, and working:

• New Precision setting and Divisor code
• 4 way Maps ( allows for using QMK keycodes)
• 4 way tapping workaround function (legacy only standard keycodes allowed)
• D-PAD Mode type (Fixed!)
• Hold key modes (Working but differences to tapping mode are very subtle)
• 8 Way Maps (Working!)
• 2 Way Maps
• inverting setting per mode (part of mode type)
• allowing adjusting settings (Divisor, and type) on default modes (Drag/regular pointer)
• Finish updating Documentation with all changes (Now finally fixing up this)
  • Update 4-way mode maps documentation, divisor setting, and precision
  • Add 8-way mode map documentation
  • Update all function names to new naming scheme
  • Add section for adjusting mode types and options with examples
  • Update advanced mode type definitions to include new functions for accessing residuals etc.
  • Update any device switching code to reflect changes