v0.2.1: enhance keyboard shortcut (word-break)

[ynqa]

Key	Action
Alt + B	Move the cursor to the previous nearest character within set(.,|,(,),[,])
Alt + F	Move the cursor to the next nearest character within set(.,|,(,),[,])
Ctrl + W	Erase to the previous nearest character within set(.,|,(,),[,])
Alt + D	Erase to the next nearest character within set(.,|,(,),[,])

Resolves #8

[hu0p]

I built this locally on an arm64 Mac and tested it inside default iTerm 2, Visual Studio Code's integrated terminal, and the native macOS Terminal.

Installation/Compilation Notes

j9-sys won't build on arm64 Mac, and the Dockerfile setup gave me some trouble as well. I was able to get the container running by changing the rust image and llvm repo (reference), but ran into a separate issue trying to build there. Ultimately, in order to produce a debug binary, I abandoned the container approach. Instead, I chose to install automake and libtool natively with brew install automake libtool. After that, cargo build ran successfully. It was also much faster and more lightweight.

Test Results

As expected, default iTerm 2 still produces the same problem. For anyone who might stumble upon this, it's possible to alleviate this with the following configuration guide (the instructions are for an older version but the gist is the same).

A nice treat, however, is that Visual Studio Code's integrated terminal seems to not be affected and works with this PR's changes out of the box. I suppose VS Code sends Escape Sequence + [B|F] when Option + [Left|Right] Arrow is pressed instead of the xTerm defaults on macOS. Option + Delete also works (maps to behavior of Ctrl + W as @ynqa outlined here). The only one that doesn't work is the equivalent for Alt + D, which is Option + Shift + Delete on macOS.

The default native macOS terminal works for Option + [Left|Right] Arrow but doesn't work for Option + Delete or Option + Shift + Delete.

[ynqa]

@hu0p Thank you for pointing out the installation notes. I plan to address this in a separate PR.

Alt + D

Please try this with Option + D (without Shift), I also tested it on MacOS and it worked without any issues.

[hu0p]

Interesting. I'm unable to reproduce this. Option + d produces the partial derivative character for me (∂). I tried this with normal keyboard input as well but here's a video with the accessibility keyboard for demonstration purposes:

Option.+.D.mp4

[hu0p]

@hu0p Thank you for pointing out the installation notes. I plan to address this in a separate PR.

Sounds good! Is your plan to update the docs to suggest the native approach or make the Dockerfile platform-independent? I'd be happy to give a shot, although I'm not sure what can be done about the homebrew on linux situation if that's a priority.

Edit: looks like someone may have a related WiP open on this too https://github.com/ynqa/jnv/pull/32/files

[ynqa]

@hu0p Please check if the option is set to Esc+:

Q: How do I make the option/alt key act like Meta or send escape codes?
A: Go to Preferences > Profiles tab. Select your profile on the left, and then open the Keyboard tab. At the bottom is a set of buttons that lets you select the behavior of the Option key. For most users, Esc+ will be the best choice.

From https://iterm2.com/faq.html

[ynqa]

Is your plan to update the docs to suggest the native approach or make the Dockerfile platform-independent?

@hu0p This is about the topic of devcontainers, right? Initially, it was prepared for the verification of Homebrew for Linux, which I think would be beneficial to have in the future. However, I'm thinking now it was more important to complete a container environment in which jnv can be built properly, ignoring Homebrew.

I would appreciate it if you could give it a try.

(By the way, this is for a Dockerfile that builds, not for one that runs the binary, right? If it's the former, it's being discussed in #19)

[hu0p]

Please check if the option is set to Esc+:

It wasn't. I had only set my configuration to send Esc+ on a key-combo level for those I mentioned. Sorry if that created confusion. If we're in agreement this kind of configuration is a reasonable pre-requisite for this functionality to work, I think this work is good to merge. After all, we can only offer keyboard shortcuts, not force TTYs to use them, right? 😁

This is about the topic of devcontainers, right? Initially, it was prepared for the verification of Homebrew for Linux, which I think would be beneficial to have in the future. However, I'm thinking now it was more important to complete a container environment in which jnv can be built properly, ignoring Homebrew.

By the way, this is for a Dockerfile that builds, not for one that runs the binary, right?

Yep, I was referring to one that builds cross-platform. Thanks for pointing out #19. I'll take a stab at it and follow up with a PR or there if needed.

[ynqa]

we can only offer keyboard shortcuts, not force TTYs to use them, right?

@hu0p Yes, to my understanding, we cannot enforce it. Also, since the configuration depends on the editor (and possibly the keyboard), it would probably be difficult to accommodate all cases.

As an example with text editors, it seems like there might be similar issues:

• Alt(Opt)+_ keymaps do Not work on macOS helix-editor/helix#2280

Therefore, I will go ahead and merge this. Thank you very much for your cooperation in the review 🙇

Regarding #19, since there hasn't been any update from the person assigned, I think it's fine for you to go ahead and work on it freely.