Blink: Better precision when selecting text

[goerz]

I mentioned this in #52 already, but the more I actively use Blink, the more strongly I feel the frustration in selecting text for copy and paste. The tap-and-hold, then dragging the handles is (a) way too slow and (b) I don't seem to have the motor skills to select exactly the text I want on the first try (it always turns into the "vertical" selection box, and then everything becomes just a mess).

Ideally, I could hit a shortcut, move the cursor across the screen with the arrow keys (and maybe roughly position it with a tap), then select text with Shift+arrow keys, then copy with Cmd+c and paste with Cmd+v.

[carloscabanero]

This is painful throughout iOS, but I think it became even more painful in the last Blink version. Will check if there has been any type of regression with HTerm too.

The cursor idea is great. But doing a cursor move across the screen could be a bit painful, so maybe doing tap and hold to start the selection and then using the arrows or keys to move could help a lot. Another feature that could work is to enable "copy mode" from tmux, although I think that is a mosh limitation. Also related to #71, as the "Extend" feature will help in 80% of the cases where you require precision.

[goerz]

Thanks for reminding me that tmux (which I'm always in) can handle this pretty well. I just have to get into the habit of using it and build some better muscle memory for the copy/paste shortcuts. It actually pretty much does exactly what I had in mind!

Nonetheless, it would be great to be able to use the keyboard to extend a selection that was first created by tapping, as you suggest!

[iq6gGsk7]

I was thinking about how this would be the best as user point of view. For me and lots of admins around me copy pasting is essential and works quite flawless in any desktop terminal application coupled with a text editor at hand. However as you say it is still a pain on iOS. I've using prompt too but it is a bad experience as well.

One problem is that the screen gets resized when switching to copy-paste mode, because the on-screen keyboard hides, at least in Prompt there is a bar containing undo controls that gets hidden now and then even when using an external keyboard. My point here is that the aspects of the screen I am typing into should be pretty solid and should not be changed unless I manually hide the keyboard or rotate the screen and so on. I use a lot of curses-like application, or formatted output and these constant resizes are pretty frustrating.

Though it is innovative the way blink handles tabs, it messes this up. I'd rather pick single pixels for changing windows in exchange for having a rock solid experience when typing and copy pasting.

Again I don't know much about iOS programming but there are text editors out there were copy pasting is surprisingly usable, think of Editorial for example.

I am in the habit of learning tmux copy pasting too but I think it is a step backwards. I am using a touch device because I want to work with it like a with piece of paper. You know when I want to highlight a word on a paper, I put my pen there and underscore it, so I don't have to sit at a typewriter and type ^b-[ l l l W W v e ESC ^b-] .

[carloscabanero]

In the iPad with an external keyboard this is much less of a problem I guess, as the window doesn't change at all.

I actually had the keyboard as a static part of the UI, but during a trip switched to having it full screen. I just had to be able to see more stuff during copy/paste, specially when using Mosh (as with Mosh the scroll doesn't really work.

I will put more work on it after release as I think there has to be a great way to do it for everyone. A greate start will be: dismiss the keyboard only if you explicitly dismiss it instead of changing the mode for selection - this might be problematic during SplitView though -, and avoid the keyboard movements during swipes.

[carloscabanero]

iOS 10 messed up with the gestures, so we might have this sooner than expected.

[ohAitch]

Gestures emitting arrow key presses would be great, yeah.

[carloscabanero]

We have tried to fix it also by performing a "two point" selection, and it was not working (difficult to capture the gestures on HTerm).

I have also tried to avoid the terminal to change size at least during the section. Tried to follow the keyboard hide event, but it was not possible to restore it back to normal properly.

Continue finding a solution...

[ggruen]

A piece of this, possibly easier to fix, is that when using an external keyboard with the "Smart Keys" turned on in the Blink configuration, tapping and holding on the screen (to select a word) dismisses the Smart Keys, causing the selection to end up a few lines above where the user originally tapped. If the Smart Keys keyboard would stay put, selection while using an external keyboard would be pretty simple (well, as simple as it usually is on iOS).

To reproduce:

• Turn on Smart Keys > Show with external keyboard
• tap and hold on a word on the screen

Expected result:

• The tapped word is selected

Actual result:

• The screen shifts down and a word a line or two above the originally-tapped word (distance dependson the font size) is selected

Not sure if this should be its own issue or if it's related enough to belong in this issue.

[carloscabanero]

Alright, so v9 brought better precision, and in v10 we even have keyboard controls for the selection.

@goerz I will let you close it if you feel comfortable enough already with it.

Thanks!

[goerz]

The keyboard controls seem extremely nice, except for one things: how do I switch between the arrow keys moving the beginning of the selection vs the end of the selection? Sometimes, pressing space seems to do it (but only very rarely)

[yury]

@goerz selection mode supports vim and emacs keys. You can use hjklwb. And like in vim you can change control point with o.

[goerz]

Ah! Great! (I had no idea about 'o' in vim.. I don't think I ever select anything).

I also noticed that the up-down arrow keys (respectively j, k) do something weird. I assume they should go up/down one line, which they sometimes do, but then they tend to stop working, or change behavior to jump to some random other location

[yury]

Config, line wise selection a little bit buggy. It confuses when style of text changes :(

[goerz]

Ah, yes. Should I submit a new issue to track that? Or do you want to keep this issue open? As far as the original issue, I'm very happy with the solution, so I'd be ready to close.

[yury]

There is now easy solution for line wise selection now. So if you can create new one it would be awesome.

[goerz]

Will do, sometime later today...