feat: suite of changes

[johnrichardrinehart]

Overview

First: my apologies/caveat since this is one of my first PRs almost completely relying on LLM-generated changes. I made sure to preserve that information in the commit messages. However, I've been testing this branch lightly over the last 12h and I'd like to consider the ideas in the commits for review, even if the exact change set is undesirable for any number of reasons. Also, each of these commits is notionally independent, so I've done some work to extract each into its own branch off of main (0.4.1). But, 2 of the 4 commits on this branch are interdependent (they affect the same file in dependent ways) so cherry-picking wasn't clean when generating all the associated "one-commit branches. Please note that the entirety of the human interactions (prose) in this PR (including this description) will be generated manually by me.

I only ask maintainers to consider the pain points and ideas, below. Given that I haven't reviewed the generated code, it may introduce new issues which I haven't considered. I'll outline the goal of each commit, below. If this entire PR branch as-is is accepted, then there's no need to consider the commits in isolation on their own branches. If certain changes need more review then we can drop any/all commits, here, and open separate PRs as-needed on a case-by-case basis.

Please note that I have not defined a wl-kbptr configuration file. So, I'm using the default application logic/configuration according to wl-kbptr's user documentation.

Commit 1 (UX fix)

1. On at least one of my displays, I'm seeing duplicate labels in bisect mode (after tile mode). I don't see this on all displays, though. Please see the below screencasts for the problem and after applying this commit/patch.

0.4.1

repeated_bisect_labels.mp4

With edfd6cd

unique_bisect_labels.mp4

Commit 2 (UI fix)

I'm finding that on at least one of my displays, the bisect labels run off the screen for those "rectangles" on the edge of the screen. Please see the screencasts below documenting the problem and the "fix". I don't love how the labels aren't positioned in the same row/column as the rectangles, exactly. But, the spirit of this change is correct: labels are always visible. I also saw that labels would be inconsistently embedded within squares at a given "level". So, toward the top of my screen, the bisect rectangles may have the text within the corresponding square, because it was deemed small enough to fit, but then at the bottom of my screen, the labels would surround the rectangle (not be placed within the square) even though the square and font size were the same - only the rectangle's position on the display was different. So, this commit also tries to make this behavior consistent.

0.4.1

labels_on_screen.mp4

589f2ab

labels_off_screen.mp4

Commit 3 (compilation fix)

This just fixes a compiler warning:

[9/11] Compiling C object wl-kbptr.p/src_main.c.o
In function ‘print_result’,
    inlined from ‘main’ at ../src/main.c:921:9:
../src/main.c:628:5: warning: ‘click’ may be used uninitialized [-Wmaybe-uninitialized]
  628 |     printf(
      |     ^~~~~~~
  629 |         "%dx%d+%d+%d +%d+%d %c\n", state->result.w, state->result.h,
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  630 |         state->result.x, state->result.y, state->current_output->x,
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  631 |         state->current_output->y, click
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  632 |     );
      |     ~
../src/main.c: In function ‘main’:
../src/main.c:613:10: note: ‘click’ was declared here
  613 |     char click;
      |          ^~~~~

Commit 4 (feature)

I love this change/feature less than what I first created it, so no stress to discard. This change basically allows users to opt in to (prefix_adjacency=[false|true] in their configuration file) a tile mode behavior where selecting a for something like al will ensure that ak and am are adjacent to al. If this commit is placed on 0.4.1 (instead of on top of edfd6cd193f75981938b2959f6b13c6348737dbf (commit #1)) then the adjacency will be vertical instead of horizontal, since that commit changes the layout ordering of tiles. Please see the screencast for what this looks like.

0.4.1

tile_adjacency.mp4

8b99035

tile_no_adjacency.mp4

[moverest]

Thank you for your interest in the project.

For "commit 1 (UI fix)", I'm not sure why you have this bug. This bug should have been fixed with the 0.4.1 release and I can't reproduce there. Do you have any custom configuration or just use a Dvorak layout? In any case, the AI went awry since the commit changed the wrong file for this mode. This would be in the src/mode_bisect.c file and not scr/mode_tile.c.

For "commit 2" (UI fix), I like the idea and agree with your assessment. An easy solution might just be to get the check the bounds and if it goes outside the screen just put it at the edge then check if the other label would overlap and do the same except to the edge of the other label.

For "commit 3 (compilation fix)" sure. The case where the value is not set shouldn't happen (unless there's a bug) thus why I didn't bother with this. This would probably be more adequate:

    case CLICK_NONE:
        click = 'n';
        break;
    default:
        LOG_ERR("Invalid `click` value. This should not have happened.")
        click = 'n';
        break;

For "commit 4 (feature) adjacency", there shouldn't be any need to store the indices in a list. We just need to change the way the labels are generated to use the first letter as the least significant value. This means modifying the label_selection_incr(), label_selection_set_from_idx() and label_selection_to_partial_idx() to work from the end of the input vector to the beginning (the opposite of what we're doing now). If you want to change the order and make it the default and only behaviour I don't mind.